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.
BTW Amazon AWS/ELM is vulnerable, confirmed publically by their support.
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.
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.
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.
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
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.