[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <040b01ccaee2$21ed1810$65c74830$@net>
Date: Tue, 29 Nov 2011 15:59:13 -0600
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: .bss size in -jumbo
>Yes. Another way to approach this, though, is by introducing a
>debugging feature into our memory.c where, when the feature is in fact
>temporarily enabled for debugging, the allocated memory would be
>initialized to a "bad" value that is likely to cause bugs to manifest
>themselves. After such debugging and fixing of the bugs (if any), we'd
>disable the initialization again (till next time we need to check for
>possible bugs of this nature).
What I have seen, is not 'bugs', but an assumption that the buffer is NULL
when the program starts. So, for md5_std, we simply drop the 15 bytes over,
leaving that 16th byte alone, and things worked. However, when the memory
set set to CDCDCD..... which is what the debug malloc does, it caused no
null bytes, and went belly up. There are other formats which also depend
on the assumption that these arrays are initially NULL.
Jim.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
