[cryptography] question about heartbleed on Linux
Does heartbleed allow one to read (discarded, freed) physical memory containing data from the OS and/or other processes in linux? A friend and I were discussing this. If the memory management is lazy (doesn't clear on page allocation/free), and if processes don't clear their own memory, I wondered if heartbleed would expose anything. My friend thinks modern operating systems clear memory to prevent inter-process data leakage. Of course, I agree that this is security goodness, but I wonder if, in the name of performance, this is optional. I'm poking around in linux memory management code in between other tasks, but I'll bet somebody here knows the answer. Anyone? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] question about heartbleed on Linux
On Thu, Apr 10, 2014 at 10:09:10AM -0700, Scott G. Kelly wrote: Does heartbleed allow one to read (discarded, freed) physical memory containing data from the OS and/or other processes in linux? Yes. It doesn't clear memory when it is freed, so you may end up allocating memory that has old content in it, perhaps even from swap. This is why you should clear your memory that contained secret data before freeing it, and preferably keep secrets in locked memory. B. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] question about heartbleed on Linux
On Thu, 10 Apr 2014 10:09:10 -0700 (PDT), Scott G. Kelly sc...@hyperthought.com wrote: My friend thinks modern operating systems clear memory to prevent inter-process data leakage. Of course, I agree that this is security goodness, but I wonder if, in the name of performance, this is optional. I think even early systems can't have allowed random memory contents to leak between processes. After all, insulating users from one another is pretty much the core Unix security notion. Someone more knowledgeable confirm? I'm poking around in linux memory management code in between other tasks, but I'll bet somebody here knows the answer. Anyone? Memory allocation via the brk system call is implemented internally as an anonymous mmap. The latter is specified to return zero-initialized memory. So both ways that malloc() uses to acquire virtual memory do initialize to zero. -pesco ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] question about heartbleed on Linux
I believe that the Linux kernel allocates a zero-page in the page table when a first-use (read) page fault occurs, and the zero-page is in fact zeroed out. Since Linux is copy-on-write, when a write occurs to an address that maps somewhere in that zero-page, a new page is allocated, the zero-page is copied to it and the write applied, and the page table is updated. So the short answer is that, no, I don't believe there is any way for another process's memory to accidentally bleed into the memory accessed by the heartbleed vulnerability. If recently free()d memory was likely to show up un-zeroed in another process's address space, we'd have enough concern about data leaks that it would end up being rolled into free() to auto-zero each page, since even in non-sensitive circumstances, you don't want one user to be able to run a simple program to sniff for other users' documents that were just in memory because they had it open in an editor... -Craig On Thu, Apr 10, 2014 at 10:09:10AM -0700, Scott G. Kelly wrote: Does heartbleed allow one to read (discarded, freed) physical memory containing data from the OS and/or other processes in linux? A friend and I were discussing this. If the memory management is lazy (doesn't clear on page allocation/free), and if processes don't clear their own memory, I wondered if heartbleed would expose anything. My friend thinks modern operating systems clear memory to prevent inter-process data leakage. Of course, I agree that this is security goodness, but I wonder if, in the name of performance, this is optional. I'm poking around in linux memory management code in between other tasks, but I'll bet somebody here knows the answer. Anyone? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] question about heartbleed on Linux
On Thu, Apr 10, 2014 at 11:48:15AM -0600, sch...@subverted.org wrote: On Thu, Apr 10, 2014 at 06:26:48PM +0100, Rob Kendrick wrote: | On Thu, Apr 10, 2014 at 10:09:10AM -0700, Scott G. Kelly wrote: | Does heartbleed allow one to read (discarded, freed) physical memory containing data from the OS and/or other processes in linux? | | Yes. It doesn't clear memory when it is freed, so you may end up | allocating memory that has old content in it, perhaps even from swap. Correct. FWIW, the grsecurity patch adds the [moderately expensive] capability to do this at the kernel level. I'm overextending myself, because I haven't crawled through the Linux memory allocation code any time in the past 10 years, but I'm pretty sure that while it is true that free() doesn't clear memory, that is only an issue for re-allocation in the same process (or in other threads, which are in the same memory space.) The original question was whether a processes could get uncleared memory from a *different* process, and I'm pretty sure that it can't. As I replied in my other message, I'm pretty sure that when a process is started, it has an empty page table. If you access a page that maps to the real 0x0-page, you get a page fault. The kernel then looks to see if the access is below the current brk value, and if it is, it writes the address of a common zero-page to the page table. This zero-page is always kept with contents of 0. Since Linux is COW (copy-on-write), every read in that page will return 0s, and the first time you try to do a write you'll trap into the kernel, the kernel will copy the zero-page (which is all zeros) to a new page (effectively clearing anything that might have been there from another process that might have free()d it), and it'll write that new page's physical address to the page table. So the OPs original concern/curiosity isn't a problem, as far as I can tell. That said, since most servers are multi-threaded, heartbleed will definitely allow memory to bleed between those threads, so that's bad enough... -Craig BTW. Sorry for the top-post last time... Forgot my net-manners. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] question about heartbleed on Linux
In article 20140410172648.gj8...@platypus.pepperfish.net you write: On Thu, Apr 10, 2014 at 10:09:10AM -0700, Scott G. Kelly wrote: Does heartbleed allow one to read (discarded, freed) physical memory containing data from the OS and/or other processes in linux? Yes. It doesn't clear memory when it is freed, so you may end up allocating memory that has old content in it, perhaps even from swap. I don't ever remember any Unix-ish or Linux system where the kernel didn't clear newly allocated process memory, other than perhaps some ancient tiny machines with no memory protection, and I've been in this biz since the 1970s. That would be a horrible security hole that malware would be exploiting directly, not by accident via something like heartbleed. I agree that these days the implementation is typically that new memory is page faulted in from the equivalent of /dev/zero. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] question about heartbleed on Linux
At 10:09 AM 4/10/2014, Scott G. Kelly wrote: Does heartbleed allow one to read (discarded, freed) physical memory containing data from the OS and/or other processes in linux? A friend and I were discussing this. If the memory management is lazy (doesn't clear on page allocation/free), and if processes don't clear their own memory, I wondered if heartbleed would expose anything. My friend thinks modern operating systems clear memory to prevent inter-process data leakage. Of course, I agree that this is security goodness, but I wonder if, in the name of performance, this is optional. I'm poking around in linux memory management code in between other tasks, but I'll bet somebody here knows the answer. Anyone? Well, the operating system clears memory when it is allocated to a new process, but that doesn't matter. The residue containing memory sits around until it's needed. And quite possibly during that time before it is re-allocated it is subject to disclosure via heartbleed. Ron ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] question about heartbleed on Linux
On Thu, Apr 10, 2014 at 10:31 PM, John Levine jo...@iecc.com wrote: Well, the operating system clears memory when it is allocated to a new process, That's plenty bad, of course. Yeah, too bad none of that memory can be made executable :) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] question about heartbleed on Linux
On Thu, Apr 10, 2014 at 1:09 PM, Scott G. Kelly sc...@hyperthought.com wrote: A friend and I were discussing this. If the memory management is lazy (doesn't clear on page allocation/free), and if processes don't clear their own memory, I wondered if heartbleed would expose anything. My friend thinks modern operating systems clear memory to prevent inter-process data leakage. Of course, I agree that this is security goodness, but I wonder if, in the name of performance, this is optional. I'm poking around in linux memory management code in between other tasks, but I'll bet somebody here knows the answer. Anyone? Last I remembered (and this was a long time ago; 10+ years, so things may have changed), the heap managed by malloc / free generally does not automatically clear the free'd or new allocated memory using something like memset by default. That is up to the application.Usually that is done by the application calling calloc() rather than malloc() when requesting memory from the heap. There may also be some explicit alternate memory allocation libraries (e.g., libmalloc might have this abilitiy; too lazy to look it up and it's be a LONG time). Also, the memory allocated on the stack (e.g., local variables and function arguments) is usually not cleared before use, although I suppose there could be some compilers that might / could do that. When memory is returned to the operating system, things may be different because it could be a different process that grabs that memory segment. So, is most of the cases that I've seen, it is considered good practice for the OS to that whenever the kernel maps some memory page to user address space. I believe that Linux does this but I've never done kernel programming in Linux, but only on ATT SVR[2,3,4] UNIX. At the time, it was done in SVR4, but it was inconsistent in that do all of the kernel used the same memory allocation routines. (The kernel itself didn't generally clear memory for it's own use as it already had access to all memory address space.) I'm not sure if that answers your question or not. If not, well, like I said it's be a long time that I've written C/C++ programs and even longer since doing an serious kernel work. -kevin ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] question about heartbleed on Linux
-Original Message- From: cryptography [mailto:cryptography-boun...@randombit.net] On Behalf Of Kevin W. Wall Sent: Friday, April 11, 2014 00:20 To: Scott G. Kelly Cc: Crypto discussion list Subject: Re: [cryptography] question about heartbleed on Linux On Thu, Apr 10, 2014 at 1:09 PM, Scott G. Kelly sc...@hyperthought.com wrote: A friend and I were discussing this. If the memory management is lazy (doesn't clear on page allocation/free), and if processes don't clear their own memory, I wondered if heartbleed would expose anything. My friend thinks modern operating systems clear memory to prevent inter-process data leakage. Of course, I agree that this is security goodness, but I wonder if, in the name of performance, this is optional. I'm poking around in linux memory management code in between other tasks, but I'll bet somebody here knows the answer. Anyone? Last I remembered (and this was a long time ago; 10+ years, so things may have changed), the heap managed by malloc / free generally does not automatically clear the free'd or new allocated memory using something like memset by default. That is up to the application.Usually that is done by the application calling calloc() rather than malloc() when requesting memory from the heap. There may also be some explicit alternate memory allocation libraries (e.g., libmalloc might have this abilitiy; too lazy to look it up and it's be a LONG time). Also, the memory allocated on the stack (e.g., local variables and function arguments) is usually not cleared before use, although I suppose there could be some compilers that might / could do that. Note that in the case of Heartbleed, zeroing the memory on deallocation would not have prevented information leakage. The memory following the read buffer is not necessarily unallocated. It will likely be in use by other sessions or parts of the process. As a matter of fact, OpenSSL clobbers memory that was used to hold sensitive information by means of the OPENSSL_cleanse() function before deallocation. The fact that it was possible to exfiltrate keys through Heartbleed thus shows that zeroing by the heap manager would not have made much of a difference. --Felix ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
