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

371–380 of 547 posts

Re: The Heartbleed Bug

#371

Post by juhanima »

astrange wrote: post #303
repost wrote: post #269

Earlier quoted context omitted.

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.

When for instance an AES-key is being used by OpenSSL, it is put into a 'struct aes_key_st' which is not random at all but quite easily recognizable when scanning memory.

The Cold Boot attack paper by Halderman, Schoen et al. here

https://citp.princeton.edu/research/memory/

...discusses this in detail in chapter 6, Identifying Keys in Memory.

EDIT: fixed the reference

Re: The Heartbleed Bug

#372

Post by [deleted] »

pearjuice wrote: post #118

"goto fail;" doesn't seem that bad now huh. Lovely how these GNU/Linux freedom fighters were LOLling their asses off earlier, but when it happens to them they sweat themselves and cry for spoon-fed instructions to compile a software package from its sources. - sent from my Mac

[deleted]

Re: The Heartbleed Bug

#373

Post by [deleted] »

lmm wrote: post #361
CCs wrote: post #354

Earlier quoted context omitted.

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

Rails does plenty of "make life easier for the programmer" things that I would expect to increase the risk of security issues. Do you have those kind of problems for e.g. Haskell?

[deleted]

Re: The Heartbleed Bug

#374

Post by [deleted] »

drv wrote: post #100
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…

From a quick reading of the TLS heartbeat RFC and the patched code, here's my understanding of the cause of the bug. 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). In the code that handles TLS heartbeat requests, the payload size is read from the packet controlled by the attacker: n2s(p, payload); pl = p;…

[deleted]

Re: The Heartbleed Bug

#375

Post by pdpi »

mietek wrote: post #286
pbsd wrote: post #227

Earlier quoted context omitted.

OpenSSL and similar libraries spend most of their time processing short packets. For example, encrypting a few hundred bytes using AES these days should take only a few hundred CPU cycles. This means that the overhead of calling the crypto code should be minimal, preferably 0. This is in part what I meant by "first-class". Perhaps I should have written "zero-overhead" instead. I googled around just now for some bench…

This project attempts to measure the overhead of calling out from $LANGUAGE and into C, which is the reverse of what's necessary to solve the problem stated here — to write a low-level library in a high-level language. There are other means of achieving a secure implementation, such as programming in a very high-level language, such as Cryptol, and compiling to a low-level language: http://corp.galois.com/cryptol/

No, it's the exact problem we're faced with here: Calling OpenSSL from the outside is something you do a handful of times. The OP was concerned about parts of OpenSSL that require direct hardware access (thus, should be written in C). Because those parts of the code are extremely hot, having to cross FFI boundaries to reach them might be prohibitively expensive.

Re: The Heartbleed Bug

#376

Post by nandemo »

codygman wrote: post #223
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…

I believe Haskell could be up to the job, but I heard that there were some difficulties in guarding against timing attacks. However those could have just been noise. I know that a functional (I believe and haha) operating system was made in Haskell. Aren't Operating Systems lower level than OpenSSL?

If you mean Metasepi, it's still under development:

http://metasepi.org (mostly in Japanese) http://www.ipa.go.jp/files/000036232.pdf (Slides in English)

Re: The Heartbleed Bug

#377

Post by ch0wn »

raphinou wrote: post #369
FiloSottile wrote: post #215

I've built a web tester for this bug, find it at http://filippo.io/Heartbleed/ It actually exploit the bug, since it was quite trivial, and echo some memory. It's written in Go, no more than 100 lines. I'll release code in some time.

My upgraded debian and ubuntu boxes are still reported as vulnerable.... Who's wrong, who's right?

Have you restarted the services linked against openssl?

lsof | grep ssl | grep DEL

Re: The Heartbleed Bug

#379

Post by hf »

Over 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 into '-current' and '-not'?

Re: The Heartbleed Bug

#380

Post by rtpg »

twic wrote: post #368
rtpg wrote: post #221

Earlier quoted context omitted.

>The problem with C is that a lot of people don't write it well. There are languages that make it very very hard to write bad code. Haskell is a good example of where if your program type-checks, there's a high chance it's probably correct. C is a language that doesn't offer many advantages but offers very many disadvantages for its weak assurances. Things like the Haskell compiler show that you can get strong typing…

> Haskell is a good example of where if your program type-checks, there's a high chance it's probably correct. I really wish people would stop saying this. It's not in the slightest bit true. Making this assertion makes Haskellers seem dangerously naive.

it's just probably correct ;)
Post reply on HN