diff options
| author |   miod <miod@openbsd.org> | 2014-04-22 21:52:21 +0000 |
|---|---|---|
| committer | miod <miod@openbsd.org> | 2014-04-22 21:52:21 +0000 |
| commit | 987edc824c759a2ed74c8af38a07790fe8b10d12 (patch) | |
| tree | 720f851a98610462c66fd906e6aff476a205094e /lib/libc/stdlib/malloc.c | |
| parent | When compiling with AES_WRAP_TEST, make main() return a meaningful value (diff) | |
| download | wireguard-openbsd-987edc824c759a2ed74c8af38a07790fe8b10d12.tar.xz wireguard-openbsd-987edc824c759a2ed74c8af38a07790fe8b10d12.zip | |
So it turns out that libcrypto on i386 platforms, unconditionaly compiles this
little gem called OPENSSL_indirect_call(), supposedly to be ``handy under
Win32''.
In my view, this is a free-win ROP entry point. Why try and return to libc
when you can return to libcrypto with an easy to use interface?
Better not give that much attack surface, and remove this undocumented
entry point.
ok beck@ tedu@
Diffstat (limited to 'lib/libc/stdlib/malloc.c')
0 files changed, 0 insertions, 0 deletions