[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On 12/04/14 10:07, Martijn Grooten wrote: > On Sat, Apr 12, 2014 at 09:57:30AM +0100, Tom wrote: >> Even auditing the software would have not found this - it seems the >> RFC for it requests just what happened! > > That's incorrect, as xkcd pointed out yesterday: > > http://xkcd.com/1354/ > > The RFC states you should send the payload and its length, after which > the server returns the payload (and perhaps its length). The problem > with the implementation was that the receiving server didn't check > whether the length was actually the length of the payload and it just > returned this many bytes of memory. > >> It has, however, been confirmed you can get the the keys from a >> server. https://www.cloudflarechallenge.com/heartbleed > > Yes, that was in the link I sent. Note that the people at CloudFlare > were extremely sceptical about the possibility of something like this > happening. > > Martijn. > > Worth pointing out maybe that it seems that a reboot of your HTTPD daemon (Nginx, Apache, whatever) which initially loads its private key into a lower position on the heap is required for attackers to loot it successfully: the two security researchers who managed this sent 2.5 million and 100k individual requests respectively. This was to a specially setup vulnerable box running on Cloudflare - I sincerely hope that nobody in the real world would let a single IP batter their network like that before dropping the IDS ban hammer on them. Whilst *possible*, retrieving SSL private keys seems to be extremely difficult and Cloudflare themselves say that unless you just restarted your HTTPD, probably impossible. And just as I said right from the very start of this debacle, SSH keys are 100% safe. You can only read memory mapped from the relevant process, which seemed pretty obvious to me. Also just as I said, the devil is in the details of malloc and the heap, as explained properly here by an OpenBSD dev: http://www.tedunangst.com/flak/post/heartbleed-vs-mallocconf http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse The OpenSSL devs should be taken out and shot as far as I am concerned. They ignored best practices, didn't properly audit or QA (for two damn years) their own mission critical code and actually worked around the very protections that are designed to shield people from exactly this sort of madness. This has been a stark reminder to those of us in the trenches that our entire security infrastructure has been built on sand :[ Regards -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq