There are open support tickets in both Heroku and AWS about the impact of this bug but no answers yet. I hope folks will promote a warning if either platform is effected both on HackerNews and twitter.
Got links?
The Heartbleed Bug
301–310 of 547 posts
Re: The Heartbleed Bug
#302I think the summary is a bit too sensationalistic in terms of what the actual security implications are: The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. Yes, while that's true, it's not a "read the whole process' memory" vulnerability which would definitely be cause for panic. The details are subtle: Can attacker access o…
I agree entirely with your post, and I can't quite understand the hysteria in this thread. The odds of getting a key using this technique are incredibly low to begin with, let alone being able to recognize you have one, and how to correlate it with any useful encrypted data.
Supposing you do hit the lottery and get a key somewhere in your packet, you now have to find the starting byte for it, which means having data to attempt to decrypt it with. However, now you get bit by the fact that you don't have any privileged information or credentials, so you have no idea where decryptable information lives.
Assuming you are even able to intercept some traffic that's encrypted, you now have to try every word-aligned 256B(?) string of data you collected from the server, and hope you can decrypt the data. The amount of storage and processing time for this is already ridiculous, since you have to manually check if the data looks "good" or not.
The odds of all of these things lining up is infinitesimal for anything worth being worried about (banks, credit cards, etc.), so the effort involved far outweighs the payoffs (you only get 1 person's information after all of that). This is especially true when compared with traditional means of collecting this data through more generic viruses and social engineering.
So, while I'll be updating my personal systems, I'm not going to jump on to the "the sky is falling" train just yet, until someone can give a good example of how this could be practically exploited.
Re: The Heartbleed Bug
#303Earlier quoted context omitted.
The latter, and AFAIK the buffer doesn't get reallocated on every connection, so it should be unlikely that any private keys actually get dumped. However, I could be missing a way to exploit it.
Reading between the lines in the announcement it sounds like dropping and reconnecting may cause it to read memory freed up from a prior connection. It may "just" be a matter of keep trying or it may be a matter of opening lots of connections to consume resources dropping them all then connecting and seeing what was left on the beach after the tide went out. BTW Amazon AWS/ELM is vulnerable, confirmed publically by t…
If it just reads the up-to-64KB after that allocation, wouldn't you expect to see the server process segfault before too long?
Of course, servers helpfully just start themselves back up again.
As for scanning for key material, I wonder how to tell that 256-bit random data is the 256-bit random data you want.
Re: The Heartbleed Bug
#304There was a discussion here a few years ago ( https://news.ycombinator.com/item?id=2686580 ) about memory vulnerabilities in C. Some people tried to argue back then that various protections offered by modern OSs and runtimes, such as address space randomization, and the availability of tools like Valgrind for finding memory access bugs, mitigates this. I really recommend re-reading that discussion. My opinion, then a…
This sort of argument is becoming something of a fashion statement amongst some security people. It's not a strictly wrong argument: writing code in languages that make screwing up easy will invariably result in screwups. But it's a disingenuous one. It ignores the realities of systems. The reality is that there is currently no widely available memory-safe language that is usable for something like OpenSSL. .NET and…
>This sort of argument is becoming something of a fashion statement amongst some security people.
Just the ones who don't understand how good API designs can work well to solve these problems, don't worry not all of us are like that :)
Re: The Heartbleed Bug
#305Honestly, why aren't the formal verification people jumping on this? I keep hearing about automatic code generation from proof systems like Coq and Agda but it's always some toy example like iterative version of fibonacci from the recursive version or something else just as mundane. Wouldn't cryptography be a perfect playground for making new discoveries? At the end of the day all crypto is just number theory and num…
You may be interested in Quark, which is a browser kernel written using Coq http://goto.ucsd.edu/quark/
Re: The Heartbleed Bug
#306Found a Python PoC: http://s3.jspenguin.org/ssltest.py
Edit: and just used it to dump 64K from a known-vulnerable device we control. Got a session cookie. Jeez.
Re: The Heartbleed Bug
#307A couple more data points: I'm running Fedora 19 and Arch on my main dev machines/VMs and as of this posting are considered up-to-date. Both are vulnerable: [Fedora19] $ openssl version OpenSSL 1.0.1e-fips 11 Feb 2013 [Arch] $ openssl version OpenSSL 1.0.1f 6 Jan 2014
Yeah, I haven't seen any new RPMs for RHEL/CentOS/Fedora yet. Kinda concerning, since I'd expect vendors to be given advance notice and the chance to prep updates to coincide with the announcement. All my RHEL5 boxes are running 0.9.8, though, at least.
I've built RPMs for 1.0.1g for CentOS 6. Based of 1.0.1e source rpms. https://www.dropbox.com/sh/7s1fiuvfwma16ra/iSz3Jfh1o-
Re: The Heartbleed Bug
#308Earlier quoted context omitted.
I think over the last few months we've seen some pretty concrete evidence that implementing SSL securely is horribly hard to do.
Also the library he pointed to has only had 33k downloads total. Can you really suggest that as a replacement for one of the most heavily and read crypto libraries on earth? I wouldn't be surprised if OpenSSL had more than 33k programs that use it as a dependency.
I am recommending it as an existence proof that one can construct a usable crypto library in a performant safe language.
Re: The Heartbleed Bug
#309Earlier quoted context omitted.
This sort of argument is becoming something of a fashion statement amongst some security people. It's not a strictly wrong argument: writing code in languages that make screwing up easy will invariably result in screwups. But it's a disingenuous one. It ignores the realities of systems. The reality is that there is currently no widely available memory-safe language that is usable for something like OpenSSL. .NET and…
How about Ada? It is time tested! GNU's Ada shares the same backend as GCC so it can be pretty fast. Good enough for DoD. =P Edit: I say this having used VHDL quite a bit. I appreciate its type strictness and ranges.
My first thought too was Ada, it's easily callable from anything that can call C afaik, and has infinitely better support for catching these sorts of bugs than C or C++ do. It's basically made for this kind of project, and yet no one in the civilian population really cares; it's a real shame. Not only does Ada make it easy to do things safely, it makes it very hard to do things unsafely.
I've been advocating Ada's use on HN for a few years now, but it always falls on deaf ears. People seem to think it's old and dead like COBOL or old FORTRAN, but it's really a quite modern language that's extremely well thought out. Its other drawback is that it's pretty ugly and uses strange names for things (access is the name given to pointer like things, but Ada specifies if you have say a record with a 1 bit Bool in it, you must be able to create an access to it, so a pointer is not sufficient).
Re: The Heartbleed Bug
#310Has anybody seen or created a PoC for this yet?
UPDATE: I've found one! Shouts to the venerable FiloSottile!
https://github.com/FiloSottile/Heartbleed/blob/master/bleed/...