91–100 of 125 posts
We will add a $10,000 bounty for the first published and confirmed successful completion of this challenge. Conditions: 1) CloudFlare confirms success. 2) The winner publishes their solution, including source, publicly. 3) Promptly send the link to the publication to [adam | ionicsecurity | com] (for tracking the order of submissions) Good luck!
Didn't Juliano Rizzo already post that he'd been able to extract keys from a server? I'm not clear on the circumstances; for instance, it might have been right after boot, and it might have been Apache, and it might have been FreeBSD.
We will add a $10,000 bounty for the first published and confirmed successful completion of this challenge. Conditions: 1) CloudFlare confirms success. 2) The winner publishes their solution, including source, publicly. 3) Promptly send the link to the publication to [adam | ionicsecurity | com] (for tracking the order of submissions) Good luck!
That is awesome Adam, please have it posted on the Challenge page so that more people can see it. Hopefully someone solves it soon :)
Is this really an accurate challenge? I have wondered if the true exposure risk from Heartbleed may be over-stated* due to memory separation between processes, etc. This however is probably a clean server with a fairly static install. There isn't a risk of things like session leakage which I think is the true risk of Heartbleed. Nor would there be the memory fragmentation that would occur in a production system. Whil…
We will add a $10,000 bounty for the first published and confirmed successful completion of this challenge. Conditions: 1) CloudFlare confirms success. 2) The winner publishes their solution, including source, publicly. 3) Promptly send the link to the publication to [adam | ionicsecurity | com] (for tracking the order of submissions) Good luck!
That is awesome Adam, please have it posted on the Challenge page so that more people can see it. Hopefully someone solves it soon :)
so i assume any intermediate values from the RSA computations will end up in the heap and may be accessible by an attacker. is it possible to reconstruct the key from these values? i could be missing something but it looks like signing does m mod p and m mod q and part of these operations involves doing a left shift on the divisor (p, q) and this is allocated to a temporary buffer. if these buffers are allocated near…
> maybe this is not leaked or it requires a read at the correct time because these buffers might be trashed by another computation. As far as I can tell, it's certainly possible for intermediate data to be leaked, but it'd require pretty spectacular timing. That said, I'm having a bit of a hard time understanding why this challenge exists. If the possibility (even remote) exists that key material was leaked in any fo…
Would a multi-process server engine help protect against this? Think what Chrome does with tabs. If the network request is received by a dedicated IO process which then uses IPC to communicate with other parts of the server, then perhaps sensitive information like keys would not be in the same address space so could not be leaked? I guess if the bug was in a sensitive process then it would still happen. Disclaimer: I…
Even communicating over IPC you would still be vulnerable.
You can read more about the CloudFlare Challenge and our own tests on obtaining SSL Private Key material here: http://blog.cloudflare.com/answering-the-critical-question-c... Matthew Prince Co-founder & CEO, CloudFlare
I.e., is it a 8192-bit AES256 key?
so i assume any intermediate values from the RSA computations will end up in the heap and may be accessible by an attacker. is it possible to reconstruct the key from these values? i could be missing something but it looks like signing does m mod p and m mod q and part of these operations involves doing a left shift on the divisor (p, q) and this is allocated to a temporary buffer. if these buffers are allocated near…
> maybe this is not leaked or it requires a read at the correct time because these buffers might be trashed by another computation. As far as I can tell, it's certainly possible for intermediate data to be leaked, but it'd require pretty spectacular timing. That said, I'm having a bit of a hard time understanding why this challenge exists. If the possibility (even remote) exists that key material was leaked in any fo…
leaking the intermediate values in nginx to recover the private key looks like a dead end. however, i think this could be quite promising for apache mpm_worker. :)
Earlier quoted context omitted.
No, it works like this: everyone gets their fix ready hush hush, and on an agreed date it's made public, and vendors hit the "publish" button more or less simlultaneously.
Except that it doesn't work like this. The major Linux vendors are too decentralized for this to work.