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

471–480 of 547 posts

Re: The Heartbleed Bug

#471

Post by dirtyaura »

eliteraspberrie wrote: post #422
hf wrote: post #379

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…

The cost of a cryptography code review is about $5-10k per week.

That cheap? A freelance web/Mobile developer can charge over $5K per week, I find it hard to believe that you could get quality security code review for that price

Re: The Heartbleed Bug

#472

Post by chc »

eggnet wrote: post #456
Xylakant wrote: post #403

Earlier quoted context omitted.

Ruby != Rails. We do a lot of ruby, but practically no rails.

But rails is written in ruby. So it can't have security bugs, right?

Observing that Ruby eliminates entire classes of bugs doesn't mean that Ruby eliminates all bugs; just that your attack surface is smaller.

Re: The Heartbleed Bug

#473

Post by hamburglar »

dylz wrote: post #347
hamburglar wrote: post #146

Earlier quoted context omitted.

The part that's caused me to read this page several times over without a clear answer is that they mention that private keys may be leaked, but their calls to action do not recommend generating new private keys. How does that make any sense?

>this leak requires patching the vulnerability, revocation of the compromised keys and reissuing and redistributing new keys. Even doing all this will still leave any traffic intercepted by the attacker in the past still vulnerable to decryption. All this has to be done by the owners of the services.

Yes, down in the Q&A of details of what's leaked, not in the "here's what you need to do" section. It makes you think, "wait, the details say reissue keys...why does the 'what you need to do' section not say that? Did I misunderstand?" It's not very clearly written. Not to mention "revocation of the compromised keys" is itself vague: which keys are compromised? "The crown jewels" of course. We must infer that we're talking about the SSL private keys. And again, because revoking those keys is not mentioned in the call to action, you're forced to question whether your inference is correct.

As an actionable bulletin, this page leaves a lot to be desired. Nice logo and domain name, though.

Re: The Heartbleed Bug

#474

Post by rmc »

colinbartlett wrote: post #459
rmc wrote: post #364

Earlier quoted context omitted.

Sometimes things are time-critical.....

Ah, the old middle-management excuse: "We don't have time to write tests!"

When half the secure internet is on fire... yeah, i think that's an acceptable time.

Re: The Heartbleed Bug

#475

Post by bostik »

repost wrote: post #269
comex wrote: post #237

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

> It may "just" be a matter of keep trying

I gave this some thought earlier today, and expect that address space randomisation can make this bug eventually expose the server keys. You need to hit an address that has been just vacated from a (crashed) httpd worker.

Most implementations clear encryption key material on exit, but a crashed process never got to run that code.

Re: The Heartbleed Bug

#476

Post by Xylakant »

eggnet wrote: post #456
Xylakant wrote: post #403

Earlier quoted context omitted.

Ruby != Rails. We do a lot of ruby, but practically no rails.

But rails is written in ruby. So it can't have security bugs, right?

Sure it can and I'm not surprised it has. But if you're trying to point out flaws in ruby, at least use examples for flaws in ruby - not flaws in something written in ruby. It's not like web frameworks in other languages magically don't suffer from XSS injection attacks.

Re: The Heartbleed Bug

#477

Post by SoftwareMaven »

Perseids wrote: post #429
ef47d35620c1 wrote: post #397

Earlier quoted context omitted.

Secure coding is very prevalent in C++ (outside the group of old C programmers who write C++ code as if it were C). C++ is far safer than C.

Sorry, let me be more clear: In the courses and books I've seen and read novices don't get taught secure coding techniques as C++ is often introduced as a superset of C and security in general is not of interest to the teacher. Then later on when they transition to the web as a primary source of information there is a lot of legacy C++ code lying around that does not use modern memory management concepts. Also, as no…

I don't know. I was a C++ coder 15 years ago, left for managed languages, then came back to it a couple years ago. Rusty would be an understatement, so I had to come at it in what may be a worse state than a noob: a person with outdated knowledge of how things work.

If you looked at all for "best practices", things like RIAA, stl/boost, and other concepts became very clear, very quickly, and these are the types of thing that limit these kinds of bugs (RIAA, in particular). Now, to be fair, I was writing crypto-related software, so I was paying very close attention, but I didn't really have to hunt.

Re: The Heartbleed Bug

#478

Post by jcalvinowens »

kibwen wrote: post #466
jcalvinowens wrote: post #457

Earlier quoted context omitted.

> Why not put every chance on our side and use languages (e.g. Rust, Ada, ATS, etc.) that make entire classes of errors impossible? I don't think intentionally preventing the programmer from doing certain things the computer is capable of doing on the theory it makes errors impossible makes sense. As I've said several times in this thread, somebody has to deal with the pointers and raw memory because that's the way c…

> I don't think intentionally preventing the programmer > from doing certain things the computer is capable of > doing on the theory it makes errors impossible makes > sense. With arguments like this, we'd all be back in the days of non-structured programming languages (enjoy writing all your crypto in MUMPS). Every modern language, including C, restricts itself in some way in order to make programs more predictable…

> With arguments like this, we'd all be back in the days of non-structured programming languages

You're confusing the difference between syntactical restrictions and actual restrictions on what one can make the computer do.

I define "things the computer is capable of" as "arbitrary valid object code executable on the CPU". (Valid here meaning "not an illegal instruction".) Any language that prevents me from producing any arbitrary valid object code is inherently restrictive. C allows me to do this. I can even write functionless programs in C, although it's often non-portable and requires mucking with the linker. If the CPU has some special instruction I want to use, I can use inline assembly.

Any language that prevents me from doing arbitrary pointer arithmetic and memory accesses prevents me from doing a lot of useful things I can do in C. See my other comment about linked lists with 16-bit pointers on a 64-bit CPU.

My understanding of Rust is that its pointers have similar semantics to the "safe_pointers" in C++. If that's the case, my understanding is that it would prevent me from doing things like the 16-bit linked list (please, correct me if I'm wrong).

Re: The Heartbleed Bug

#480

Post by willfiveash »

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

This reminds me of what another programmer told me a long time ago when we were discussing C; "The problem with C is that people make terrible memory managers.". So true.
Post reply on HN