Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ