331–340 of 547 posts
Earlier quoted context omitted.
It was - registered 2 days ago by Marko Laakso from Codenomicon, the guys credited (by themselves it seems !) with finding the bug: http://www.networksolutions.com/whois/results.jsp?domain=hea...
They should probably get the guy who designed heartbleed.com to revamp their own website :)
Found 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.
JESUS CHRIST, all sorts of private information. Patch your servers now!
This shit is scary.
There 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…
I 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…
>>> 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 happens when the payload is smaller than the payload size passed in the request. This results in the response preparation dumping the memory block [pointer+realPayloadSize, pointer+payloadSize] into the response.
Any data in this block is now exposed to the callee; and could contain any data from the process.
Earlier 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…
Other than C there is also C++ and D if you don't want to stray to far from C. The problem with C++ is that even though it is possible to adapt to a memory safe programming style with C++ the concepts are not prevalent in the community.
Holy shit. That seems worse than the debian openssl debacle. If i got that right ALL openssl private keys are now potentially compromised. I hope vendors push fixes soon, and then I guess I'm busy for a few days regenerating private keys.
Oh it's even worse , basically every secret you had in your server processes' RAM was potentially read in real-time by an attacker for the last 2 years.
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…
I did this with no formal CS education and about 400 lines of code. I'm an operations engineer, not a security expert. Once I get it 100% and review my situation legally, I'll probably publish what I have.
Now is not the time to be conservative. Efforts to downplay this vulnerability are directly damaging to the Internet's security and, given that you are a single-issue poster, suspicious.
Earlier quoted context omitted.
> Most of the applications I use take roughly 0% of my processor's capacity. We're talking about a server-side vulnerability in OpenSSL here, not applications running on your personal computer. Roughly speaking, making your server code twice as slow means it will cost you twice as much money to run your servers. Of course, that depends a lot on what exactly you're doing and is obviously not always true... but OpenSSL…
SSL itself is a tiny fraction of the CPU load on a normal webserver. The idea that it's expensive has done more harm than many other things. It wouldn't cost anything except on accelerator boxes.