Slashdot Mirror
OpenSSL Security Vulnerability
SiliconEntity writes "On the heels of multiple OpenSSH vulnerabilities,
the OpenSSL project is now reporting a number of security vulnerabilities of its own. OpenSSL is a standard cryptographic library used in a wide variety of security applications. The new vulnerabilities range from denial-of-service attacks to stack corruption, which imply the possibility of running malicious code. New versions of the software are released today which address the vulnerabilities."
thanks up2date :-)
At least we find out when where vulnerable BEFORE the exploits start rolling out. I'm also yet to hear of Linux bringing the net to it's knees when some kid writes an e-mail virus.
Also, it took me less than a minute to patch my webserver. That's good design.
4. Due to an error in the SSL/TLS protocol handling, a server will parse a client certificate when one is not specifically requested. This by itself is not strictly speaking a vulnerability but it does mean that *all* SSL/TLS servers that use OpenSSL can be attacked using vulnerabilities 1, 2 and 3 even if they don't enable client authentication.
so i do think that it affects most users.
What the hell are you rambling on about? OpenSSL is not inherently insecure. While your points about using the KISS method are good practice for any software, in some cases complexity is inherent to the app. OpenSSL implements cryptographic protocol which is *not* simple, both because of the underlying mathematics, and because of the care which must be taken to avoid attacks which trivialize it.
And if you think auditing "secure software" is easy, you're just setting yourself up to be owned. Auditing should be done meticulously no matter how simple the app is perceived to be.
Most distributions do. With redhat you can subscribe to the redhat network, and with debian, its package manager, apt-get has this built in. Both of these however are dependant on the distro maintainers actually putting the new version in, and resolving dependancy issues that might arise.
On the other hand, unlike windows update you don't need to reboot every time you update something like this (the only time you ever need to boot is if you update the kernel).
How do secure software authors then avoid the kind of security holes that are difficult to find? By keeping the code simple.
You're way off base in this case. SSL requires the use of X.509 certificates, and it was in the cert parsing code that these new vulnerabilities were found. X.509 means ASN.1 formats, which have at least two different encoding rules, BER and DER that both must be supported; implicit versus explicit tags; several different ways of encoding packet lengths, and a host of other complexities. There's no way to write this kind of code and just keep it simple as you describe. Any implementation of SSL which is going to interoperate with other systems on the net is going to face these complexities.
I've written certificate handling code so I know how complicated it is. Also worth reading is Peter Gutmann's somewhat dated but still insightful X.509 Style Guide which describes some of the horrors an X.509 implementation has to deal with.
In this case the failures were mostly in the error handling, and any developer knows that this tends to be the hardest part of your program to get right. Not only are there a lot more ways things can fail than go right, but they can fail in many more places in your code and it is very difficult to make sure your program can recover gracefully from everywhere something might go wrong.
Also, I'm not sure if it's public yet, but a lot of other implementations are affected by this besides OpenSSL. See the CERT advisory when it comes out and you will find some of the biggest names in the security business got burned by this. It's absurd to suppose that your cosmic insights are somehow being overlooked by companies that base their reputations on security.
New RPMs and RedHat's security advisory for for 7.1, 7.2, 7.3 and 8.0 can be found here.
> will we see another lazy-admin problem with this (and any) vulnerability in Open Source applications?
Lazy applies to admins, open-source applications, closed-source applications, make-up applications, partners in relationships, oil changes, bill-paying, laundry, dishes, dogs, eyeballs, and any other situation where not taking action is available as an option, which happens to be most situations. No fix for anything is any good if it goes unused.
> what good is an immediate bugfix if the admin isn't applying the patch?
That's rhetorical, I'm guessing.
> does Linux have a similar auto-update feature like in Windows
There are several, but most are not really like Windows. They are usually better. For example, if you run Debian or can use apt for rpm, run apt-get update && apt-get upgrade as a nightly cron job. But the admin still has to initially submit the job, and pick up the pieces when something breaks. Automagic patching can have side effects and certainly perpetuates the "someone else" problem. Besides, I like to watch the progress meter. Makes me feel useful.
Anyway, hire a new admin if the one you have can't be a verb as well as a noun.
pardon my ignorance, does Linux have a similar auto-update feature like in Windows (but with fewer bugs :) ?
No problem, after all no one's born knowing this stuff. :)
It seems most Linux distros have such a feature under various names, but they generally call home (or the nearest mirror site, or wherever you told it to look), and compare the list of updates there against the software installed on your machine. Then it gives you the opportunity to review the relevant updates individually, with explanations about what they fix, on a per-application basis before installing any or all of them as you like. Many distros have a nice GUI app for this.
There are generally no monolothic do-all updates like in Windows-land; you only D/L what you need and if you ever install another package later off CD, you only have to grab the latest update for that one package, the system stays up, no reboots required. Or just install from the web and have the latest to begin with.
I can only speak for Mandrake about bugs, but I've never seen a fatal one on my home box. It doesn't try to think for you much to begin with, it just tells you what your options are and awaits your input, so there's less room for error, more ability to back-out, etc. There have been a couple of instances where it's gotten dependencies wrong, some boolean flag reversed so patch A required that I install patch B, then B required that I NOT install A. This only happened once and it was corrected a few hours later. Aside from that it's been fine.
Hope that helps. Oh, yeah I forgot this is slashdot: RTFM. ;)
Here is the dirt:
/etc/cron.daily that simply says:
RedHat RHN service:
$60 a year gets you two "entitlements" and they are $60 each afterward. You can change your entitlements to any computer as often as you want. I use one entitlement for just updating fresh installs, for instance. You can easily run a cron job by placing a script in
up2date -p
up2date -u
The -p updates their servers with all the supported packages you have installed(not necessary if you don't install anything or haven't since the last -p) and -u will update automatically. It is super easy and super cheap. There is one other big advantage.
You can NOT run a cron job and do updates from any computer using just a web browser. You log onto rhn.redhat.com then look at your computers. You can install new software, uninstall software, update systems, schedule reboots and more. I have remotely installed more than a few dozen kernel upgrades AND rebooted, with never one failure. I don't recommend remote booting ANY production box unless you like to live dangerously, however. I do tend to live dangerously.
It is highly cool, I have never seen it fail in almost 2 years, and very easy to do. You can opt for email notification if any box *needs* an update for security reasons, or not.
You can also ssh or telnet in and just run "up2date -u" and watch all the pretty # marks go by and update your computer. The download speeds are very good. In addition, you get premium access to download ISOs.
There are ways to keep a linux box updated for free, but the features that come with rhn make it a bargain for many of us. If you are not an uber-geek, or you are but have better things to do, it is a killer service. If you are a total noob, you can still understand and gain alot from it. If you are an OS snob, you will trash it because it is not as L33+ as rolling your own.
If you have to ask, then its a great service for you since it is easy to learn and unreal stable.
Tequila: It's not just for breakfast anymore!
Exceptions would be nice, but I think in most cases the cleanup is just freeing dynamically allocated memory. Solution is to get rid of the free() calls. Garbage collector, memory pools, alloca(), data stack, etc. Data stack and memory pools have worked very well with my latest project. Error handling is almost always just a return call and there's hardly any wrapper functions just for handling errors. Too bad I haven't yet had time to test how well they'd work in other kind of software. I'd guess pretty well except maybe for general purpose libraries since they require a bit different way of writing C code.
OpenSSH isn't vulnerable to this problem. We don't use OpenSSL's ASN.1 routines for network-supplied data.
OpenSSH isn't remotely vulnerable to these attacks. Recent versions don't use the OpenSSL ASN.1 parsing code for signature validation (e.g. signatures coming from the network). The OpenSSL ASN.1 code is only used for parsing private keys.
This was done a little while ago, as Markus (wisely) decided that we didn't need a whole ASN.1 parser just to verify signatures.
Don't let that slow you down patching the issue - Apache and other SSL/TLS apps (OpenLDAP, the various imapd's, etc.) may be vulnerable.
Vulnerable to denial of service attack
Potentially vulnerable to remote exploits (unknown currently)
For a client (e.g. mail client) using OpenSSL