Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Heartbleed Bug

heartbleed.com

Post reply on HN
Print view View original

351–360 of 547 posts

Re: The Heartbleed Bug

#351

Post by etherealG »

jsmthrowaway wrote: post #338
atomicUpdate wrote: post #302

Earlier quoted context omitted.

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 have successfully extracted a key and decrypted traffic in a lab. I'm refining my automatic process. You're forgetting analysis of the runtime layout of OpenSSL in RAM which is quite predictable on machines without defensive measures. I have a 100% success rate extracting memory and about a 20% success rate programmatically extracting the secret key of the server. I'm nearly 100% against a certain version of Apache…

This is the reason the grandparent post was downvoted. Assumption that cause something seems unlikely is usually a bad idea in security.

Thanks for confirming my suspicions about this bug, seems anyone with decent effort can break keys.

Re: The Heartbleed Bug

#352

Post by MichaelGG »

ehPReth wrote: post #240
sexmonad wrote: post #34

Earlier quoted context omitted.

Update to 1.0.1g, redo all crypto. That is, revoke certs and keys and regenerate.

Just a note to others: all crypto includes things like SSH keys, SSH host keys, and GPG keys. Anything in memory could have been read.

How would a TLS webserver read the memory of sshd? Processes shouldn't generally have everything mapped in.

Re: The Heartbleed Bug

#353

Post by MichaelGG »

Kiro wrote: post #343

A lot of doomsayers here but I'm running a service which could just as well be http. https is only there for show. Why do I need to upgrade?

If your process space is public, you don't.

There's probably the potential for segfaults, though, since the code might read past all allocations.

Re: The Heartbleed Bug

#354

Post by CCs »

ballard wrote: post #254
lambdasquirrel wrote: post #152

Earlier quoted context omitted.

I've felt that C makes this code easy to write because it makes doing the right thing hard. What you are describing is just a lot of work in C, compared to a language with something akin to Java's generics, which are in turn an afterthought in the ML family of languages. What we're asking for is not that complicated from a PL standpoint. A generic streams library? Economics plays an invisible part here. Someone writi…

That's what I like about Ruby. ;) Even in C, Go or Python, I column align any text that is remotely similar, so differences are obvious. Clean code might be extra work but the net work (maintenance) should amortize less. Reducing cognitive load for large supportable production codebase cannot be underscored enough.

There's no "just use X" type of answer in security.

Sep 2013

"All versions of the open source Ruby on Rails Web application framework released in the past six years have a critical vulnerability that an attacker could exploit to execute arbitrary code, steal information from databases and crash servers."

https://groups.google.com/forum/#!topic/rubyonrails-security...

Nov 2013

"A lingering security issue in Ruby on Rails..."

http://threatpost.com/ruby-on-rails-cookiestore-vulnerabilit...

Dec 2013

"Ruby on Rails security updates patch XSS, DoS vulnerabilities"

http://www.infoworld.com/d/security/ruby-rails-security-upda...

Re: The Heartbleed Bug

#355

Post by pjmorris »

axman6 wrote: post #309
jevinskie wrote: post #251

Earlier quoted context omitted.

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 us…

Tony Hoare (Mr. Quicksort, CSP, etc...) has softened his stance since "The Emperor's Old Clothes", but his concern was that ADA is too complicated to be understandable and safe. I hated Pascal because the array length was part of its type... but maybe that kind of thinking is apparently what it takes to avoid bugs like Heartbleed.

Re: The Heartbleed Bug

#356

Post by ibmthrowaway218 »

HappMacDonald wrote: post #317
astrange wrote: post #303

Earlier quoted context omitted.

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.

Well, one way is to brute iterate through every potential 256-bit string you dredge out of the canal against the known public key. If you can dredge up 64kB of fresh data every time, that's 511,744 tests per shovelful which is quite a bit to sift through from a performance perspective but it's also a trivially parallel task. Additionally, folk might know of even better ways to narrow that down. For example, the data…

65505 tests as I work it out as it's unlikely to be non-byte aligned:-

256 bits is 32 bytes

If you get 64kB of payload data back each time then it can only contain 65536-31=65505 different consecutive strings of 32 bytes.

Re: The Heartbleed Bug

#357

Post by 72deluxe »

Perseids wrote: post #328
pbsd wrote: post #191

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.

What would you advocate as memory safe programming styles? Strong guarantee? RAII?

Re: The Heartbleed Bug

#358

Post by corford »

pbsd wrote: post #191
yaakov34 wrote: post #90

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…

How about D?

Re: The Heartbleed Bug

#359

Post by 72deluxe »

Dylan16807 wrote: post #313
jcalvinowens wrote: post #264

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.

Is it really a tiny load? Have you ever looked at the throughput values quoted for VPN routers that do their encryption in software (not hardware like the expensive Cisco ASAs)? If you compare the non-VPN throughput with the VPN-throughput, the software encryption is massively massively slower, so I would argue that software encryption is not a tiny load on a normal webserver, unless the webserver was not getting any hits...?
Post reply on HN