Date: Fri, 13 Sep 2013 12:21:00 +0800 From: Julian Elischer <julian@freebsd.org> To: Jonathon Wright <jonathon.s.wright@gmail.com> Cc: "freebsd-security@freebsd.org" <freebsd-security@freebsd.org>, John-Mark Gurney <jmg@funkthat.com>, Guy Helmer <guy.helmer@gmail.com> Subject: Re: FreeBSD Transient Memory problem? Message-ID: <523292AC.1050907@freebsd.org> In-Reply-To: <CAGX1DMY=bSpOkzHT=4mYVfSb_tUR6TVTwZqnUcNM-ORa-GBsRg@mail.gmail.com> References: <CAGX1DMbQP=TggYQm-3hra0Od3gjgz5xQ8bEMMrueuhL6kuZMUA@mail.gmail.com> <20130912053559.GF68682@funkthat.com> <979901F9-5F25-4DF1-95A8-32473C55B25F@gmail.com> <52320144.2090807@freebsd.org> <CAGX1DMYAheUAV_eB4Z4R_YaMDx_LzrepEag5KyBC=EOxzhUiMQ@mail.gmail.com> <EC4378DB-3AF0-40F7-98BC-0FE6D318938E@gmail.com> <CAGX1DMY=bSpOkzHT=4mYVfSb_tUR6TVTwZqnUcNM-ORa-GBsRg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 9/13/13 4:33 AM, Jonathon Wright wrote: > Thanks for those insights Guy. Makes sense that they are referring > to security boundaries (inter-process related) only. what's the name of the "security" company? maybe we can publicly lambast them as idiots on slashdot. > I didn't get the reference (witness the sendmail() security advisory > earlier this week). Was there a reference to this issue in the one > earlier this week, and / or how do I view the security advisories? > As far as the book, I am trying to find an online version that I can > copy / paste out the section that would talk about this. > I did go back to the teams local rep who is simply "tracking" the > item. He stated that the "proof" would preferrably be an EAL cert, > but verbiage in that book or other "formal" documenation would be > considered. > So few questions: > Do you know where I can get the book in an online copy? > Do you have a link to nCircle or site (my GoogleFu is not very > strong, I only got tripwire hits) > Thanks > > > On Thu, Sep 12, 2013 at 10:05 AM, Guy Helmer <guy.helmer@gmail.com > <mailto:guy.helmer@gmail.com>> wrote: > > On Sep 12, 2013, at 2:33 PM, Jonathon Wright > <jonathon.s.wright@gmail.com > <mailto:jonathon.s.wright@gmail.com>> wrote: > > > I agree, really, I do. This is very frustrating to me. > Unfortunately, the > > team has left and gone to another project. They indicated to > our management > > that we had 90 days to address the issue with our plan. Its a > bit harder to > > contact them now since they are gone, but I can probably get > some questions > > to them. They did leave a copy of the report, here is the > entire verbiage: > > > > ---BEGIN > > > > *Description of Finding:* Object reuse cannot be verified. The > FreeBSD > > servers used have not been evaluated or certified by NIAP. As > such, it > > cannot be verified that the operating system ensures transient > memory > > cleansing (object reuse) features are in place. > > > > *Rationale for Severity Code Determination:* The Validation > team has > > determined this to be a Category II finding. By using > unapproved Operating > > Systems (OS) which do not ensure that no residual data from a > former object > > exists, a malicious user could gain access to memory and OS > objects that > > contain sensitive information. > > > > *Recommended Countermeasure(s):* Transition servers to an NIAP > approved OS. > > Decommission the FreeBSD servers. > > ---END > > > > What I think they are looking for is a verification that every > malloc has a > > call to free afterwords that zeros out the memory used. I > could be wrong, > > but just a guess. > > > > JW > > Two common forms of object reuse are in memory allocation to a > process and in blocks allocated to a file. As far as I > understand the issue, malloc/free within a single process would > not be a relevant concern (generally, only inter-process > activity crosses security boundaries). A malloc that causes VM > pages to be assigned to the process by the kernel, or file > writes that cause blocks to be allocated to a file, would be the > among the relevant issues. Unfortunately, as I'm not a VM or FS > guru, I can't point to particular points in the kernel source > that show that memory is zeroed when allocated to a new process, > or blocks are zeroed when allocated to a file. However, this is > fundamental to secure operation of any modern system, and if > there is *any* evidence that FreeBSD operates to the contrary, > it would be worthy of a security advisory (witness the > sendfile() security advisory from earlier this week). > > I don't have a copy of "Design and Implementation of FreeBSD" > handy, but I would imagine it points out the relevant code > paths. However, it seems your management wants evidence of EAL > certification, not evidence from code. Perhaps you can borrow > such certification from nCircle or others. > > Guy > > > On Thu, Sep 12, 2013 at 8:00 AM, Julian Elischer > <julian@freebsd.org <mailto:julian@freebsd.org>> wrote: > > > >> On 9/13/13 1:49 AM, My Email wrote: > >> > >>> My apologies, I have been replying too all, I hope that is > the correct > >>> method. > >>> > >>> Anyway, that is very interesting information. I'd be > extremely interested > >>> in information on customizing malloc and jemalloc. Let me > know where to > >>> start. Thanks! > >>> > >> > >> it's hard to know how to refute it because they don't explain > WHAT memory > >> they are talking about. > >> there is NO OS in the world that can survive that test if > they are talking > >> about protection from a malware kernel module. > >> On the other hand if they are just talking about user memory > allocation > >> then of course we NEVER hand uncleared memory to anyone. > (even root). Ask > >> them to tell you what memory they are talking about.. > >> and if they want free memory in the pool to be clear then it > wouldn't take > >> much to > >> add a module that zeros non vnode memory when it's handed > back to the > >> kernel. > >> > >> But for all we know they are talking about people stealing > punch cards and > >> photographing them.. > >> > >> JW > >>> > >>> On Sep 11, 2013, at 7:35 PM, John-Mark Gurney > <jmg@funkthat.com <mailto:jmg@funkthat.com>> wrote: > >>> > >>> Jonathon Wright wrote this message on Wed, Sep 11, 2013 at > 14:15 -1000: > >>>> > >>>>> I have posted this question (username-scryptkiddy) in the > forums: > >>>>> > http://forums.freebsd.org/**showthread.php?t=41875<http://forums.freebsd.org/showthread.php?t=41875> > >>>>> but was suggested to bring it here to the mailing list for > discussion. > >>>>> > >>>>> Basically, FreeBSD 8.3 (64bit) is what we use in our shop. > We were > >>>>> inspected by a security team and they had issues with > FreeBSD's memory > >>>>> management. > >>>>> > >>>>> Namely the transient memory and object reuse areas of > FreeBSD. They > >>>>> claimed > >>>>> that FreeBSD did not have a Common Criteria (EAL1-4) > evaluation > >>>>> completed, > >>>>> and therefore was vulnerable to the Transient memory problem. > >>>>> > >>>> Any system that uses malloc will have difficulties with > this as most > >>>> versions of free will not zero out the memory... You could > make > >>>> modifications to kernel malloc to always zero memory on > free, and turn on > >>>> the junk feature of jemalloc and that could possibly close > this issue > >>>> for them... > >>>> > >>>> Our higher ups need some sort of documentation / testing > that can be > >>>>> used > >>>>> to counter this, since changing Operating Systems is not > something we > >>>>> have > >>>>> time / manpower to do, but might have too based on this > supposed > >>>>> 'finding'. > >>>>> > >>>>> The post has all the details. Let me know I need to repost > in this as > >>>>> well. > >>>>> > >>>> I know that FreeBSD 4.7 and 4.9 has been EAL3 ceritfied. I > worked for > >>>> nCircle a number of years ago, and they got their products EAL3 > >>>> cerified. > >>>> > >>>> Link: > >>>> > http://www.**commoncriteriaportal.org:80/**files/epfiles/nCircle%20CR%** > <http://commoncriteriaportal.org:80/**files/epfiles/nCircle%20CR%**> > >>>> > 20v1.0.pdf<http://www.commoncriteriaportal.org:80/files/epfiles/nCircle%20CR%20v1.0.pdf> > >>>> > >>>> It is possible someone else has received certification on a > newer > >>>> version, > >>>> but I'm not aware of any at this time... > >>>> > >>>> -- > >>>> John-Mark Gurney Voice: +1 415 225 5579 > <tel:%2B1%20415%20225%205579> > >>>> > >>>> "All that I will do, has been done, All that I have, > has not." > >>>> > >>> > >>> > >> > > _______________________________________________ > > freebsd-security@freebsd.org > <mailto:freebsd-security@freebsd.org> mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-security > > To unsubscribe, send any mail to > "freebsd-security-unsubscribe@freebsd.org > <mailto:freebsd-security-unsubscribe@freebsd.org>" > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?523292AC.1050907>