nanog mailing list archives

Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]


From: Scott Howard <scott () doc net au>
Date: Wed, 16 Apr 2014 17:14:09 -0700

On Wed, Apr 16, 2014 at 4:12 PM, Larry Sheldon <LarrySheldon () cox net> wrote:

If the hardware (as has been suggested) or the OS does any of this, how do
diagnostic routine in or running under the OS work?


The OS does it, when allocating memory to userland programs.

For memory, before memory is allocated to a new process it is cleared.  If
the same block of memory is re-allocated to (or within) that process then
it is generally NOT cleared.  ie, if you request some memory within a
process there's no guarantee that it'll be zeroed out (unless you
specifically request it to be), but there is a guarantee that anything in
the memory is something that your own process put there.

For kernel-level code, this does NOT happen by default (again, depending on
which exact functional you call). So within the kernel you can allocate a
block of memory and end up with random user-land data it in - but if you
think that's a problem then you probably don't understand where the kernel
fits in within the bigger picture. (Hint: at a minimum, it can real any
memory anywhere in the system)

There is obviously a cost of clearing that memory, which is why it's
normally only done when absolutely necessary (eg, allocating a new page to
a userland process), but not when it's not (eg, allocating to the kernel)


For disk, physical space normally isn't assigned by the filesystem until
you actually write to a block. Writing obviously overwrites what was there
previously, so reading it back only gives you your own data.  If you read
back an area of a file that you haven't yet written (presuming the
filesystem supports it) then you've got what's called a "sparse" file, and
as no block on disk has yet been allocated for that space yet the OS simply
returns you a pile of zeros. Those zeros never actually existed on the
disk, they are just a logical concept for any blocks that have not yet been
written to.


None of these controls stops someone with root access from accessing memory
or disk - root generally has access to interfaces like /proc/mem and the
raw disk devices, so can read anything.

  Scott


Current thread: