Slashdot Mirror
Due Diligence?
ekr writes "The OpenSSL remote buffer overflows discovered at the end of July got
a lot of press here on /. But how many people actually fixed their
machines? I decided to study this question, and the results are kind of
depressing. Two weeks after the release of the bug, over two thirds of
the servers I sampled were still vulnerable. Even two weeks after
the
Slapper worm was announced, a third of the total servers
were vulnerable. The paper can be found here in
PDF
or
Postscript."
I didn't and paid for it. Within about 3 hours time, some bastard got in, created a superuser, DoS'd nasa.gov, spawned a few irc servers, and started scanning other IP's for the same exploit. Damn they work fast.
Well if you'd read the PDF instead of skimming it, you would have seen this:
Thus, we can simply connect to the HTTPS server and issue a HEAD request. The server responds with an HTTP header containing the Server: field and hence the answer we desire:
Server: Apache/1.3.26 (Unix) mod_ssl/2.8.10 OpenSSL/0.9.6
They then went on to verify that SSLv2 is not disabled, but they mention later in the paper that on only 10 hosts was this done.
Theoretically you could change the response to report the more recent version which would make this check innacurate, but why would anyone bother doing that? Far easier to just upgrade OpenSSL.
Upgrading your OpenSSL isn't as easy as it could be.
Any decent distribution will do this work for you. That's what they're for after all. My Debian box was updated no more than 24 hours after I read about the problem, requiring nothing more that an apt-get update on my part.
This is too easy, folks. Subscribe to your distro's update announcement list, read your mail daily, and apply the relevant patches promptly.
It's really not that hard. A typical update for me is:
- read mail
- ncftpget whatever.rpm
- rpm -Uhv whatever
- read rest of mail
By far the most time-consuming part is waiting for the RPM to download. Some say that it's even easier for source-based distros.Sheesh, evil *and* a jerk. -- Jade
If you haven't yet, you should definitely check out nessus.
It'll scan your machiens for known vulnerabilities and give you pointers on how to go about taking care of any that it finds. It's also got built-in updating to pull in the latest exploits.
The clients are even getting pretty spiffy these days, and the project has matured very rapidly.
The bogus update problem is really no problem at all when you use cryptographic signatures: If there is an update, the distributor signs the update with his private key and the update process checks that the signature matches the data and is from a know authorized distributor. The public key which is used to check the update is distributed with the initial install media, so it should be out of the hackers' reach. The distributor would of course have to make sure that his key doesn't get compromised, but that should not really be an issue when smartcards or other separate/disconnected machines are used to sign the updates. This method is already in use today, but many projects still rely on MD5-checksums which the hacker can produce just as easily as the project owners.
- As should be noted from Figure 4, updating on Linux was rather easier than updating on *BSD, since all of the *BSD updates required compilation, either of the base system or from the ports/packages collection.
Huh?# pkg_add ftp://ftp.freebsd.org/pub/FreeBSD/ports/packages/A ll/openssl-0.9.6g.tgz
Binaries installed -- no compilation required!
No, but they have been cracked before:. html
http://www.attrition.org/security/commentary/ms16
It doesn't take a whole lot of imagination to come up with some very scary scenarios of what could have been put there instead of "Hacked by Chinese!" After all, how many people visiting Windows Update are running versions of IE without known run-arbitrary-code security holes?
Not sure how gentoo does things, since I tend to avoid cults, but the point here isn't that they were behind the curve, or old. It is that they had checksums of the correct (untrojaned) archives on a different server/media. Thus when somebody tried to build, the modifed archive was caught. Your post is just stupid and wrong. Additionally the OpenSSH trojan was caught in the same way, only via the FreeBSD port system which includes the checksums as part of the port. If the downloaded archive doesn't match the checksum, you get a warning. It is a security process, in that by seperating the checksums from the archives you can verify them without trusting the checksum from the same repository as the archive itself. With a sufficiently strong checksum this will catch *all* third party, substitution, trojan attempts.
In the same vein, readers might be interested in a presentation we did at RSA 2002; the topic was Downstream Liability for Attack Relay and Amplification
(A two-page summary is available here.)
We described a scenario in which an intruder compromised a system, used it as a jumping-off point, and subsequently caused damages to an individual. The paper focuses on the legal side of things; IANAL but the other two authors - Tim Rosenberg, J.D. and Ron Plesco, J.D. - are.
I also state my opinion, which is that "...patches should be installed no later than ten (10) calendar days after release of the patch by the vendor". Discuss.
I want to drag this out as long as possible. Bring me my protractor.
You actually have to recompile Apache with ./configure flags to link it to the new version of OpenSSL which you just recently downloaded
I don't. That's the beauty of shared libraries and shared Apache modules.
up2date runs with gpg signatures on all packages
and it checks all dependencies. And, since the packages are built by a company trying to guarantee you can run oracle on your box rather than a couple of dudes in a basement, the packages and their dependencies are correct and current.
--mandi
I've had up2date break a ton of things when it installs a newer version. ypbind and xinetd are two that bit us recently. They both installed and initially tested fine, but there were subtle changes that broke other things (securenets on ypbind, and all our ssl-based email services like spop3 and simap with xinetd). Easy enough to fix, but not something you want automated when you're on vacation.
We have a cron job at 4am that mirrors the RH update directories (only downloads changes) and then emails us if there are changes. Then we install and test them on a test non-production server to verify first, then install on the production boxes, plus we already have the update(s) on a local box so 'rpm -Fvh ftp://localupdateserver/whatever.rpm' goes really fast (especially when you have a couple dozen boxes to maintain).
I also checked the browsers, mainly command line a little while ago when the IE cert chain vulnerability was found. Most (wget, links, lynx) didn't bother to check the chain. Some didn't check anything at all, so any proxy server could spoof any page.
If you can see https://www.amazone.com, your browser is badly broken. amazone.com points to amazon.fr - but you should match the cert to the DNS.
Opera on the Zaurus was also vulnerable. Apple doesn't install any certificates in their OS X or Darwin OpenSSL directory.
One thing that happened between SSLeay (the original project) and OpenSSL is that the certificate chains were NOT installed by default, so everyone had a library, but no way of checking certificates since you require root certificates to check the site certificate. A second thing, probably worse is that the old default was to return an error if the certificate couldn't be validated. Now the default is TO GIVE NO ERROR IF THE CERTIFICATE CANNOT BE CHECKED. It would be better to give an error that would have to be overridden, which would cause developers to have to take a look and to actively disable security.
Curl was the only one that included any checking, but it required manually installing certs and specifying an option to turn it on. It would SILENTLY connect to SSL sites without security.
Mozilla was fine, and Konqueror fixed any problem it had, but the Opensource community should be embarrassed since the rest of the browsers security was not just flawed like IE, but DISABLED without any notice to this effect or NONEXISTENT.
No right-minded packaging system would have merged in the MD5 changes from the site on blind faith without at least giving the old and new files a cursory diff. The only people that were fooled by the weak strategy of modifying the server's MD5sum file are people who used the equally weak strategy of downloading it at the same time as the file. Everybody with a reasonable checksum-checking build system is safe.
You really should get out more. There are distro's that include a trusted key on the install media, and yes, people who use Free Software do get install media. If you don't have anything factual to see, silence will become you.....
People who think they know everything are a great annoyance to those of us who do.