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:
- Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years], (continued)
- Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] Glen Wiley (Apr 15)
- Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] Scott Howard (Apr 15)
- RE: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] Barry Shein (Apr 15)
- Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] Jason Iannone (Apr 16)
- Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] Glen Turner (Apr 16)
- Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] Barry Shein (Apr 16)
- Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] TGLASSEY (Apr 16)
- Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] Scott Howard (Apr 16)
- Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] Barry Shein (Apr 16)
- Message not available
- Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] Larry Sheldon (Apr 16)
- Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] Scott Howard (Apr 16)
- Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] Warren Bailey (Apr 11)
- Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] William Herrin (Apr 11)
- Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] Scott Howard (Apr 15)