[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 3 Dec 2010 11:05:53 -0800
From: Geoff Keating <geoffk@...le.com>
To: oss-security@...ts.openwall.com
Cc: "Chad R. Dougherty" <crd@...t.org>,
David Svoboda <svoboda@...t.org>
Subject: Re: Interesting behavior with struct initiailization
On 03/12/2010, at 6:44 AM, Robert Seacord wrote:
> With respect to this specific problem:
>
>> then the compiler is free to change the padding bytes after 'x.b' to whatever it likes, because you changed 'x.a', even though you might >
>> think you cleared them and the compiler would have no reason to make this change. In practice this might manifest in the case of
>
>> memset (&x, 0, sizeof(x));
>> x.a = 1; x.b = 2; x.c = 3;
>
>> by the compiler optimising out the 'memset' as a dead store.
>
> CERT proposed #5 memset_s() to clear memory, without fear of removal (see http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1358.pdf).
Even if the memset is not removed, a compiler could implement 'x.b = 2' by
- setting the low byte of a 32-bit register to 2, leaving the high bytes unchanged
- storing all 32 bits of the register into memory
which would store nonzero data in the high bytes, possibly containing sensitive information.
Content of type "text/html" skipped
Download attachment "smime.p7s" of type "application/pkcs7-signature" (4221 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
