2014.04.20. 7:47, "Riku Voipio" <riku.voipio@iki.fi> ezt írta:
>
> On Sat, Apr 19, 2014 at 02
On Sat, Apr 19, 2014 at 02:06:45PM +0200, Bálint Réczey wrote:
> Hi Riku,
>
> 2014-04-19 13:26 GMT+02:00 Riku Voipio <riku.voipio@iki.fi>:
> > On Tue, Apr 15, 2014 at 12:00:33PM +0200, Balint Reczey wrote:
> >> Facing last week's Heartbleed [1] bug the need for improving the
> >> security of our systems became more apparent than usually. In Debian
> >> there are widely used methods for Hardening [2] packages at build time
> >> and guidelines [3] for improving the default installations' security.
> >
> > Riding the Heartbleed publicity wave seems unwise, unless you can
> > propose a hardening flag that would have protected users from
> > Heartbleed. Else, Heartbleed merely serves on a example
> > how wallpapering problems over with "hardened" binaries often
> > doesn't help you at all..
> >
> > Considering that most issues protected by compiler hardening are
> > also detectable by static/dynamic code analysis, a more effective security
> > measure would be to spend time with clang static analyzer, valgrind, trinity
> > and other tools... or actualy reviewing patches that security critical
> > projects recieve.
> Thank you for bringing this up now.
> I have just managed to compile openssl, without the fix for the
> Heartbleed test but with -fsanitize=address, and as I expected it
> avoids leaking anything, I see only this in the Apache2's error.log:
> ...
> [Sat Apr 19 13:44:58.818704 2014] [core:notice] [pid 18456:tid
> 3068020544] AH00094: Command line: '/us
> r/sbin/apache2'
> =================================================================
> ==18459==ERROR: AddressSanitizer: heap-buffer-overflow on address
> 0xb4960411 at pc 0xb547a785 bp 0xb14f7c88 sp 0xb14f7c7c
> READ of size 1 at 0xb4960411 thread T2
> ASAN:SIGSEGV
> ==18459==AddressSanitizer: while reporting a bug found another one.Ignoring.
> =================================================================
> ==18461==ERROR: AddressSanitizer: heap-buffer-overflow on address
> 0xb4960411 at pc 0xb547a785 bp 0xaf86bc88 sp 0xaf86bc7c
> READ of size 1 at 0xb4960411 thread T5
> ASAN:SIGSEGV
> ==18461==AddressSanitizer: while reporting a bug found another one.Ignoring.
> ...
>
> Since this is exactly the flag I looked at for amd64-hardened, if we
> had this arch existing a few weeks ago it would have prevented
> successful attacks on this platform.
Well this is certainly impressive - I was not aware of AddressSanitizer,
seems like very powerful and easy to us instrumentation tool.
AddressSanitizer does not look like a flag intended for hardening. The
performance slowdown is quite steep. The instrumentation code itself might
be buggy, causing exploitation potential in itself.
Essentially this sounds about as wise as running server code under
valgrind.
> I used Heartleech for triggering the bug and the attached debdiff on openssl.
>
> The PoC is fragile because you need to set LD_PRELOAD=libasan1 and
> compile the package with the following command:
> CC=gcc-4.9 DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage -rfakeroot -us -uc
>
> I have also disabled OpenSSL's feelist implementation because any
> custom memory handling would be disabled on amd64-hardened to let ASAN
> work effectively.
>
> During creating the PoC I have hit several bugs which I had to work
> around in the patch:
>
> Changes:
> openssl (1.0.1f-1~dontuseheartbleedtest) UNRELEASED; urgency=low
> .
> * Enable -fsanitize=address
> * Disable freelist using -DOPENSSL_NO_BUF_FREELISTS
> * Add patch to fix freelist reuse from here:
> http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse
> * CVE-2014-0160 a.k.a Heartbleed is not fixed in this version!
> * Add patch 'Check i before r[i]' to fix buffer overflow by reading
> * Export ssl3_write_bytes() for compiling Heartleech
> * Use -DOPENSSL_NO_ASM to prevent crash in OPENSSL_cpuid_setup on i386
This doesn't really look like a magical "if it was just compiled with
hardening flags, this wouldn't have happened" case. The PoC required
elobarate knowledge where the bug was and how it was hidden by
openssl's memory allocations. With -DOPENSSL_NO_BUF_FREELISTS the bug
would have been found with static analysis anyways...
Riku