I 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…
The Heartbleed Bug
431–440 of 547 posts
Re: The Heartbleed Bug
#432Earlier quoted context omitted.
What would you advocate as memory safe programming styles? Strong guarantee? RAII?
RAII is a minimum. You also have to treat any direct and indirect (unchecked) pointer arithmetic as a potential security vulnerability though. For example if you use the [] operator of a vector you can still access memory outside of the allocated space. Instead you would have to use the at() method which actually checks the bounds. Even iterator are problematic as the iterator on a vector also ignores the actual boun…
Ah I tend to not use [] operators on vectors etc. but as you say iterators can be problematic. The best way is to start at the end of the container and work backwards, particularly if you are removing items from the list (thereby wrecking the iterator's idea of the end position if you were moving forwards through it).
I should probably finish Bjarne's C++11 book - I am maintaining a codebase of old style C++ and seem to be stuck in the old methods of doing it, mainly because of using compilers that don't have C++11 support.
Is there any recommended reading on new style C++ other than Bjarne's book?
Re: The Heartbleed Bug
#433Over 300.000 LoC: ~/tmp/openssl-1.0.1g $ find . -name "*.c" | xargs wc -l | tail -n1 349834 total This is too much by at least one order of magnitude. What's the going price for a crypto-level code review (I'm not even saying audit) these days? Is all this code necessary for state-of-the art encryption or isn't it rather backwards compatibility baggage? If the latter: how much could be gained by splitting the project…
The cost of a cryptography code review is about $5-10k per week.
Thanks! So how does this work: Say I have this project and I want
it audited -- would you (or the company/person that you
had in mind) give me an estimate like "I'd need 3 weeks for
25, 5 weeks for 50 or 10 weeks for 95% coverage" or do you simply analyse away for a week (or whatever time I'm willing to pay you) and try to find something?
Re: The Heartbleed Bug
#434Love this
> Is there a bright side to all this?
Re: The Heartbleed Bug
#435Earlier quoted context omitted.
First, I do realize that rewriting the software stack from the ground up to have only managed code is a huge task. I do think that as an industry, we should set a goal of having at least one server implementation along these lines (where 'set a goal' may mean, say, grants or calls for proposals). Microsoft Research implemented an experimental OS like that, although it probably didn't have all the features a modern OS…
Do not like the term "C/C++", and especially in this context. Modern C++ makes avoiding this sort of bug as easy as doing so in the "managed" languages already discussed. This is as much a cultural as a technical problem; C really is in the last chance saloon for this sort of problem, we have the solution to hand, but a strong cadre of developers will still only consider C for this sort of work.
I don't think this is true. When it comes to copying bytes from a buffer supplied from the network, there isn't a wrapper/manager class that can do this for you. Somewhere down the pipeline some piece of code has to copy the unstructured, variable length byte stream into a manageable data structure. C++ does not give any way to do this beyond the mechanisms available in C.
Re: The Heartbleed Bug
#436Earlier 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.
I successfully obtained the private key for my local Apache install this way once, though I'm having trouble getting anything reliable.
How many tries did it take to get the whole key?
Re: The Heartbleed Bug
#437Note: if you use mint.com, it's likely hitting your banks with your login on your behalf today. You'll still want to change those passwords even if you didn't use banking sites during the known vulnerability window.
Re: The Heartbleed Bug
#438Earlier quoted context omitted.
First, I do realize that rewriting the software stack from the ground up to have only managed code is a huge task. I do think that as an industry, we should set a goal of having at least one server implementation along these lines (where 'set a goal' may mean, say, grants or calls for proposals). Microsoft Research implemented an experimental OS like that, although it probably didn't have all the features a modern OS…
Do not like the term "C/C++", and especially in this context. Modern C++ makes avoiding this sort of bug as easy as doing so in the "managed" languages already discussed. This is as much a cultural as a technical problem; C really is in the last chance saloon for this sort of problem, we have the solution to hand, but a strong cadre of developers will still only consider C for this sort of work.
Thank you, this really had to be said. You can do C in C++ (and if you do that, chances are that you're doing it wrong), but you can't do C++ in C. The ugliest and unsafe parts of C++ are invariably those coming almost untouched from C (raw pointers, casts from/to void ptrs, etc). C is close to the machine, but C++ is largely a vertical language where you can do things low-level or high-level (and yes, you can do a lot of interesting things with templates, no matter the bad rap they've got); and most of the current C++ community vastly prefers high-level-like code, for good reasons (for starters, it may be even more performant). A LOT of the sources of unsafe code go away by two simple techniques: use RAII-managed smart pointers instead of raw ones (some of them are as lightweight as a raw pointer), and prefer vector (or other container) to array.
I love C and C++, and each one has its place, but really, they're very different. Almost as much as C++ is to Java, for example.
Re: The Heartbleed Bug
#439I don't quite understand how this bug works. I would appreciate any input from someone knowledgeable. It sounds like the heartbeat code is sending some data in the handshake. That data should be harmless (padding? zeroes?) but the bug results in reading off the end of an array and from whatever other data happens to be there. Someone sniffing the connection can then see those bytes fly by. If they happened to contain…
I'll give it a shot. Quoting a poster above. >>> TLS heartbeat consists of a request packet including a payload; the other side reads and sends a response containing the same payload (plus some other padding). So, what happens is that the payload comes in as a pointer and a size (up to 64kb). The server then prepares a response and copies the memory block [pointer, pointer+payloadSize] into the request. The attack ha…
Thanks. That lines up with what I've seen elsewhere too. I think the main thing I was missing was that this is not a sniffing attack, but rather an active attack where you talk to a peer over SSL and basically trick it into sending you some content from its memory.
Re: The Heartbleed Bug
#440Earlier quoted context omitted.
The bug is in the handling of the TLS protocol itself (actually, in a little-used extension of TLS, the TLS Record Layer Heartbeat Protocol), and isn't exposed in applications that just use TLS for crypto primitives.
Sooo in layman's terms - we only need to be worrying about HTTPS and not SSH ?
If it would be that easy. ssh not, but all those. Some of them actually use the heartbeat feature.
curl seems to be the worst.
$ apt-cache showpkg libssl1.0.0 => http://perl514.cpanel.net/libssl1.0.0.depends (186 deps)