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
--Apple-Mail=_5ACB6A6C-91B4-4C5D-A5BA-DAE79AA198E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 21.4.2014, at 6.06, Jamie Landeg-Jones <jamie@dyslexicfish.net> = wrote: > "hcoin" <hcoin@quietfountain.com> wrote: >=20 >> local variables) harms performance. It's also true doing both of = these=20 >> things would not fix the flaw that 'opened the window' onto these = data. =20 >> However it is true that doing so would make the exploit valueless as=20= >> 'opening a window' onto erased data would reveal nothing and could = erase=20 >> trojan/virus 'hijack via code-injection then trampoline' = opportunities. >=20 > 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=92s called failure to validate input parameters before = using the input parameters or derived values from the input parameters = as array indices.=20 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()=92d until the process = terminates) in unprotected form (plain text essentially) for fast access = during encryption and decryption. -Kimmo --Apple-Mail=_5ACB6A6C-91B4-4C5D-A5BA-DAE79AA198E4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTVTfeAAoJEFvLZC0FWRVpHfMIAKPW0sIvgfGv2BlTdyw5lADB MPWXB/P3E7HGfY5gKCrn7X2XOgdv6omg9WvZqS5WhRdFXM4MEAMYQBstgEP9mJgu N9RXCbhic08vQDWQdmGcGyh9tknPlitilYiRpMZ2yMCAbU6dan0GRP0fxYUeqaWn iK+j2f4gF8KJl0XPPCd3f3pC08LoNGCLV61yClJJ8R/fv5T6GX79oBQrwLslmzjR TB0i1DDLALuhXqAVxQtRDqcZHAJMha3Y1oxW/UQL79UfcKE9JDjvNrN7lhPotuCq UHWg0dhVa05ocFM0tDNNtpQ1R3ik26vCLA4T/Q9nlVERBAVGLCsm0iIWj3R9yms= =Lk0k -----END PGP SIGNATURE----- --Apple-Mail=_5ACB6A6C-91B4-4C5D-A5BA-DAE79AA198E4--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?89978872-0943-417C-9A96-9DB24E5D6CB8>