Malloc -Z

Xin LI delphij at delphij.net
Wed Jul 27 19:21:43 UTC 2011


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 07/27/11 10:16, grarpamp wrote:
>> malloc(3) has never provided zeroed memory. If you need zeroed
>> memory in C, you either need to zero it yourself using memset(3),
>> or use calloc(3).
> 
> Or, in lieu, use -Z, presumably.
> 
>> What would be prudent as a developer (and is the default in CURRENT
>> I believe) is to use J - it enforces the "memory from malloc(3) is
>> not guaranteed to be zeroed." by specifically setting it to
>> non-zero.
> 
> Hmm, well for debugging/fuzzing programs, Z or J could be useful. As
> would new R(random), 5(0x55), a(0xaa), and f(0xff) variations.
> 
> But for security, it seems running with any of them set would be wise
> or flat out required. No? As in the case where users are untrusted
> (mischievous, but unable to gain root).

We usually want programs to "crash early" when there comes a bug, as if
there is one uncovered bug, there is likely to be more bug undiscovered.

My personal experience is that most C programs crashes when the buffer
is not initialized properly rather than misbehaving and Z makes them
"work" rather than break.  Zero'ing memory usually gives consistent
behavior (not to crash) rather than else.  That's exactly why the
- -CURRENT branch uses J and not Z by default.

> Because while your own shiny new program may zero on free, all the
> other installed programs that handle 'sensitive' data may not. And
> without using say, Z... any user could scrape the box. Right?

Programs that handles sensitive data should hold the sensitive data in
memory as short as possible.  Zeroing the memory ensures that "they are
not there", as free(3) is not guaranteed to give the memory back to the
kernel, which in turn WILL zero the page before handing it to another
process.

Cheers,
- -- 
Xin LI <delphij at delphij.net>	https://www.delphij.net/
FreeBSD - The Power to Serve!		Live free or die
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (FreeBSD)

iQEcBAEBCAAGBQJOMGVFAAoJEATO+BI/yjfB/vIIAKT1X/tF5gJ3waFzdPCG9T7h
fKjSXqmxDzcV1cjn6BBc2GVhXOsCdGQE7P2Kc+t6xefZfBFXedDpMVRcPI+l506X
uvy2OOxNowT/WkBaeJP1LqIfBBD9nQqrczFg+YjEhuvLGK3Q6K1BGlxXJtZjTvfH
KgUiVZ1fog5Av2oXcCcx5qsDyltL8z/cy+JCjD7UQdt7TqZj9KGPLVHk5+tx0W71
UVWrxPU5V4MaAUqXjNott5Gzyh5uO6aemQkEKCH2jV7HUe15H9okX29I5/FJjK+Q
MRqRLbMN3tamsRCjjfZY5jQhEZNFzDFmK7qfUQeqMc3p5oTOdlEZFTxiRTabSMA=
=fqoZ
-----END PGP SIGNATURE-----


More information about the freebsd-security mailing list