zlib security - permanent fix to the real problem?
daniel at roe.ch
Wed Mar 13 02:17:09 PST 2002
Kevin Krumwiede <krum at smyrnacable.net> wrote:
> Yes, someone with more know-how please comment on this, for I am
FWIW, I think this is a fix (or workaround, rather).
with MALLOC_CHECK_=0 your tester should silently ignore the second
call to free and reach the printf. Without corrupting the heap.
> The question is: Do either of these settings (1 or 2) actually
> prevent the program from corrupting the heap?
yes. the segfault is a direct sign of the heap corruption; it does
not (well, should not) happen with any of the MALLOC_CHECK_
settings (0, 1, 2).
> If so, does this address the zlib issue, at least as an interim
Me thinks so. But I've barely had the time to recompile vulnerable
software, much less to actually have a look at the problem in
detail. If you want to make sure, you can try it with the
png-of-death.png that was posted on bugtraq. search the bugtraq
archives for it.
> Or maybe this is something we should all do by default, zlib
> issues aside?
Depends what you are using your box for. If performance is
critical, then setting this might not be an option. On the average
workstation however there should be no harm in enabling it, I guess.
Daniel Roethlisberger <daniel at roe.ch>
PGP Key ID 0x8DE543ED with fingerprint
6C10 83D7 2BB8 D908 10AE 7FA3 0779 0355 8DE5 43ED
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-security' in the subject header of the message
More information about the lfs-security