Major OpenSSL Security Issue Found (and Fixed)

← Back to Stories (view on slashdot.org)

Major OpenSSL Security Issue Found (and Fixed)

Posted by timothy on Thursday April 19, 2012 @01:53AM from the resume-transmission dept.

tearmeapart writes "A major security issue has been found in all OpenSSL packages. You probably want to download your preferred OpenSSL package as soon as possible. Changes to the CVS repository are detailed on the OpenSSL timeline."

78 comments

Min score:

Reason:

Sort:

Anyone want to translate this into dummy speak? by mallyone · 2012-04-19 02:00 · Score: 3, Interesting

Is this a remote exploit? Does this mean my client can be overrun if a server throws me a bad packet or two? I guess my other question is, how can the most utilized utility on a system still have unchecked overflows? It has to have been audited about a trillion times? Please help, half assed linux admins want to know!
1. Re:Anyone want to translate this into dummy speak? by arglebargle_xiv · 2012-04-19 02:04 · Score: 5, Informative
  
  Is this a remote exploit?
  Yes.
  
  Does this mean my client can be overrun if a server throws me a bad packet or two?
  Yes.
  
  I guess my other question is, how can the most utilized utility on a system still have unchecked overflows?
  Have you ever looked at the OpenSSL code? It could have the Ark of the Covenant hidden in all that mess somewhere for all we know and we'd never find it.
2. Re:Anyone want to translate this into dummy speak? by ledow · 2012-04-19 02:10 · Score: 5, Informative
  
  Truly, the OpenSSL code is quite hideous. I mean, from what I saw they basically wrap calls to realloc and that was part of the problem because they did it half-assedly.
  But even the API is a horrible nightmare to use and documentation is scant. Sure you can find a billion *examples* that have all copied from the examples given in the source distribution (which were third-party contributed) but actually finding out what's necessary or important is almost impossible from the documentation. You literally have to either copy the (pretty much undocumented) example, or roll your own and hope for the best.
  I wrote some code using OpenSSL a while back to verify two PEM certificates (one signing the other). God, was that a trek through uncharted territory. In the end, I just made a "broken" certificate chain with fake / broken certificates in every way I could imagine and just kept testing my code until I'd taken account of every problem with the certs that I could reasonably generate myself. Even getting the plain certificate name out of certificate can be an exercise in guesswork.
  I'm not at all surprised, to be honest. And that it was something as simple and obvious (and hidden behind deliberate casts that would stop the compiler warnings) is hardly a shock, once you've tried to plough through their code.
3. Re:Anyone want to translate this into dummy speak? by Trepidity · 2012-04-19 02:15 · Score: 5, Informative
  
  Have you ever looked at the OpenSSL code? It could have the Ark of the Covenant hidden in all that mess somewhere for all we know and we'd never find it.
  That's one reason OpenSSH has been moving towards more restricted/careful use of OpenSSL, and I believe in this case it actually makes OpenSSH not vulnerable, because this is (yet another) bug in the ASN.1 parser, and OpenSSH doesn't use the OpenSSL ASN.1 parser anymore. Sometime a few years ago they replaced it with a minimal, special-cased, audited internal version, which can't handle full ASN.1, but can handle the subset used in OpenSSH. See section 3.2 of this paper (pdf) for a bit more.
  
  --
  10 PRINT CHR$(205.5+RND(1)); : GOTO 10
4. Re:Anyone want to translate this into dummy speak? by Anonymous Coward · 2012-04-19 02:16 · Score: 2, Interesting
  
  Right. I've posted elsewhere that the documentation, what there is of it, is obscure and minimal. I'd probably get the O'Reilly book if I had to work with it again - not sure how good that is but it has to be better than the docs.
5. Re:Anyone want to translate this into dummy speak? by IamTheRealMike · 2012-04-19 02:18 · Score: 5, Informative
  
  Are you sure about that?
  The advisory says that SSL/TLS code is not affected, and only software that parses ASN.1/DER structures from BIO or FILE streams could be impacted. Parsing ASN.1 from memory is also not affected. That would appear to restrict the vulnerable software quite a bit.
  Whether you have a remote vulnerability or not would seem to depend very highly on what software you're running.
6. Re:Anyone want to translate this into dummy speak? by swillden · 2012-04-19 02:24 · Score: 5, Interesting
  
  I guess my other question is, how can the most utilized utility on a system still have unchecked overflows?
  Have you ever looked at the OpenSSL code? It could have the Ark of the Covenant hidden in all that mess somewhere for all we know and we'd never find it.
  No kidding. I've seen a lot of horrible messes in my career, but OpenSSL tops them all. There have to be hundreds of serious security bugs lurking in there... the only thing saving us is that it's so nasty not even the black hats want to dig in there to find them. Good security code should be as simple and straightforward as possible, to make it easy to verify. The authors of OpenSSL took a... different approach.
  
  --
  Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
7. Re:Anyone want to translate this into dummy speak? by lipanitech · 2012-04-19 02:25 · Score: 0
  
  This does not shock me in the least as any technology gets more and more popular vulnerability and bugs come to the surface.
  
  --
  http://thetechnologygeek.org/
8. Re:Anyone want to translate this into dummy speak? by slim · 2012-04-19 02:40 · Score: 3, Insightful
  
  Have you ever looked at the OpenSSL code? It could have the Ark of the Covenant hidden in all that mess somewhere for all we know and we'd never find it.
  Yeah. OpenSSL has a problem -- it's good enough.
  It's poorly documented. It triggers all kinds of compiler warnings if you turn them on. Valgrind throws up all kinds of complaints. The code is really hard to grok.
  As a user of the API, there are all kinds of gotchas. Best practice isn't reflected in the defaults; you have to pick up the best flags to pass in by examining how other people have done it, or asking around.
  But, it's good enough that so far nobody's thought it's worth the effort to write a new SSL library from scratch.
  It's good enough that so far nobody's thought it's worth the effort to really firm up the free documentation (so, buy the O'Reilly book instead).
  After all, you go through a bunch of pain understanding enough of OpenSSL to put it in your app -- but you only go through that pain once, and after that, it works.
9. Re:Anyone want to translate this into dummy speak? by skids · 2012-04-19 02:40 · Score: 1
  
  FWIW, an SSL BIO can be a network socket. I'm not sure (or qualified to be) if the claims that this only effects work on disk-stored certificates are correct.
  
  --
  Someone had to do it.
10. Re:Anyone want to translate this into dummy speak? by Coward+Anonymous · 2012-04-19 02:41 · Score: 4, Insightful
  
  "because this is (yet another) bug in the ASN.1 parser"
  This is because ASN.1 is an insanely complex, wasteful and redundant standard that should have never been adopted for security related standards where simplicity is an important contributor to writing secure code.
  ASN.1 has been the bane of all the standards that ever adopted it (SNMP anyone?) and should have been shot years ago.
11. Re:Anyone want to translate this into dummy speak? by Anonymous Coward · 2012-04-19 02:49 · Score: 0
  
  Dude, your handle is awesome.
12. Re:Anyone want to translate this into dummy speak? by dkf · 2012-04-19 02:56 · Score: 1
  
  Good security code should be as simple and straightforward as possible, to make it easy to verify. The authors of OpenSSL took a... different approach.
  <sarcasm> It must be correct, it has no obvious bugs (instead of having obviously no bugs, which is only for lamers and ivory tower types). </sarcasm>
  
  --
  "Little does he know, but there is no 'I' in 'Idiot'!"
13. Re:Anyone want to translate this into dummy speak? by Anomalyst · 2012-04-19 03:10 · Score: 1
  
  ASN.1 has been the bane of all the standards that ever adopted it (SNMP anyone?) and should have been shot years ago.
  So what is the alternative?
  While I grasp teh main concepts of snetwork security, I'm relatively ignorant of the nitty gritty details of endpoint security negotiation, what, if any, is a better alternative to ASN and is there a URL that might hint how one might configure it (indicate a preference) for SSH or SSL connections.
  
  --
  There is no right to feel safe thru security vaudeville at the expense of everyone's freedom, privacy and tax money.
14. Re:Anyone want to translate this into dummy speak? by Qzukk · 2012-04-19 03:16 · Score: 4, Informative
  
  it's good enough that so far nobody's thought it's worth the effort to write a new SSL library from scratch.
  Except for GNU's gnutls, but they did it because their only problem with openssl it is that it's BSD licensed.
  
  --
  If I have been able to see further than others, it is because I bought a pair of binoculars.
15. Re:Anyone want to translate this into dummy speak? by slim · 2012-04-19 03:18 · Score: 1
  
  My assumption (and no, I'm not looking at the code) would be that the SSL/TLS handshake would involve parsing certificates (which contain ASN.1) supplied by the remote host, which you'd be reading from a socket wrapped in a BIO stream. Is that not the case?
  I guess it's not unlikely that by happenstance, the SSL/TLS handshake reads the entire certificate into memory then parses that. But is that confirmed?
16. Re:Anyone want to translate this into dummy speak? by mallyone · 2012-04-19 03:26 · Score: 1
  
  hehe, I have trouble looking at the changelogs let alone the code :). I guess ignorance is bliss, I was thinking openssl was a nice simple protocol that made everything 100% secure. It's nice living in my bubble where nothing can harm me! :). P.S. I always thought the arc of the Covenant was in AtheOs. :P
17. Re:Anyone want to translate this into dummy speak? by PybusJ · 2012-04-19 03:27 · Score: 5, Informative
  
  But, it's good enough that so far nobody's thought it's worth the effort to write a new SSL library from scratch.
  Err, yes, apart from GnuTLS, Mozilla's NSS, Gutmann's cryptlib, yaSSL (there's enough to name one yet another ...), Polar SSL, and probably more -- and that's only counting C libraries available under an open source license.
18. Re:Anyone want to translate this into dummy speak? by Nimey · 2012-04-19 03:34 · Score: 1
  
  How's the code quality on gnutls?
  Pity about the license being more restrictive; that'd keep it out of proprietary operating systems.
  
  --
  Hail Eris, full of mischief...
  
  E pluribus sanguinem
19. Re:Anyone want to translate this into dummy speak? by slim · 2012-04-19 03:35 · Score: 1
  
  Blast you and your facts.
  OK, let me revise that. It's good enough that so far no replacement SSL library has been any near as widely adopted.
  It's "Nobody ever got fired for using OpenSSL" territory.
  Years ago when I worked for IBM, we used IBM's internal GSKIT SSL libraries -- at around the time I left, they were bringing OpenSSL code into GSKIT, and many of their products were adopting OpenSSL instead of GSKIT.
  Thanks for drawing NSS to my attention. I had always assumed Netscape and Mozilla used OpenSSL.
20. Re:Anyone want to translate this into dummy speak? by Vellmont · 2012-04-19 03:44 · Score: 3, Informative
  
  Is this a remote exploit?
  
  Yes.
  
  Does this mean my client can be overrun if a server throws me a bad packet or two?
  
  Yes.
  Based on the advisory, I can't fully agree with either of these statements.
  The advisory states:
  
  Any application which uses BIO or FILE based functions to read untrusted DER
  format data is vulnerable.
  DER is a format for the certificate key. For the most part it's relatively rare to handle untrusted certificate keys. I suppose it's possible if you're doing some form of authenticating the client end as well as the server end via SSL.
  Please correct me if I'm wrong, but I don't see much evidence this vulnerability is anything worth worrying about for the vast majority of people.
  Advistory at: http://www.openssl.org/news/secadv_20120419.txt
  
  --
  AccountKiller
21. Re:Anyone want to translate this into dummy speak? by PybusJ · 2012-04-19 04:18 · Score: 2
  
  I'm guessing it's the fact a random hacker looking to "add some security" to their project has heard of OpenSSL and already has it on their system.
  Most developers are not security experts so will assess a library on awareness, features, reputation etc.; assessing security is not easy so the choice is almost certainly made on the other factors, and it's rational not to trust a library you've not heard of before for security. The other libraries have their own limitations/missing features or other warts which might push you towards OpenSSL.
  Personally, I'd trust GnuTLS over OpenSSL, but then not all projects are happy using an LGPL library.
  I'd be even more happy if someone made the effort to provide a TLS implementation which was proved correct. Code proofs are a lot of work, but SSL/TLS is so widely used that it ought to repay the effort.
22. Re:Anyone want to translate this into dummy speak? by bill_mcgonigle · 2012-04-19 04:48 · Score: 3, Insightful
  
  There have to be hundreds of serious security bugs lurking in there... the only thing saving us is that it's so nasty that the black hats who put in the effort to find the bugs for their governments or corporate espionage clients get paid damn well for their work and wouldn't dream of disclosing their findings.
  TFTFY
  
  --
  My God, it's Full of Source!
  OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
23. Re:Anyone want to translate this into dummy speak? by skids · 2012-04-19 05:12 · Score: 1
  
  It's that the commonly used code uses a stripped down ASN.1 parser, not the OpenSSL one.
  
  --
  Someone had to do it.
24. Re:Anyone want to translate this into dummy speak? by Trepidity · 2012-04-19 05:31 · Score: 2
  
  There's not much to do about it as an end user; it's part of the protocol. I think the parent poster is just arguing that adopting ASN.1 in the definition of your protocol is a bad idea, so future protocols should avoid doing so.
  
  --
  10 PRINT CHR$(205.5+RND(1)); : GOTO 10
25. Re:Anyone want to translate this into dummy speak? by Anonymous Coward · 2012-04-19 06:27 · Score: 0
  
  Thanks for drawing NSS to my attention. I had always assumed Netscape and Mozilla used OpenSSL.
  No, they stuck with their own, even older and cruftier code base. And now apparently Red Hat is trying to standardize on it, when a more appropriate choice for them would be to drive gnuTLS forwards.
26. Re:Anyone want to translate this into dummy speak? by mysidia · 2012-04-19 06:34 · Score: 2
  
  Is this a remote exploit?
  For some applications, it will be, please see the advisory
  Any application which uses BIO or FILE based functions to read untrusted DER format data is vulnerable. Affected functions are of the form d2i_*_bio or d2i_*_fp, for example d2i_X509_bio or d2i_PKCS12_fp.
  Applications using the memory based ASN1 functions (d2i_X509, d2i_PKCS12 etc) are not affected. In particular the SSL/TLS code of OpenSSL is *not* affected.
  Applications only using the PEM routines are not affected. S/MIME or CMS applications using the built in MIME parser SMIME_read_PKCS7 or SMIME_read_CMS *are* affected.
27. Re:Anyone want to translate this into dummy speak? by TechyImmigrant · 2012-04-19 08:34 · Score: 1
  
  >So what is the alternative?
  Specifying the encoding of your information in the specification of whatever it is you are specifying.
  E.G. "The length field is encoded as a 4 byte, unsigned integer in big endian byte order in bytes 3 to 6 of the packet"
  
  --
  I should use this sig to advertise my book ISBN-13 : 978-1501515132.
28. Re:Anyone want to translate this into dummy speak? by TechyImmigrant · 2012-04-19 08:41 · Score: 2
  
  >DER is a format for the certificate key.
  DER is a format for the certificate. The type a server sends to you in a https sesssion setup.
  
  --
  I should use this sig to advertise my book ISBN-13 : 978-1501515132.
29. Re:Anyone want to translate this into dummy speak? by Anonymous Coward · 2012-04-19 08:52 · Score: 1
  
  gnutls: (both from march 2012)
  http://www.vuxml.org/freebsd/CVE-2012-1569.html
  http://www.vuxml.org/freebsd/CVE-2012-1573.html
30. Re:Anyone want to translate this into dummy speak? by CAIMLAS · 2012-04-19 10:32 · Score: 1
  
  No kidding. I've seen a lot of horrible messes in my career, but OpenSSL tops them all.
  
  I take it you don't have to work with OpenLDAP, then.
  
  --
  ~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
31. Re:Anyone want to translate this into dummy speak? by JoelKatz · 2012-04-19 11:59 · Score: 2
  
  Those claims are correct. While an SSL BIO could be a network socket, the ASN1 code never talks directly to the SSL BIO code. The SSL protocol has to be parsed first to find the ASN1 structures, and by that time, they're not in the SSL BIO any more.
32. Re:Anyone want to translate this into dummy speak? by Anonymous Coward · 2012-04-19 14:49 · Score: 0
  
  I thought it was Coward Anonymous.
33. Re:Anyone want to translate this into dummy speak? by Anonymous Coward · 2012-04-19 14:59 · Score: 0
  
  >So what is the alternative?
  Specifying the encoding of your information in the specification of whatever it is you are specifying.
  E.G. "The length field is encoded as a 4 byte, unsigned integer in big endian byte order in bytes 3 to 6 of the packet"
  You forgot to specify whether the first byte of the packet is byte 0 or byte 1.
34. Re:Anyone want to translate this into dummy speak? by Roachie · 2012-04-19 15:05 · Score: 1
  
  The O'Reilly book is a good choice. However, I would like to point out that every line of the OpenSSL source is completely documented, in C, you just have to be willing to go down the rabbit hole.
  
  --
  This sig is not paradoxical or ironic.
35. Re:Anyone want to translate this into dummy speak? by Roachie · 2012-04-19 15:08 · Score: 1
  
  No kidding. I've seen a lot of horrible messes in my career, but OpenSSL tops them all.
  You should peruse QMail. Just keep all sharp objects away lest you be overwhelmed by the temptation to gouge out your own eyes.
  
  --
  This sig is not paradoxical or ironic.
36. Re:Anyone want to translate this into dummy speak? by arglebargle_xiv · 2012-04-19 16:13 · Score: 1
  
  For the most part it's relatively rare to handle untrusted certificate keys. I suppose it's possible if you're doing some form of authenticating the client end as well as the server end via SSL.
  It really depends. If you're using OpenSSL purely as an SSL server and never use client certs then you should be OK (there are some weird-ass things involving OCSP response pinning where you can still get the server if you can impersonate the CA that it gets the OCSP info from, but that's getting a bit esoteric and I'm not sure how far OpenSSL supports that stuff yet). OTOH if you use client certs, or use it to run an OCSP server, or a CA, or do any kind of cert processing (including the relatively common use of 'openssl x509 ...' as a cert-handling swiss-army-chainsaw) then you're vulnerable. So I'd say it is of general concern, because so many things that involve using OpenSSL end up bringing it into contact with certs or other ASN.1 data.
  I'd be patching pretty quickly, in any case.
37. Re:Anyone want to translate this into dummy speak? by Vellmont · 2012-04-19 17:58 · Score: 0
  
  Why should you bother to patch the vulnerability if like 99.9% of people you don't deal with client certs, run an OCSP server, or a CA?
  
  --
  AccountKiller
38. Re:Anyone want to translate this into dummy speak? by TechyImmigrant · 2012-04-19 20:06 · Score: 1
  
  They'll sort that out in interop testing.
  
  --
  I should use this sig to advertise my book ISBN-13 : 978-1501515132.
39. Re:Anyone want to translate this into dummy speak? by Reality+Master+301 · 2012-04-19 23:39 · Score: 1
  
  No: http://slashdot.org/~awesome
It only affects 64 bit systems by hamjudo · 2012-04-19 02:03 · Score: 4, Informative

"Only" a problem for systems where size_t is different from int. So the 15% of you still running in a 32 bit world can rest easy. This also means that on a mixed 32/64 bit system, you could use 32bit libraries until you get around to patching everything. Remember, a whole bunch of stuff uses ssl. Have fun fixing your Java jars.
1. Re:It only affects 64 bit systems by Anonymous Coward · 2012-04-19 02:09 · Score: 4, Informative
  
  Yet another reason you why you fuckerlords who ignore standards and types like size_t and intptr_t need to choke.
2. Re:It only affects 64 bit systems by Anonymous Coward · 2012-04-19 02:23 · Score: 2, Interesting
  
  I'm sorry, but that's just bad programming. When I took C 15 years ago in college, one of the very first lessons was the professor telling the class to never assume data size.
  Data type sizes is something we knew about and resolved over 30 years ago, so it makes me sad we still encounter this today.
3. Re:It only affects 64 bit systems by Anonymous Coward · 2012-04-19 02:30 · Score: 0
  
  Well, good thing I'm a luddite and all of my boxes are still 32 bit then. I knew delaying the purchase of a new laptop would pay off someday.
4. Re:It only affects 64 bit systems by jonwil · 2012-04-19 02:48 · Score: 1
  
  Does this affect ARM platform devices like my Nokia N900?
5. Re:It only affects 64 bit systems by Gaygirlie · 2012-04-19 04:04 · Score: 1
  
  The N900 is a 32-bit system.
6. Re:It only affects 64 bit systems by Chemisor · 2012-04-19 04:17 · Score: 2
  
  It's perfectly acceptable to assume the size of data types, as long as you use the data types with defined sizes, such as uint8_t, uint16_t, uint32_t, and uint64_t. stdint FTW.
7. Re:It only affects 64 bit systems by StikyPad · 2012-04-19 04:22 · Score: 4, Informative
  
  I don't think that's accurate. According to the incident report, the problem is passing a signed int to a function expecting an unsigned int. That means passing unsigned values > 2^(n-1)-1 will cause unexpectedly large allocations leading to a heap overflow regardless of whether n is 32, 64, or 8.
  According to the incident report: Producing DER data to demonstrate this is relatively easy for both x86 and x64 architectures.
  But I could be wrong...
  
  --
  https://www.eff.org/https-everywhere
8. Re:It only affects 64 bit systems by TechyImmigrant · 2012-04-19 08:43 · Score: 1
  
  >Data type sizes is something we knew about and resolved over 30 years ago, so it makes me sad we still encounter this today.
  ASN.1 was supposed to fix that. Yes there is irony in there somewhere.
  
  --
  I should use this sig to advertise my book ISBN-13 : 978-1501515132.
9. Re:It only affects 64 bit systems by GameboyRMH · 2012-04-19 08:57 · Score: 1
  
  Don't kid yourself, at this point the N900 is protected mostly by obscurity. The version of Flash on there is riddled with holes and the mozilla-based browser probably is too.
  
  --
  "When information is power, privacy is freedom" - Jah-Wren Ryel
10. Re:It only affects 64 bit systems by Anonymous Coward · 2012-04-19 09:27 · Score: 0
  
  Interesting to note is this line of code in particular:
  n = (len + 3)/3*4
  (see: http://fossies.org/dox/openssl-0.9.8u/crypto_2buffer_2buffer_8c_source.html line 145--looks like they fixed the function to accept an int and also check for the problem below)
  Assuming size_t is 32 bits, if len is the value 0xBFFFFFFD or greater (-1073741827 = len = -1 if it were a signed 32 bit number) then there will be an overflow, and n will potentially be smaller than the buffer being copied into. I think you're right: the actual size of the size_t isn't super relevant here. What's more important is that this overflow will cause CRYPTO_realloc_clean to be called with the buffer, the correct old size, and the new size (which is now likely smaller due to the overflow), and they use a simple memcpy from there to copy the old buffer into the new one after mallocing it, and we get heap corruption.
  Now, if size_t is 64 bits, then the negative number is just sign extended, we have a similar problem due to truncation, and there is overflow if len is the value 0xBFFFFFFFFFFFFFFD or greater (e.g -4611686018427387907 = len = -1). Now, because the function calling this one is doing just plain 32 bit arithmetic, if there is an overflow, the range of values for len will be 0xFFFFFFFF80000000 to 0xFFFFFFFFFFFFFF, which places all overflow in the calling function squarely in the danger zone here for 64 bit architectures as well.
  So unless I'm wrong (and I very well could be!), this is also a vulnerability on 32 bit platforms. In the message, it says that LP64 is sometimes required, but I suspect that has something to do with the actual heap corruption than this little bug here that's leading to it.
11. Re:It only affects 64 bit systems by Anonymous Coward · 2012-04-19 09:32 · Score: 0
  
  Correction: first paragraph, I said "n will potentially be smaller than the buffer being copied into" but I meant to say "n will potentially be smaller than size of the buffer being copied from".
12. Re:It only affects 64 bit systems by Anonymous Coward · 2012-04-19 10:06 · Score: 0
  
  Correction 2: Must be having a brainfart today. In my first paragraph, I said "which is now likely smaller due to the overflow", but it will actually ALWAYS be less than or equal to the original size in the case of an overflow.
13. Re:It only affects 64 bit systems by jonwil · 2012-04-19 12:19 · Score: 1
  
  Even more reason for me to support the efforts to port a more recent Gecko run-time to the thing :)
14. Re:It only affects 64 bit systems by Just+Some+Guy · 2012-04-19 17:12 · Score: 1
  
  It's perfectly acceptable to assume the X of Y, as long as you use the Y's with defined X's
  I don't think "assume" means what you think it means.
  
  --
  Dewey, what part of this looks like authorities should be involved?
15. Re:It only affects 64 bit systems by WaffleMonster · 2012-04-19 17:31 · Score: 1
  
  "Only" a problem for systems where size_t is different from int. So the 15% of you still running in a 32 bit world can rest easy. This also means that on a mixed 32/64 bit system, you could use 32bit libraries until you get around to patching everything. Remember, a whole bunch of stuff uses ssl. Have fun fixing your Java jars.
  This advice is wrong. The problem exists in 32 and 64bit libraries. Using 32-bit binaries will NOT protect you from this problem.
  The issue is a signed/unsigned mismatch when the unsigned number reaches 2^31 and gets passed to a signed variable it is treated as a negative number with catastrophic results.
16. Re:It only affects 64 bit systems by Thuktun · 2012-04-25 06:48 · Score: 1
  
  Remember, a whole bunch of stuff uses ssl. Have fun fixing your Java jars.
  I greatly doubt Java's baked-in SSL functionality uses OpenSSL.
Re:Security issue how? by ledow · 2012-04-19 02:15 · Score: 3, Informative

If you handle on-disk certificates using a program (e.g. Apache, which reads them from /etc/ssl), there's a potential for arbitrary code execution (literally, the attacker writing what they want to the heap).
Now think about browser's cached certificates, or a browser that might write them to disk and then read them from there rather than the network, or utilities that "do things" with PEM certificates, or basically anything that uses SSL with an on-disk certificate that could come from a malicious source.
No, your browser's SSL session is probably still quite safe, but it's far from being a non-issue from a security standpoint.
Re:Security issue how? by gQuigs · 2012-04-19 02:18 · Score: 3, Informative

From TFA:
"The old data is always copied over, regardless of whether the new size will be
enough. This allows us to turn this truncation into what is effectively:
memcpy(heap_buffer, , );"
Letting the attacker write to arbitrary/unexpected memory is always a security issue... [I guess it might not be easily exploitable in all cases based on system setup/random memory allocation, etc though]
CVS repository? by honestmonkey · 2012-04-19 02:43 · Score: 3, Funny

Well, I guess I don't care then, because we only have Walgreens around here.

--
Everything you know is wrong, Just forget the words and sing along.
1. Re:CVS repository? by Anonymous Coward · 2012-04-19 03:36 · Score: 0
  
  Dude, Walgreen's was hacked last Tuesday. Netcraft confirmed it, and Microsoft, IBM, and CNN called it the worst virus ever. All you ibuprofen gets replaced by these furry dancing bears. Look at your jdbgmgr.exe file, if its icon is a teddy bear, then you are already infected.
ssh? by MMC+Monster · 2012-04-19 02:44 · Score: 3, Funny

How does this effect ssh?
I've got a few systems running older distributions or custom distributions with little or no support that I ssh into.
One of them (http://www.readynas.com/?cat=3) has ssh exposed to the internet (not on port 22, but still...).
Is this something I need to worry about?
(Sorry in advance for my lack of specific geekdom to figure out the answer to this myself.)

--
Help! I'm a slashdot refugee.
1. Re:ssh? by realxmp · 2012-04-19 03:19 · Score: 0
  
  None. SSH does not use SSL.
2. Re:ssh? by realxmp · 2012-04-19 03:24 · Score: 1
  
  Actually scratch my previous assertion. Some distributions of SSH use OpenSSL (not in the SSL tunnel sense, but for certificates etc).
3. Re:ssh? by realxmp · 2012-04-19 03:25 · Score: 1
  
  Ignore this post I had forgotten certificates.
4. Re:ssh? by Pionar · 2012-04-19 03:32 · Score: 2
  
  As someone else said, this is a bug in the ASN.1 parser, and OpenSSH uses it's own specialized ASN.1 parser. So it's not.
5. Re:ssh? by Anonymous Coward · 2012-04-19 07:15 · Score: 0
  
  SSH doesn't use X.509 ASN.1 certificates either, so resurrect post.
Security vs functionality by Anonymous Coward · 2012-04-19 03:20 · Score: 3, Informative

> You probably want to download your preferred OpenSSL package as soon as possible
No, you don't. The latest OpenSSL has problems connecting to facebook.com and paypal.com (they filter Client Hello packets larger than 255 bytes, and, unfortunately, OpenSSL creates those). Please see http://bugs.debian.org/665452
1. Re:Security vs functionality by ShaunC · 2012-04-19 03:41 · Score: 4, Funny
  
  The latest OpenSSL has problems connecting to facebook.com and paypal.com
  Sounds like a feature, not a bug.
  
  --
  Thanks to the War on Drugs, it's easier to buy meth than it is to buy cold medicine!
Messy Code.... by Anonymous Coward · 2012-04-19 03:51 · Score: 0

It's cause they're cryptographers, not coders
1. Re:Messy Code.... by TechyImmigrant · 2012-04-19 08:46 · Score: 2
  
  >It's cause they're cryptographers, not coders
  Good cryptographers write extremely simple and clear code.
  Those that don't are failing.
  
  --
  I should use this sig to advertise my book ISBN-13 : 978-1501515132.
Chrome uses OpenSSL by Anonymous Coward · 2012-04-19 09:05 · Score: 0

Chrome relies on OpenSSL.
To check this visit:
about:credits
1. Re:Chrome uses OpenSSL by makomk · 2012-04-19 10:10 · Score: 1
  
  I think Chrome uses a fork of NSS for its SSL support though.
Re:It affects ALL systems by hamjudo · 2012-04-19 09:33 · Score: 1

But I could be wrong...
The article says: "Some attack vectors require an I32LP64 architecture, others do not.".
So StikyPad is right, and I was wrong.
69.55.55.93 caught trying to exploit recent SSL vu by Anonymous Coward · 2012-04-20 09:50 · Score: 0

Vuln references:
- http://www.openssl.org/news/secadv_20120419.txt
- http://it.slashdot.org/story/12/04/19/1351203/major-openssl-security-issue-found-and-fixed
From the tor mailing list url below, they don't sound imo too concerned over it, but imo they really should be and so
should you if you use Tor! Monitor your logs in Tor and be aware of any bad entries highlighted in Vidalia in yellow related
to this vuln!
This message was posted to the most recent Tor Blog post comments area, awaiting approval. Please share this information with others and add this IP's fingerprint into your torrc file's block list. They could change their fingerprint at any time, so check the tor router list ( at http://torstatus.blutmagie.de/ ) for this IP or an IP within the range listed below for any new fingerprints and add them to your blocked section of your torrc file.
OFF TOPIC :
Please update the TBB with the newest version of OpenSSL.
Today I received my first ever SSL cert error within Vidalia, using the latest TBB version for my platform of choice.
I have never witnessed this error in the past. The error in the logs showcased several lines of errors, around 4, I believe, and it was directly related to the OpenSSL vuln, in my guess.
I regret not saving the error logs, but at the time I shrugged it off.
I do recall the IP associated with the error:
Router Name: whywouldiwanna
IP: 69.55.55.93
FP: $9e1dd7c6fa7f72b9473daf3f0780bbc7c1ce670f
Detail:
http://torstatus.blutmagie.de/router_detail.php?FP=9e1dd7c6fa7f72b9473daf3f0780bbc7c1ce670f
I'm familiar with the related discussion here:
https://lists.torproject.org/pipermail/tor-talk/2012-April/024031.html
but I believe it to be incorrect.
I strongly believe an updated release of all TBB versions' OpenSSL should be updated AT ONCE.
Let's not speculate, put this update into motion!
OrgTechEmail: abuse@realitychecknetwork.com