Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×

OpenSSL Hit by Forgery Bug 69

Posted by ScuttleMonkey from the fast-fixes dept.
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."
This discussion has been archived. No new comments can be posted.

OpenSSL Hit by Forgery Bug More

OpenSSL Hit by Forgery Bug

Comments Filter:

  • who knew (Score:4, Funny)

    by User 956 ( 568564 ) on Monday September 25, 2006 @06:12PM (#16193009) Homepage
    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?
  • Slashdot. News for time travellers from just arriving here from two and half weeks ago.
    http://www.openssl.org/news/secadv_20060905.txt [openssl.org]

    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. Others too, no doubt.

    • Re: (Score:3, Informative)

      by cperciva ( 102828 )
      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 [openssl.org].

      In general you're right, though -- we hear about security issues before they go public and make sure we h

      • Re: (Score:3, Informative)

        by noahm ( 4459 )

        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.

        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.

    • if openssl also can be attacked by bug, what else should we trust to secure our data?

      paid service cant secure our data..and now even the 'secure' open source service cant secure it..so now what we should use? seriously man..what should we use?? any suggestion??

  • 1.0 (Score:4, Funny)

    by Richard W.M. Jones ( 591125 ) <rich@@@annexia...org> on Monday September 25, 2006 @06:28PM (#16193177) Homepage
    If only they'd released a 1.0 version that would never have happened...

  • old news (Score:4, Informative)

    by noahm ( 4459 ) on Monday September 25, 2006 @06:44PM (#16193347) Homepage Journal
    Wow, that was like almost a month ago. All the major, and most of the minor, OS vendors and Linux distributors have long since announced released fixes. Why's it on slashdot now?

    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 [freebsd.org] has some good info on why. To quote: (emphasis mine)

    RSA public keys may use a variety of public exponents, of which 3, 17, and 65537 are most common. As a result of a number of known attacks, most keys generated recently use a public exponent of at least 65537.
    ...
    OpenSSL will incorrectly report some invalid signatures as valid. When an RSA public exponent of 3 is used, or more generally when a small public exponent is used with a relatively large modulus (e.g., a public exponent of 17 with a 4096-bit modulus), an attacker can construct a signature which OpenSSL will accept as a valid PKCS#1 v1.5 signature.

    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

    • ``Wow, that was like almost a month ago. ... Why's it on slashdot now?''

      The first 42 submissions of a story are rejected. The next one is posted. After that, 1337 submissions are rejected before the dupe is posted.

      TINC

    • Re: (Score:2, Interesting)

      by dveditz ( 11090 )
      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.
      Unfortunately it is. While it may be true that few certs are issued with small exponents these days it doesn't really matter. Some of the pre-installed Certificate Authorities use a small exponent and you simply forge *their* signature to create a "valid" cert for any site you like.

    • Re:old news (Score:4, Informative)

      by tqbf ( 59350 ) on Monday September 25, 2006 @11:02PM (#16195277) Homepage

      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.

      • There is no security reduction from RSA to factoring, for e=3 or any other e. In fact there's strong evidence that there will never be such a reduction.

        In addition, any such security reduction won't apply to PKCS #1.5 - a proper padding method, like OAEP+, must be used for the security reduction to apply.

        There is such a reduction for e=2 aka Rabin, but that's not RSA any more, because your equations have multiple solutions. I nonetheless recommend adoption of Rabin everywhere RSA is now used, since it's b

      • Re: (Score:2)

        by fbjon ( 692006 )
        Long story short, Firefox, Opera, and Konqueror are all spoofable until you download patches.
        Indeed, Opera 9.02 was released just a week ago, fixing this.

  • Vendors have Patched As Well (Score:3, Informative)

    by miller60 ( 554835 ) on Monday September 25, 2006 @07:18PM (#16193669) Homepage
    This weakness was first described at the CRYPTO conference in August, and a technical explanation of the exploit [imc.org] was public on Aug. 27, Open SSL issued its advisory and patch [openssl.org] on Sept. 5 and the Netcraft article [netcraft.com] 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.
  • From what I remember of the earlier slashdot story, didn't it require a large tail of semi-random junk on the file, and so the consensus it was interesting but unexploitable? Or was that something else...

    • Re: (Score:1)

      by sowth ( 748135 ) *

      That sounds like the md5/sha hash issues. Though those would probably be exploitable on openssl too. Openssl supports hashes. Digital signatures are usually done by hashing the data first then signing the hash. (Because public key algorithms are usually slow, hashes are usually much faster)

      The junk shouldn't matter. How often do you look at the source html or all the fields of a cert on secure pages? Probably never. There may be an area or field of certs which most program don't even show, so even if you

  • First a huge raft of problems in gzip, now this. Thank you, Google. But you have to wonder--is there a point at which fewer security issues will be found in system software? I mean, it's gzip! It's not like it's some new whizbang technology; this has been around for more than ten years. The real question to be asked is why we're still finding these problems now.
  • Firefox/Thunderbird had this fix applied in 1.5.0.7, released on 2006/09/14.
    Seamonkey had this fix applied in 1.0.5, released on 2006/09/14.
    Opera had this fix applied in Opera 9.02, released on 2006/09/21.
  • I had submitted the same news on 6th but was rejected by editor.
      http://www.heise-security.co.uk/news/77800 [heise-security.co.uk]

  • if anyone wonder..here is the definition of OpenSSL.. courtesy of wikipedia.org...

    OpenSSL is an open source implementation of the SSL and TLS protocols. The core library (written in the C programming language) implements the basic cryptographic functions and provides various utility functions. Wrappers allowing the use of the OpenSSL library in a variety of computer languages are available.

    Versions are available for most Unix-like operating systems (including Solaris, Linux, Mac OS X and the four ope
  • It's been stated in Help Net Security that the only solution to this problem is to:
    Upgrade to version 0.9.8c, 0.9.7k or higher, as it has been reported to fix this vulnerability. An upgrade is required as there are no known workarounds.
    'No known workarounds' seems like quite an exxageration!
    It's normal for technologies to be upgraded, right? But u have to admit though.. everything seems to require regular upgrading nowadays. At least once! Even humans need a so-called self-upgrading. What more t
  • "OpenSSL versions up to 0.9.7j and 0.9.8b" The software package created above is not a predictable program because it is vulnerable to signature forgery technique although it uses strong cryptography.
  • There are multiple ways to avoid this vulnerability. Any one of the following measures is sufficient. 1. Upgrade the OpenSSL server software. The vulnerability is resolved in the following versions of OpenSSL: - in the 0.9.7 branch, version 0.9.7k (or later); - in the 0.9.8 branch, version 0.9.8c (or later). OpenSSL 0.9.8c and OpenSSL 0.9.7k are available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.o [openssl.org]
  • although this bug has been fixed in ssl. browsers are also affected by it. the attack requires that one of the accepted certificate authorities uses an RSA key with the exponent 3. all of the major browsers have such a CA. browsers like IE and safari are not affected by this. In firefox however it is affected but there already exists a fix from version 1.5.0.7 so no need to worry if youre using firefox and youre up to date. konqueror meanwhile uses opsnssl libraries and is not affected is it is up to date.
  • oh then jus update it!! that is why we have many versions dont we.
  • OpenSSL 0.9.8 was released on July 5, 2005 announcement. OpenSSL 0.9.7 was released on December 31, 2002. OpenSSL 0.9.6 was released on September 25, 2000. OpenSSL 0.9.5 was released on February 28, 2000. OpenSSL 0.9.4 was released on August 9, 1999. OpenSSL 0.9.3 was released on May 25, 1999.

Slashdot Top Deals

Live free or die.

Close