Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 30 Nov 2011 09:41:45 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: .bss size in -jumbo

2011-11-29 22:20, magnum wrote:
> 2011-11-29 21:10, jfoug wrote:
>> I did not add any 'memset' after allocations on the changes magnum has made.
>> Like I said, it 'may' not be an issue anywhere.  However, the md5 std format
>> caused one of my builds to core, due to not memsetting the buffer to start
>> with, and then a strlen() call was returning a HUGE string.  Skipping memset
>> on these formats 'may be' safe, but who knows.
> 
> I admit not being 100% sure, but I opted to memset only where I believe
> it's needed. The sapG and sapB formats got memsets, the rest should be
> fine without it.

2011-11-29 22:21, jfoug wrote:
> I have found that many of these also required a memset of zero. I am
> not sure if the build was special (the problem I found was in a 
> win32-cygwin-x86-sse2 build).
> 
> Thus, I will be putting out a new memset after alloc patch, if magnum
> does not beat me to it.

I don't object to the memsets at all (and I could reproduce the problem
on a couple of OMP build targets), but I really wonder what is the
culprit. I picked mschapv2 as an example and reviewed the code again. In
no place does it assume any of the arrays is zeroed. I almost want to
debug this, out of curiosity. It's easy now - I could change the memset
to fill with 0xAA instead :-)

magnum

Powered by blists - more mailing lists

Your e-mail address:

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