freebsd stable - Apr 2014 - OpenSSL CVE-2014-0160 (openssl) in 10-STABLE workaround?

Hi,

till it's fixed in base (which I hope is very soon) (or you replace 
openssl in base with the fixed version from ports or patch manually):

Would it probably help (with the performance impact in mind) to set 
malloc option junk:true to lower the risk of leakting information?

manpage says:

       "opt.junk" (bool) r- [--enable-fill]
           Junk filling enabled/disabled. If enabled, each byte of
           uninitialized allocated memory will be initialized to 0xa5. All
           deallocated memory will be initialized to 0x5a. This is intended
           for debugging and will impact performance negatively. This option
           is disabled by default unless --enable-debug is specified during
           configuration, in which case it is enabled by default unless
           running inside Valgrind[2].

as oppsosed to:

       "opt.zero" (bool) r- [--enable-fill]
           Zero filling enabled/disabled. If enabled, each byte of
           uninitialized allocated memory will be initialized to 0. Note that
           this initialization only happens once for each byte, so realloc and
           rallocm calls do not zero memory that was previously allocated.
           This is intended for debugging and will impact performance
           negatively. This option is disabled by default.


Anyone with better insights could comment on that?

- Oliver


-- 
| Oliver Brandmueller          http://sysadm.in/         ob at sysadm.in |
|                        Ich bin das Internet. Sowahr ich Gott helfe. |

Apparently OpenSSL intentionally subverts malloc, which is why the issue exists
at all... See also (cribbed, I confess, from Slashdot):

http://article.gmane.org/gmane.os.openbsd.misc/211963
http://www.tedunangst.com/flak/post/heartbleed-vs-mallocconf
http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse

On Apr 8, 2014, at 12:00 PM, Oliver Brandmueller <ob at e-Gitt.NET> wrote:
> Hi,
> 
> till it's fixed in base (which I hope is very soon) (or you replace 
> openssl in base with the fixed version from ports or patch manually):
> 
> Would it probably help (with the performance impact in mind) to set 
> malloc option junk:true to lower the risk of leakting information?
> 
> manpage says:
> 
>       "opt.junk" (bool) r- [--enable-fill]
>           Junk filling enabled/disabled. If enabled, each byte of
>           uninitialized allocated memory will be initialized to 0xa5. All
>           deallocated memory will be initialized to 0x5a. This is intended
>           for debugging and will impact performance negatively. This option
>           is disabled by default unless --enable-debug is specified during
>           configuration, in which case it is enabled by default unless
>           running inside Valgrind[2].
> 
> as oppsosed to:
> 
>       "opt.zero" (bool) r- [--enable-fill]
>           Zero filling enabled/disabled. If enabled, each byte of
>           uninitialized allocated memory will be initialized to 0. Note
that
>           this initialization only happens once for each byte, so realloc
and
>           rallocm calls do not zero memory that was previously allocated.
>           This is intended for debugging and will impact performance
>           negatively. This option is disabled by default.
> 
> 
> Anyone with better insights could comment on that?
> 
> - Oliver
> 
> 
> -- 
> | Oliver Brandmueller          http://sysadm.in/         ob at sysadm.in |
> |                        Ich bin das Internet. Sowahr ich Gott helfe. |
> _______________________________________________
> freebsd-stable at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at
freebsd.org"
>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 04/08/14 11:00, Oliver Brandmueller wrote:
> Would it probably help (with the performance impact in mind) to set
>  malloc option junk:true to lower the risk of leakting
> information?
[...]
> Anyone with better insights could comment on that?
Neither will help for CVE-2014-0160.

It's not the buffer newly allocated didn't get initialized, it's
reading beyond boundary of another buffer and thus these mitigation at
allocation side have nothing to do with the problem.

Hope this helps.

Cheers,
- -- 
Xin LI <delphij at delphij.net>    https://www.delphij.net/
FreeBSD - The Power to Serve!           Live free or die
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (FreeBSD)

iQIcBAEBCgAGBQJTRyh6AAoJEJW2GBstM+nsg6gP/RLb6lH9dY07IRIUHLIfnE1a
dzVmVnehS3KCkI6YZJLQSSaTSi48TRNttQMw1skNVffpQ6Xnk8aT8TIQI6YE61I0
m2DhXzcFylCyFpv2rOy0Y6c90uHoE98fwI2k1qA9cV4hxHN9M0hL1HxX35Wt1Sy/
vXcnbh4YUu17Pnu7t8irEcCI/Q+iz9Xqmjp9FzUT4+il5Ti4kmOerbGV7CKl+3Gj
kJApWKkZAavIqDCP8NthwJsK/eH1CRefU1HGMfAFwU7qd4XOaS655oPLS53lGPeK
r2wXzN2oKlXDchO2gvacGipDQN8QLNqfzPnMEwCvwaCsBcNYJt6suyXdYS+M8HWs
AwRsR4KeS+EF8a5OMjCFOUCSVkg5E88E6ZtwgmIehZyKRZIncY1E1QaMw2ys9kWX
Dy4MKGsSjmEoa2Gq/IGZQ9rY44scV8HysVo2V6JY7fQZm1s+EO5MjLcRooXiKeL0
GvM+pMTXNCfU5eXnkBW2vLKNrtbY7gFuhcTY/ixKCeu/WZ0SuwwgxXGGUHazsOS0
1Wl1Y7hjZao3CMDiaR0RUW43rSk9hxW/MMrh5+29kCoPERFeh3NCPqkdP4Wk+HiT
8PZzcBmJGiC26vJRWCSotMLCYwKSBuIQf+OlOgIs+9ZXcph36JowMz3GffP1ezbB
1pZOwklyRdMn5lhbtXdN
=Et0+
-----END PGP SIGNATURE-----