Weekly Edition
Return to the Security page
| |||||||||||
|
| |||||||||||
Rapid security patches considered harmful?
When a security vulnerability is found, the right thing to do is to prepare
a patch and circulate it as quickly as possible. At least, that would
appear to be the prevailing wisdom. This
ComputerWorld article, however, takes a different approach: in many
cases, patch circulation should be slowed down, not sped up.
The author is talking, in particular, about vulnerabilities which are found by "white hat" hackers, as opposed to those which are already being actively exploited. These vulnerabilities are, presumably, unknown to the cracker community at the time the patch is prepared. But a security patch provides an instant road map for anybody looking for vulnerabilities. Rather than put in some honest work digging through and understanding a large program, a cracker need only look at the piece of code which is fixed. The release of a security patch allows administrators to close a hole, but it also tells the world about the existence and location of that hole. At that point, the race begins: administrators try to get the patch deployed before the crackers get their exploits working. What's needed is a way to give the defenders a larger window of time to obtain patches before information about the vulnerability they fix is distributed. Various approaches have been tried to accomplish that goal. The "vendor-sec" mailing list, for example, helps Linux distributors and other operating system vendors to all have their updates ready by the time a vulnerability is announced. Vendor-sec helps, but it does not solve the problem of actually distributing an update to millions of users. The OpenSSH project once took a different approach and pushed a major update on users in an attempt to deploy a security fix without saying what it was; this move was received poorly, however. What the ComputerWorld article suggests is that patches should be distributed in encrypted form. For some period of time, the encrypted patch is just a useless pile of bits sitting on the disk. This time would be the window which allows the patch to be distributed without disclosing the problem which is being fixed. After a given period of time, a key is distributed which enables the decryption of the patch; at that time, clear versions of the patch could also be made available. In theory, this approach would enable the security-conscious users on the net to update their systems nearly simultaneously as soon as the nature of the problem is disclosed. This is a solution which could perhaps work, though steps would have to be taken to fend off denial-of-service attacks aimed at preventing the distribution of the decryption key. The provision of encrypted patches does go somewhat against the spirit of the free software community, and it could, by some readings, be taken as a violation of the GPL. For almost all of the security vulnerabilities which are reported, the encrypted patch mechanism would be far more trouble than it would be worth. The next time an easily-exploitable vulnerability turns up in a utility like bind or ssh, however, it might be a nice option to have. (Log in to post comments)
Rapid security patches considered harmful? Posted Apr 15, 2004 5:34 UTC (Thu) by Peter (guest, #1127) [Link] I really don't get it. Would a 1-kilobyte decryption key really be significantly faster to deploy than a 400-kilobyte patch? There are a lot of reasons administrators don't patch their systems in a timely manner. Very few of these reasons have anything to do with not having enough bandwidth to download the patch. Having an encrypted version of the patch sitting around does not give you a head start on testing it, for example. One thing that might close a window of vulnerability just a bit would be to announce, 24 hours in advance, that such-and-such product has a hole, and say just when the details, and patch, will be released. You wouldn't want it to be much longer than 24 hours, but that would at least give admins the chance to plan for some downtime, and ensure the real announcement, the next day, won't languish unnoticed in their security announce mailbox for long. (I hope it's safe to assume that any reasonable admin will check this mailbox at least once a day.)
Rapid security patches considered harmful? Posted Apr 15, 2004 8:54 UTC (Thu) by eru (subscriber, #2753) [Link] I really don't get it. Would a 1-kilobyte decryption key really be significantly faster to deploy than a 400-kilobyte patch?Yes, it would. Especially considering that for most end-users and major programs, it is not actually a 400K patch, but a whole RPM (or other such package) that these days usually is many megabytes. Not everyone has a fast bit-pipe... I think the suggested idea is great! In theory, it would would permit the vulnerability to be disclosed and correction to be applied nearly simultaneously all over the world. Proper tool support is of course essential, but the feature could probably easily be added to existing update managers like apt-get.
Rapid security patches considered harmful? Posted Apr 15, 2004 9:37 UTC (Thu) by fergal (subscriber, #602) [Link] For a minute, it made some sense to me, when I thought of a patch as a big chunk of binary nastiness from MS, rather than a small source code diff fixing the offending line(s) of code. Then I realised that this kind of patch doesn't give very much info to black hats so there'd be little point in encrypting it. They must actually mean a source code diff.Encrypting a source code diff doesn't make much sense as security patches tend to be very small and the configure, build, test, install cycle takes much more time than downloading the patch. So I don't see the point.
Rapid security patches considered harmful? Posted Apr 15, 2004 10:37 UTC (Thu) by eru (subscriber, #2753) [Link] For a minute, it made some sense to me, when I thought of a patch as a big chunk of binary nastiness from MS, rather than a small source code diff fixing the offending line(s) of code. Then I realised that this kind of patch doesn't give very much info to black hats so there'd be little point in encrypting it. They must actually mean a source code diff.
disassemble oldexe > old.s Assuming "disassemble" is a sufficiently smart disassembler and the "black hat" is not totally incompetent, the difference will probably be enough to tell what kind of flaw the small source code patch fixed. Even if the binaries are totally stripped: if the attacker has access to the sources of the old version, he can use them to build oldexe with full symbols and use them to map the source locations that the patch affected.
Rapid security patches considered harmful? Posted Apr 15, 2004 23:27 UTC (Thu) by Peter (guest, #1127) [Link] For a minute, it made some sense to me, when I thought of a patch as a big chunk of binary nastiness from MS See, I actually read the article. (: That is what it's talking about - patches in closed-source software. Even so, downloading the patch is, IMO, a really minor step in the typical deployment stage. And you can't continue the deployment (testing, loading on to whatever software distribution mechanism you use, etc.) until you have a (decrypted) patch. To be fair, the article remains uncommitted to whether this is a good idea or not. It's just an idea, thrown in there, to make the point that the status quo is not optimal for patch distribution. I don't really agree with the article's main thesis, but that part of it is pretty hard to argue against.
Rapid security patches considered harmful? Posted Apr 15, 2004 8:25 UTC (Thu) by ballombe (subscriber, #9523) [Link] With vendor-sec+apt-get you get your system updated the same day advisoriesare issued without any hassles. Who needs to patch systems manually nowadays ? Also, some scary stories like <http://www.isec.pl/vulnerabilities/isec-0012-do_brk.txt>: "We have succesfully created proof-of-concept exploit. Unfortunately we guess that our exploit may have leaked to the underground." do not encourage advisories and patches retention.
"vendor-sec" Posted Apr 15, 2004 9:52 UTC (Thu) by jmshh (guest, #8257) [Link] How is information distributed via "vendor-sec" helpful? Either everyonecan have access to that, including black hats, or lots of small and or new vendors are excluded. Remember: Everybody can start a new distribution any time, and some even do so.
Rapid security patches considered harmful? Posted Apr 15, 2004 14:57 UTC (Thu) by RobSeace (subscriber, #4435) [Link] Purposefully withholding patches for any length of time is just a reallystupid idea... Even more stupid is identifying the program/service with a hole in advance of actually letting people fix it... Because, as soon as everyone knows there's some unspecified hole somewhere, you can bet they'll all be looking for it... Maybe they'll find it, maybe they'll find yet a different one that you don't even have a patch prepared for, but they'll probably find something, with enough digging... Doing this is a giant step backwards, and gives a major advantage to the bad guys over the good guys... Just an absolutely mind-numblingly horribly stupid and bad, bad, BAD idea... If you bought the author's premise that all (or even most) exploits require
Rapid security patches considered harmful? Posted Apr 22, 2004 14:20 UTC (Thu) by jae (guest, #2369) [Link] Good points. I always wonder about that implied, unspoken, assumption that "If awhite-hat finds it, no black-hat will until a patch is provided". Let's face it: there's a 50-50 chance that a black-hat will find it sooner. Oh, and why do people assume that the moment a black-hat finds a vulnerability, we will see "widespread exploitation"? If I were a black-hat, and found something *really* juicy (like, say, there was a 100% working remote-exploit of SSH, any version post 3.0), I surely wouldn't spread that, but rather (at least for a time) keep that too myself. Immediate full disclosure would be wrong (as in: this is wrong, here's the exploit). But a "application xyzzy is remotely-exploitable" (if that severe) would make a lot more sense, at least from my POV.
|
|||||||||||