Date: Mon, 21 Apr 2014 18:23:07 +0300 From: Kimmo Paasiala <kpaasial@icloud.com> To: Jamie Landeg-Jones <jamie@dyslexicfish.net> Cc: freebsd-security@freebsd.org Subject: Re: De Raadt + FBSD + OpenSSH + hole? Message-ID: <89978872-0943-417C-9A96-9DB24E5D6CB8@icloud.com> In-Reply-To: <201404210306.s3L36JfU020865@catnip.dyslexicfish.net> References: <534B11F0.9040400@paladin.bulgarpress.com> <201404141207.s3EC7IvT085450@chronos.org.uk> <201404141232.s3ECWFQ1081178@catnip.dyslexicfish.net> <53522186.9030207@FreeBSD.org> <201404200548.s3K5mV7N055244@catnip.dyslexicfish.net> <53540307.1070708@quietfountain.com> <20140421000122.GS43976@funkthat.com> <53546795.9050304@quietfountain.com> <201404210306.s3L36JfU020865@catnip.dyslexicfish.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On 21.4.2014, at 6.06, Jamie Landeg-Jones <jamie@dyslexicfish.net> wrote: > "hcoin" <hcoin@quietfountain.com> wrote: > >> local variables) harms performance. It's also true doing both of these >> things would not fix the flaw that 'opened the window' onto these data. >> However it is true that doing so would make the exploit valueless as >> 'opening a window' onto erased data would reveal nothing and could erase >> trojan/virus 'hijack via code-injection then trampoline' opportunities. > > In the heartbleed case, was the bug returning stale freed memory, though? > Couldn't it just as easily have been that the over-read was returning any > other memory that the process has had allocated for other variables - data > that was still in use? No, the problem was another type of programming error that is endemic in C programming. It’s called failure to validate input parameters before using the input parameters or derived values from the input parameters as array indices. https://en.wikipedia.org/wiki/Bounds_checking The bug allowed an attacker to request any number of bytes from memory that followed the buffer that the client was usually allowed to access (depending on how the index was interpreted it might have been possible to request memory before the buffer as well). The part of memory that followed the buffer very probably contained some very sensitive information, possibly secret keys that were loaded in memory (memory that was constantly in use and not free()’d until the process terminates) in unprotected form (plain text essentially) for fast access during encryption and decryption. -Kimmo [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTVTfeAAoJEFvLZC0FWRVpHfMIAKPW0sIvgfGv2BlTdyw5lADB MPWXB/P3E7HGfY5gKCrn7X2XOgdv6omg9WvZqS5WhRdFXM4MEAMYQBstgEP9mJgu N9RXCbhic08vQDWQdmGcGyh9tknPlitilYiRpMZ2yMCAbU6dan0GRP0fxYUeqaWn iK+j2f4gF8KJl0XPPCd3f3pC08LoNGCLV61yClJJ8R/fv5T6GX79oBQrwLslmzjR TB0i1DDLALuhXqAVxQtRDqcZHAJMha3Y1oxW/UQL79UfcKE9JDjvNrN7lhPotuCq UHWg0dhVa05ocFM0tDNNtpQ1R3ik26vCLA4T/Q9nlVERBAVGLCsm0iIWj3R9yms= =Lk0k -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?89978872-0943-417C-9A96-9DB24E5D6CB8>