Date: Wed, 27 Jul 2011 11:19:54 -0700 From: Chuck Swiger <cswiger@mac.com> To: grarpamp <grarpamp@gmail.com> Cc: freebsd-security@freebsd.org Subject: Re: Malloc -Z Message-ID: <1E191B01-7DAA-48F3-8544-332D0282DA45@mac.com> 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
On Jul 27, 2011, at 10:16 AM, 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. No developer should ever assume that malloc(3) returns zeroed memory. If they want that, they need to use calloc(3), exactly as Sean said. >> 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. Most of those letters are already used for other aspects of malloc's behavior. > 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). No. If the software is only secure because of platform-specific flags which change the default malloc behavior, then the software isn't secure. > 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? The kernel keeps a pool of prezero'ed pages available which it provides to processes when they need them. There shouldn't be a disclosure of information from one process to another, even if the first process never zeros memory. However, this being said, it is recommended that processes using getpass() and similar with OpenSSL keys ought to zero out the password or private key buffers as soon as possible to avoid leaving plain-text passwords in memory. Anything which provides direct DMA access, such as eSATA or firewire controllers, etc, can be used to scan memory for plaintext passwords, even if the operating system otherwise maintains good security between processes. Regards, -- -Chuck
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1E191B01-7DAA-48F3-8544-332D0282DA45>