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

251–260 of 547 posts

Re: The Heartbleed Bug

#251

Post by jevinskie »

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 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.

Re: The Heartbleed Bug

#252

Post by mpyne »

yaakov34 wrote: post #209
azth wrote: post #183

Earlier quoted context omitted.

>(2) lots of complicated ways to screw up, such as not properly allocating/deleting things deep in some templated structure Wow, that sounds scary. Do you have any references or further reading about this?

I don't have a reference, but I've seen this myself. Problems can happen whenever pointers combined with the STL or other modern C++ stuff. In the thread from several years ago, I gave as an example pushing a pointer to a local variable into a vector which is then returned somewhere outside of scope. Compilers don't warn about this, or at least didn't then, although Valgrind catches it. And of course this can be a mo…

> In fact, using raw pointers in C++ is not a good idea, at least IMO

Not just your opinion; it's become the "standard of practice" in the C++ development community.

They're trying to get it that between STL, make_shared, C++14's make_unique, etc., that you won't actually be using "naked new"s in any but the rarest cases. For the rest of memory management you'd use types to describe the ownership semantics and let the compiler handle the rest.

Re: The Heartbleed Bug

#253

Post by Dylan16807 »

yaakov34 wrote: post #170
amalcon wrote: post #139

Earlier quoted context omitted.

Nothing in the standard prevents a C compiler + tightly coupled malloc implementation from implementing bounds checks. Out-of-bounds operations result in undefined behavior, and crashing the program is a valid response to undefined behavior. If your malloc implementation cooperates, you can even bounds-check pointer arithmetic without violating calling conventions. It's quite a shame that there isn't a compiler that…

Unrestricted pointer arithmetic is indeed incompatible with memory safety. You set a pointer to point to one structure, then you change it and it now points to another structure or array. The compiler doesn't know the semantics of your code, so how can it tell if you meant to do that? And malloc/memcpy is way too low to check this stuff. It only sees memory addresses; it has no idea what variables are in them. Tightl…

>You set a pointer to point to one structure, then you change it and it now points to another structure or array. The compiler doesn't know the semantics of your code, so how can it tell if you meant to do that?

If you changed it via arithmetic or anything other than direct assignment you have violated the standard. Assuming of course that they are part of separate allocations, pointers from one may not interact with pointers from another except through equality testing and assignment.

Re: The Heartbleed Bug

#254

Post by ballard »

lambdasquirrel wrote: post #152
drv wrote: post #100

Earlier quoted context omitted.

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

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.

Re: The Heartbleed Bug

#255

Post by endeavour »

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.

Nice work

Re: The Heartbleed Bug

#257

Post by mpyne »

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.

Well, I don't think it's anything in memory, but whatever was up to 64k from wherever the downloaded packet was put in userspace (Edit: Er, 64k at a time, but the attacker can try again over and over). Since the kernel should be handing only zeroed pages to userspace to use as a buffer then it should only be memory used by the process using openssl at risk.

The big problem is that this is still a gigantic range of processes (and possible memory buffer contents). But SSH at least would appear to be fine, unless you've ever transferred an SSH key over TLS using OpenSSL.

Re: The Heartbleed Bug

#258

Post by stormbrew »

comex wrote: post #242
pbsd wrote: post #210

Earlier quoted context omitted.

Using C as an output language, backed by guarantees at the higher level, could certainly work. I believe ATS [1] works this way, and can even avoid garbage collection altogether if desired. I understand it is not an easy language, though. Nimrod [2] also generates C, but as I understand it garbage collection is unavoidable. [1] http://www.ats-lang.org/ [2] http://nimrod-lang.org/

This is one reason I'd like to see the removed LLVM C backend brought back and modernized, with Rust as the source language. Rust is safe, has no mandatory garbage collector, and has a much lower impedance mismatch with C or C++ than most higher level languages, so it should work well for libraries that are expected to integrate with C code.

> removed LLVM C backend

What are you referring to here?

Re: The Heartbleed Bug

#259

Post by gojomo »

nwh wrote: post #203
gojomo wrote: post #70

Earlier quoted context omitted.

Yes, Bitcoin the system/protocol doesn't inherently use TLS. But, with the "rpcssl=1" option, the reference Bitcoin client's RPC interface would be using SSL, and specifically OpenSSL. I'd guess a ton of online Bitcoin services reliant on hot wallets do this. So cue the thefts, or 'thefts', any minute now.

Nobody exposes their RPC port over ssl publicly. Nobody. You can't even do it if you use the normal settings in the client.

I'm fairly confident that you're wrong about "nobody"... but you'll have to find the examples yourself.

Yes, it requires extra settings in bitcoin.conf: to enable RPC, accept connections from non-local addresses, and use SSL. But it's only 5 lines if the host is not otherwise firewalled from the net:

  server=1
  rpcuser=reckless
  rpcpassword=passw0rd
  rpcallowip=*
  rpcssl=1
(Actually, I'm not sure if rpcuser and rpcpassword absolutely must be set...)

Re: The Heartbleed Bug

#260

Post by userbinator »

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 only 64k of the memory? There is no total of 64 kilobytes limitation to the attack, that limit applies only to a single heartbeat. Attacker can either keep reconnecting or during an active TLS connection keep requesting arbitrary number of 64 kilobyte chunks of memory content until enough secrets are revealed.

The address space of a process is normally far bigger than 64KB, and while the bug does allow an arbitrary number of 64KB reads, it is important to note that the attacker cannot directly control where that 64KB will come from. If you're lucky, you'll get a whole bunch of keys. If you're unlucky, you might get unencrypted data you sent/received, which you would have anyway. If you're really unlucky, you get 64KB of zero bytes every time.

Then there's also the question of knowing exactly what/where the actual secrets are. Encryption keys (should) look like random data, and there's a lot of other random-looking stuff in crypto libraries' state. Even supposing you know that there is a key, of some type, somewhere in a 64KB block of random-looking data, you still need to find where inside that data the key is, what type of key it is, and more importantly, whose traffic it protects before you can do anything malicious.

Without using any privileged information or credentials we were able steal from ourselves the secret keys

It really helps when looking for keys, if you already know what the keys are.

In other words, while this is a cause for concern, it's not anywhere near "everything is wide open", and that is probably the reason why it has remained undiscovered for so long.

Edit: downvotes. Care to explain?

Post reply on HN