Slashdot Mirror
OpenSSL Hit by Forgery Bug
Daniel Cray writes to tell us ZDNet is reporting that OpenSSL versions up to 0.9.7j and 0.9.8b are vulnerable to a signature forgery technique. OpenSSL has already released an update fixing the problem. From the article: "The flaw only affects a particular type of signature — PKCS #1 v1.5 signatures — but these are used by some certificate authorities... The signature forgery technique was first demonstrated last month at the Crypto 2006 conference by Daniel Bleichenbacher, a cryptographer with Bell Labs, according to security firm Netcraft. OpenSSL credited Google Security with successfully forging various certificates and providing the fix."
"No matter where you go, there you are." -- Buckaroo Banzai
more like,
all your certs are belong to me
ZDNet is reporting that OpenSSL versions up to 0.9.7j and 0.9.8b are vulnerable to a signature forgery technique.
Who knew that OpenSSL would have ever had anything in common with a Wal-Mart cashier?
The theory of relativity doesn't work right in Arkansas.
If only they'd released a 1.0 version that would never have happened...
libguestfs - tools for accessing and modifying virtual machine disk images
It also needs to be noted that the impact of this bug is not nearly as wide as a slashdot front-page headline might suggest. The FreeBSD security advisory has some good info on why. To quote: (emphasis mine)
So yeah, there may be some vulnerable sites out there, but they were already weaker than they should have been, and most sites are likely unaffected. That, coupled with the simplicity of the fix (both as provided in source form and from the OS vendors) makes this a non-story.
noah
This weakness was first described at the CRYPTO conference in August, and a technical explanation of the exploit was public on Aug. 27, Open SSL issued its advisory and patch on Sept. 5 and the Netcraft article cited by ZDNet has been online since Sept. 7. So while this is a potentially problematic security issue, it's not brand new, has been patched by OpenSSL and quite a few vendors have issued patches as well.
RichM
Data Center Knowledge
I would hope that all serious users of OpenSSL have already patched this. FreeBSD and Debian were on top of it the same day it was announced.
I don't know about Debian, but FreeBSD didn't issue an advisory until the day after this went public. We have a very strict policy about making sure that security updates won't break anything, and OpenSSL's original patch was broken and not fixed until a day later.
In general you're right, though -- we hear about security issues before they go public and make sure we have advisories and patches ready.
Tarsnap: Online backups for the truly paranoid
I use Tic-Tacs you insensitive clod!
==============
openssl (0.9.8a-7ubuntu0.1) dapper-security; urgency=low
* SECURITY UPDATE: signature forgery in some cases.
* Apply http://www.openssl.org/news/patch-CVE-2006-4339.tx t:
- Check excessive data in padding of PKCS #1 v1.5 signatures to prevent applications from incorrectly verifying the certificate.
* References:
CVE-2006-4339
http://www.openssl.org/news/secadv_20060905.txt
It wasn't really per se, but it did contain some unnecessary code. None of it was major, and I don't think it would have caused any problems, but the revised patch, which we in Debian also used, touched fewer files and was generally simpler.
noah
This isn't really a problem with buggy coding - it's a crypto math problem that is affected by implementation choices, and new crypto discoveries can hit some code harder than others. The code here was checked very thoroughly by *lots* of people, including some really strong crypto experts, because it's critical code for a lot of people. With RSA signatures, there's a public exponent "e" and a private exponent "d", and e is a pretty arbitrary prime, so it's common to pick a value that lets you do fast calculations. The popular values are 3, 65537, and occasionally 17, and it's hard to find a number x such that x**e mod n == y if you don't know d (or p and q.) The problem is that it's not so hard to find x and some junk such that (x,junk)**e mod n == (y,otherjunk), at least if e is small enough, and the standard ASN.1 code makes it easy to add arbitrary junk. 3 is small enough (and really fast to use), 17 might be, 65537 is pretty safe, and ASN.1 is the Mos Eisley of data representation protocols, a wretched hive of scum and villainy that nobody wants to mess around in. So some people do the right thing in checking the "otherjunk" beyond the y, but not everybody did, and until Bleichenbacher's attack you didn't need to.
Open Source does mean that you *can* update your copy of OpenSSL, without waiting for Microsoft Patch Day - and in the crypto world, the only way to trust anything is for the algorithms and implementation code to be documented and readable. They don't have to be "open" in the sense of "accepting patches from arbitrary people" or "free as in speech, not patented, not copyrighted, guaranteed to make RMS happy", but if you can't see the algorithms or install code you've recompiled from scratch yourself, you can't trust it.
So the fact that you've got to update OpenSSL and link it in to other code is really fine here - if you're paranoid, you need to do it yourself, and you've got the tools to do it; if you're not paranoid, this is a fairly tough exploit to actually do anything useful with, though you could go deleting a few certificates from your browser's security files if you're worried.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
No, the impact of this problem was wider than what the front page suggests; the same bug hit Firefox (which uses its own "NSS" SSL library, not OpenSSL), and several of the root certificates were e=3 (e=3 is a widely-recommended optimization). Long story short, Firefox, Opera, and Konqueror are all spoofable until you download patches.
The simple exploit (generate a new WELLSFARGO.COM cert and "sign" it in a way that will trick a browser into believing a root CA signed it) is literally 3 lines of Python.
You're also wrong about the crypto details: e=3 RSA is not "weaker" than e=65537. The problem is not that people used "weak" RSA parameters; the problem is that they didn't verify all the bits in an RSA-decoded signature, but instead tried to fish something that looked like a valid SHA/MD5 hash out of it. If you screw up any of the details in RSA signature verification, you're screwed, e=3, e=5, or e=65537. Conversely if you get the details right, e=3 is as secure as factoring.
It is funny that this is just hitting Slashdot now; it's weeks old.