Hello everyone! Could you tell me if FreeBSD supports memory page nulling when releasing it to prevent unauthorized access to data left in the page after it's allocated again. If it does, what sys calls etc provide that? IMHO this is an important issue when operating data with different sensivity levels. Thanks in advance. Nick
On Sun, 18 Jun 2006 12:27:22 +0400 "Nick Borisov" <neiro21@gmail.com> wrote:> Hello everyone! > > Could you tell me if FreeBSD supports memory page nulling when > releasing it to prevent unauthorized access to data left in the page > after it's allocated again.I'm certainly not as expert in this area, but I thought I'd offer the following suggestions anyway (I'm assuming you're coding in C, here): - You might want to look at _malloc_options / MALLOC_OPTIONS (for example, '_malloc_options = "J";'), though this might be an expensive way to achieve the goal. See man 2 free for more information - You could zero a memory range explicitly before free()ing it, using bzero(3) or memset(3), for instance, or even just by assignment in some cases. This has the notable advantage that you can hand-pick which data you're zeroing based on individual merit> If it does, what sys calls etc provide that? > IMHO this is an important issue when operating data with different > sensivity levels. > > Thanks in advance. > > NickHope that helps! -- Nick Withers email: nick@nickwithers.com Web: http://www.nickwithers.com Mobile: +61 414 397 446
--- Nick Borisov <neiro21@gmail.com> wrote:> Could you tell me if FreeBSD supports memory page nulling when > releasing it to prevent unauthorized access to data left in the page > after it's allocated again. > If it does, what sys calls etc provide that? > IMHO this is an important issue when operating data with different > sensivity levels. >It is important, that no user process can look at non-shared (mmap(2) / MAP_SHARED) pages in main memory that were used by another process before. I think FreeBSD does it as follows (but I am not sure): 1. If a page is allocated for a process it is either overwritten with zeroes (0x00) (e. g. in case of a page for the stack segment of a process) or it is overwritten with the bytes of an executable or another file or so... 2. For maximum performance the system keeps a bunch of "pre-zero-ed" pages, so that the OS is quite fast, when a process wants pages for data (malloc(3)) or for stack. Here is my "proof": :-) % vmstat -s | grep zero 3840247 zero fill pages zeroed 844738 zero fill pages prezeroed -Arne __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Nick Borisov wrote:> Could you tell me if FreeBSD supports memory page nulling when > releasing it to prevent unauthorized access to data left in the page > after it's allocated again.Yes, FreeBSD has a mechanism for "zero-filling" used pages before they are allocated to another process, although this is normally deferred for a while to promote reuse of the page if the original process needs to use it again.> If it does, what sys calls etc provide that? > IMHO this is an important issue when operating data with different > sensivity levels.You can set some malloc() tunables to control some of this, although if you are trying to do secure programming of sensitive data, look towards mlock() to keep the data resident and unpageable to keep it out of the VM system and potentially the swapfile. Look at the source for GnuPG, for example, or OPIE... -- -Chuck
"Nick Borisov" <neiro21@gmail.com> writes:> Could you tell me if FreeBSD supports memory page nulling when > releasing it to prevent unauthorized access to data left in the page > after it's allocated again.Processes always get zeroed pages from the kernel. This is the case for all Unices, and has been for decades. DES -- Dag-Erling Sm?rgrav - des@des.no
2006/6/19, R. B. Riddick <arne_woerner@yahoo.com>:> But if a bad guy has already root access it does not really matter, > (aa) if he has to wait for some minutes or hours, > or > (bb) if he has just a small time window > or > (cc) if he can immediately start with scanning for secrets in /dev/mem.I would argue about this. Allowing an intrunder to deal with your system even one extra minute may lead to tremendous losses depending on what kind of data your system operates with. As Dan mentioned, the cost of data defines means of security you should use to protect it. As for standards, they are Russian national governmental ones appliyng to computer systems that operate confidential, secret and more sensitive data.
--- Nick Borisov <neiro21@gmail.com> wrote:> [...] Allowing an intrunder to deal with your > system even one extra minute may lead to tremendous losses depending > [...] >:-) OK.. Let's see, if I understood this right: 1 minute <-could be-> 1 tremendous loss 50 minutes <-could be-> 50 tremendous losses But what if a system just contains 5 tremendous chunks of secrets? Then it would not matter if we catch the attacker after 50 minutes or after 51 minutes... Even if we had a preparation time (before the loss starts) of 10 minutes (e. g. to install an evil kernel)... According to my experience attackers are not caught so quickly (and how should one do it? if the software is bad, than every connection could be evil; and of course even unusal connections (e. g. IP was never seen before or very high traffic to a single IP) could be good). I know personally of a case where somebody (mis(?))configured a NFS service (maybe it was a honey-pot, or so?), so that everyone had read/write access as _root_. It was possible to transfer about 20MB of data over about one hour from a single IP, that was never seen there before... The carrier of the system was a research centre (that works for several departments of the federal GERM government) with its own specially trained network/security administrators and a little nuclear power plant... -Arne __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
2006/6/19, R. B. Riddick <arne_woerner@yahoo.com>:> I know personally of a case where > somebody (mis(?))configured a NFS service (maybe it was a honey-pot, or so?), > so that everyone had read/write access as _root_. It was possible to transfer > about 20MB of data over about one hour from a single IP, that was never seen > there before...Well, you are not goin' to say that was a great achievement of those administrators, are you? =)