Date: Wed, 27 Jul 2011 12:21:41 -0700 From: Xin LI <delphij@delphij.net> To: freebsd-security@freebsd.org Subject: Re: Malloc -Z Message-ID: <4E306545.6060008@delphij.net> In-Reply-To: <CAD2Ti29g_=kW=eMDfe0Z-xcObhT4Fs-0w8T1F1WdBqM-2Ar6NQ@mail.gmail.com> References: <CAD2Ti2_xCSzjB6eC0pUU6DHj7OSsmE_E4ikgDRx=CU3un64LoA@mail.gmail.com> <CAF3EE36-98E2-4265-A1C9-DA9671AB89C5@gothic.net.au> <CAD2Ti29g_=kW=eMDfe0Z-xcObhT4Fs-0w8T1F1WdBqM-2Ar6NQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
-----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@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-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E306545.6060008>