9 ms·
Use after free bug in OpenSSL
- andrewchoi 12y agoSorry if this is a silly question, but is this simply the Heartbleed bug? Or is this a different memory leak bug?
- saranagati 12y agoappears to be a different bug. nothing as big as heartbleed though from what I can tell.
- yarbelk 12y agoNot a silly question. Not all of us know which bug report is which sensationalised bug name. I know I don't. Admittedly, some bugs deserve to be sensationalised.
- Dylan16807 12y agoYou didn't look at the fifteen second description of what Heartbleed is?
- IgorPartola 12y agoTo be fair the linked patch is very sparse and even so not everyone reads C, or knows what the Heartbleed code looked like. I can guess at what this is because some kind people provided a few good links about how bad memory management in OpenSSL is handled.
- yohanatan 12y agoThe patch also comes with an explanation of the bug which obviously does not align at all with either the short- or the long-winded explanations of Heartbleed.
- yaur 12y agobackstory here http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse http://www.tedunangst.com/flak/post/analysis-of-openssl-free...
- IgorPartola 12y agoThis is not the Heartbleed bug. I am not certain this is actually an immediately exploitable vulnerability (aka a sexy bug). What this looks like is an instance where the code calls free() on a buffer, then assumes the buffer is still available (uses it in some way). The patch seems to make it only free the buffer after it is empty, preventing this behavior. I think this is related to OpenSSL's issue with malloc and the way it handles memory allocation.
- Danieru 12y agoYou're right about the custom malloc in so far as but bug would have been caught earlier without it.
- yaur 12y agoNo this was written about a couple days ago. It frees the memory and because Open uses a LIFO memory allocater it can "safely" assume that whatever was still in there is still in there. I belive that in order to exploit this you would need to exhaust its internal allocator (so that it requests more from the OS) and your payoff would be... having your connection dropped. This was discovered in the course of someone's attempt to figure out why OpenSSL randomly drops connections when its using a sane/OS supplied allocator.
- Dylan16807 12y agoIt's a bug that got in the way of memory hardening that could have stopped heartbleed, but it's not actually related. Heartbleed is reading too far, this is not that.
- rtpg 12y agoI think this is more of a bug that could enable something like Heartbleed. So squashing this might make other bugs less interesting to exploit.
- eudox 12y agoAre we going to post every new OpenSSL bug until everyone switches to miTLS?
- lawnchair_larry 12y agoThere are no plans to switch to miTLS. It's a toy project unsuitable for displacing OpenSSL.
- jewel 12y agoI believe that most other implementations are unsuitable for displacing OpenSSL for licensing reasons alone. I didn't look at every other implementation since I was looking for one that supported a specific mode, but the majority of them are GPL with the option to license for proprietary code. GnuTLS is LGPL, at least. Wikipedia has a pretty good list of possible implementations: http://en.wikipedia.org/wiki/Comparison_of_TLS_Implementations#Overview http://en.wikipedia.org/wiki/Comparison_of_TLS_Implementatio...
- deleted 12y ago[deleted]
- cybernoodles 12y agoIt appears Heartbleed has riled up the Hound dogs. It's unfortunate the funds aren't available for bug bounties in OpenSSL.
- regecks 12y agoThere are bug bounties for OpenSSL. 1. https://hackerone.com/openssl https://hackerone.com/openssl 2. https://www.google.com/about/appsecurity/patch-rewards/ https://www.google.com/about/appsecurity/patch-rewards/
- userbinator 12y agoIt's good to see that one of the positive effects of Heartbleed is that it motivated people to inspect OpenSSL's code, leading to more bugs being found and fixed. This is supposed to be how open-source works; it's unfortunate that it had to take a huge vulnerability to cause this motivation.
- midas007 12y agoIt still doesn't get at two top points of meta: TLS is a horribly overfeatured, design-by-committee standard AND C makes it incredibly easy to screw up and so requires zealous attention to a defensive coding style to introduce fewer flaws.
- cynicalkane 12y agoIt's possible to defensively code in C, particularly with modern tooling (some of which lets you write provably secure code) and good process. The fact of the matter is the OpenSSL people simply did not care about writing good code, and the open source community as a whole was happy to assign their most critical security features to a library widely known to be confusing and terrible and not even remotely properly analyzed or tested. Like most people, I see Heartbleed as a process failure; unlike most people, I think the process failure goes far beyond TLS or OpenSSL or C.
- ahomescu1 12y ago> The fact of the matter is the OpenSSL people simply did not care about writing good code, and the open source community as a whole was happy to assign their most critical security features to a library widely known to be confusing and terrible and not even remotely properly analyzed or tested. Sure, but open source developers have no obligation whatsoever to anyone. Considering they're not being paid in any way for their code, they can write whatever code they want and under whatever process they like. The problem IMHO is that OpenSSL was used for highly sensitive commercial uses (like Gmail, Amazon and others); I think responsibility should fall on companies who used the library without checking it first (Disclaimer: I'm not in anyway associated with OpenSSL or any crypto library, this is just how I see things).
- yelnatz 12y agoThat's pretty sick. I'd rather have bugs fixed now than later. Another!
- jevinskie 12y agoI believe this is the same patch as previously written about here on April 10th: http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse http://www.tedunangst.com/flak/post/analysis-of-openssl-free...
- caf 12y agoThe patch is slightly different, but it is the same bug.
- xorgar831 12y agoIt seems like someone should start a Sourceforge for security project; a place that tracks and does high quality static analysis of open source projects, and makes the reports readily available.
- dbbolton 12y agoWhat is up with that patch command? Why not cd /usr/src; patch -p0 </path/008_openssl.patch ?
- jzwinck 12y agoYou should use && instead of ; but otherwise I wondered the same thing. Useless use of cat, it seems.
- dbbolton 12y agoWhy? How likely is `cd /usr/src` to fail?
- sarnowski 12y agoBecause now your command isn't /path/ independant. The original assumed you downloaded the patch to your current directory and you can just copy&paste this command. Your example requires me to modify your line making this "process" more error prone.
- dbbolton 12y agoIn that case, their command is exactly as "error prone" to anyone who did not download the patch to the PWD.
- frik 12y agoOne may consider Mozilla's NSS library (Netscape invented SSL, "Network Security Services") as an alternative to OpenSSL. It has an compatible API layer (extra package), is used by Firefox, (Chrome), OpenOffice and has more sane default settings. Check out the comparison tables: http://en.wikipedia.org/wiki/Comparison_of_TLS_Implementations http://en.wikipedia.org/wiki/Comparison_of_TLS_Implementatio...
- gcb0 12y agoChrome used NSS on android only because of license or something else... now it uses openssl all around.
- barkingcat 12y agoChrome is planning to move to openssl for everything, doesn't mean it uses openssl "now all around". According to the planning doc linked earlier this week, it might take some time to get openssl into chrome. The Plan is for it to occur over 4 "milestones". I'm not sure how long each milestone will take, but suffice it to say, it's not "now". And it was the other way around. Only Chromium Android used OpenSSL. Everywhere else it used NSS (linux, mac desktop, windows) Quote from https://docs.google.com/document/d/1ML11ZyyMpnAr6clIAwWrXD53pQgNR-DppMYwt9XvE6s/edit?pli=1 https://docs.google.com/document/d/1ML11ZyyMpnAr6clIAwWrXD53... "Currently, Chromium supports two different SSL/cryptographic backends. On Windows, OS X, iOS, Linux, and Chromium OS, Chromium uses NSS. On Android, Chromium uses OpenSSL. " Please check your sources carefully and don't write unfactual information. Especially in the realm of crypto it's important to get the details right. It would be even better if you edited your post so future readers don't have to read my post at all in order to get the correct information.
- legulere 12y agoIt seems to be even more overly complex and hard to use (when not using the compatibility layer) than openssl though. The ease of use for programmers is also very important as an error of the application programmer can be as bad as an error in the ssl library.
- victormx 12y agoAnyone known a real alternative to SSL to secure communications? No GPG, POW(or bitcoin, similar, etc.)
- justincormack 12y agoYou need to be more specific about what kind of communications. You could look at spiped as one example https://www.tarsnap.com/spiped.html https://www.tarsnap.com/spiped.html
- victormx 12y agothanks this is what I was talking
- danieltillett 12y agoI think that this is a good sign. I know everyone has been saying that OpenSSL code is terrible (can't say I have looked myself), but if this is the worst bug found since heartbleed then maybe it is better than it appears.
- clarry 12y agoThis isn't a bug found in a thorough audit of the entire OpenSSL code base. This is a bug that was discovered while trying to understand why applications using OpenSSL would run into trouble after disabling the code that made it impossible to detect Heartbleed with OpenBSD's malloc safety features.
- danieltillett 12y agoI understand this, just with the amount of attention OpenSSL has been getting not much worse seems to have come out.
- nemo 12y agoI wish Theo and his colleagues would create a fork of OpenSSL that was up to OpenBSD/OpenSSH standards. It would be a huge level of work, but I'd happily donate to help fund it.
- peteretep 12y agoYes, yes a million times. Wonder if this will prompt them to. For a rewrite to have any traction, it would need implementing by a team with some credibility, and they're probably one of the few teams with that credibility
- deleted 12y ago[deleted]
- dllthomas 12y agoWould it really have to be a fork? Working with the original team could be to everyone's benefit.
- clarry 12y agoSome anecdotes from recent discussion suggest it's not so easy to work with the original team. Also, if their standard for quality is what it is, it might be hard for another project to start changing things.
- dllthomas 12y ago"Some anecdotes from recent discussion suggest it's not so easy to work with the original team." 'k, certainly forking is better than letting poor quality persist, and it may be better than reimplementing from scratch. I just don't like resorting to it when unnecessary. "Also, if their standard for quality is what it is, it might be hard for another project to start changing things." Possibly, though their "standard for quality" is probably at least a little malleable (particularly right now).
- nemo 12y ago