2014.04.20. 7:47, "Riku Voipio" <riku.voi...@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.voi...@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
>
>
