[171046] in North American Network Operators' Group
Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
daemon@ATHENA.MIT.EDU (Glen Turner)
Wed Apr 16 20:33:54 2014
From: Glen Turner <gdt@gdt.id.au>
In-Reply-To: <CAGL1wDRb8cmfDwouRkL9Fj0j1axqusqjFhbiyx_1-u4dyn_+Xg@mail.gmail.com>
Date: Thu, 17 Apr 2014 10:03:08 +0930
To: Jason Iannone <jason.iannone@gmail.com>
Cc: North American Network Operators' Group <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Jason Iannone wrote:
> I can't cite chapter and verse but I seem to remember this zeroing
> problem was solved decades ago by just introducing a bit which said
> this chunk of memory or disk is new (to this process) and not zeroed
> but if there's any attempt to actually access it then read it back as
> if it were filled with zeros, or alternatively zero it.
That's true of virtual memory pages which are new to the process.
But that isn't what malloc() usually returns, otherwise all malloc()ed =
allocations would require a 4KB virtual memory page. Rather malloc() and =
free() in the C library manage a pool of allocations and when that pool =
empties more virtual memory is allocated by using the brk() system call =
to ask the operating system for a new 4KB page of virtual memory -- =
which the operating system does set to zero, using the hardware to =
(perhaps lazily) set the page to zero if such a hardware feature is =
available.
As a result the memory returned by malloc() often isn't zeroed and may =
contain data previously used by the process. Therefore a process can =
leak information between a program and its use of libraries.
Because there is no inter-process information leakage this isn't seen as =
a problem in the traditional Unix view of security. You may have =
differing views if your program is a daemon servicing a multitude of =
networked users. Thus the interest in alternative malloc() and free() =
implementations.
--=20
Glen Turner <http://www.gdt.id.au/~gdt/>=
