The Security Patch Dilemma For Scripting And VM Based Languages

0 comments suggest edit

In his book, Producing Open Source Software, Karl Fogel gives sage advice on running an open source project. The section on how to deal with a security vulnerability was particularly interesting to me last night.

Upon learning of a potential security hole, Karl recommends the following:

  1. Don’t talk about the bug publicly until a fix is available.
  2. Make sure to have a private mailing list setup with a small group of trusted committers where users can send security reports.
  3. Fix the patch quickly. Time is of the essence.
  4. Don’t commit the fix into your source control lest someone scanning for such vulnerabilities find out about it. Wait till after the fix is released.
  5. Give well known administrators (and thus likely targets) using the software a heads up before announcing the flaw and the fix.
  6. Distribute the fix publicly.

There’s more elaboration in the book, but I think the above list distills the key points. Karl’s advice is born from his experience working on CVS and leading the Subversion project and makes a lot of sense.

But for a project built on Java, .NET, or a scripting language, there is an interesting dilemma. The security fix itself announces the vulnerability.

When the Subversion team releases a patch, it is generally compiled to native machine code, which is effectively opaque to the world. Sure with time and effort, a native executable can be decompiled, but the barrier is high to discover the actual exploit by examining the binary. It buys consumers time to patch their installations before exploits start becoming rampant.

With a language like C#, Java, or Ruby, the bar to looking at the code is extremely low. Such languages can raise the bar slightly by using obfuscators, but that is really not common for an Open Source project and creates very little delay for the determined attacker.

So no matter how well you keep the flaw private until you’re ready to announce the fix. The announcement and publication of the fix itself potentially points attackers to the flaw.

This is one situation in which the increased transparency of such languages can cause a problem. Consumers of projects built on these languages have to be extra vigilant about applying patches quickly, while developers of such code must be extra vigilant in threat modeling and code review to avoid security vulnerabilities in the first case. Then again, this doesn’t mean that code compiled to a native binary should be any less vigilant about security.\

If you have a better way of distributing security patches for VM-based/Scripting language projects than this, please do tell.

Found a typo or error? Suggest an edit! If accepted, your contribution is listed automatically here.



6 responses

  1. Avatar for Aaron Davis
    Aaron Davis September 20th, 2007

    I think it would be possible to create an automatic update mechanism, where the app calls home once a day to look for updates. We do this on-demand with trackbacks, so the basic technology is there. Most languages allow for programmatic downloading, so you could automatically download and apply any patches.
    There should be some sort of admin section, like automatic updates in windows. Automatically apply | Download and let me install | Just show me the list, that sort of thing. You could also have an option to automatically take the app offline if there is an especially critic fix.
    The only problem with this kind of system, is that it requires the admin to have access to the server, since the automatic polling would probably need to be a cron job, and some fixes may need to be recompiled.

  2. Avatar for Steven Harman
    Steven Harman September 20th, 2007

    @Aaron - I agree with the idea that there needs to be some sort of automated patching process... but this is especially tricky with web applications. Another thought is to just have a Check Engine light that will alert users that a fix is available.
    This is still something that I plan to add for Subtext... as soon as I find that 25th hour of the day, or a rich benefactor that will pay Phil and I to do this gig full time. :)

  3. Avatar for Joshua Flanagan
    Joshua Flanagan September 21st, 2007

    I'm confused about why the ease of decompiling a binary makes things harder, when we are talking about open source software. If the source is available, why would anyone need to decompile?
    Which I suppose is what is meant by point 4 above about not committing to source control, but that seems really backwards to me. Compiled code is distributed that has never been checked into source control? You build it on your local machine outside of the normal build process which is designed to promote consistency?
    Do projects like CVS, Subversion, SubText, etc have a private source control repository?

  4. Avatar for Haacked
    Haacked September 21st, 2007

    @Joshua I don't think they have a private source control repository. I think what happens is that one person is in charge of writing the patch. That person writes it on his/her machine and produces a proper build without committing those changes.
    Keep in mind that this is focused on the case when there is a critical security vulnerability. One that could cause users to lose data, or worse, control of their machines.
    In many cases, the users of the software isn't going to hax0r his own install, recompile the kernel, etc... This is the one situation in which you want a bit of closedness for lack of better term.
    The goal here is to keep the vulnerability as secret as possible just long enough for people to patch their systems. It's not an indefinite situation. Afterwards you commit the fix and everyone can see the code normally.

  5. Avatar for Adel
    Adel September 21st, 2007

    Yes, but at least if you only announce the issue with patch only not patched system will threatened, but if you do before providing the patch if i run SubText i will be threaten with not much to do.

  6. Avatar for Adel
    Adel September 21st, 2007

    Why i have to refresh if i wanted to leave another comment? and i know you try to fight spam with the 5 min delay but it's really annoying.