Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Thanks for this. How is this reading arbitrary memory locations though? Isn't this always reading what is near the pl? As in, can you really scan the entire process's memory range this way or just a small subset where malloc (or the stack, whichever this is) places pl?


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


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


In most systems, this will only work within the same process. Contemporary Unix kernels always allocate zeroed pages to processes, so it's impossible for a process to recover data from another unless there's a kernel bug.


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


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 representation in memory might have easy to grep for delimiters.


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.


I successfully obtained the private key for my local Apache install this way once, though I'm having trouble getting anything reliable.


How many tries did it take to get the whole key?




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: