Date: Thu, 12 Sep 2013 17:17:07 -0500 From: Guy Helmer <guy.helmer@gmail.com> To: Jonathon Wright <jonathon.s.wright@gmail.com> Cc: "freebsd-security@freebsd.org" <freebsd-security@freebsd.org>, John-Mark Gurney <jmg@funkthat.com>, Julian Elischer <julian@freebsd.org> Subject: Re: FreeBSD Transient Memory problem? Message-ID: <8573B6D6-0285-4167-9800-9DFC249694DA@gmail.com> 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 Sep 12, 2013, at 3:33 PM, Jonathon Wright = <jonathon.s.wright@gmail.com> wrote: > Thanks for those insights Guy. Makes sense that they are referring to = security boundaries (inter-process related) only. > =20 > 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? Security advisories are at = http://www.freebsd.org/security/advisories.html I believe I receive them on the lists freebsd-announce, = freebsd-security, and bugtraq (not a FreeBSD list). The sendfile advisory this week = (http://www.freebsd.org/security/advisories/FreeBSD-SA-13:11.sendfile.asc)= was about information disclosure as the result of issuing a sendfile() = for a length greater than the length of the file. I see other = information disclosure vulnerabilities, one in pipes = (http://www.freebsd.org/security/advisories/FreeBSD-SA-09:09.pipe.asc = and a prior one = http://www.freebsd.org/security/advisories/FreeBSD-SA-05:02.sendfile.asc),= one in firewire = (http://www.freebsd.org/security/advisories/FreeBSD-SA-06:25.kmem.asc) = and probably a couple of others I don't remember.=20 Point being: the project takes information disclosure issues very = seriously. > 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. > =20 > So few questions: > Do you know where I can get the book in an online copy? I'm not sure -- maybe Amazon? > Do you have a link to nCircle or site (my GoogleFu is not very strong, = I only got tripwire hits) Not sure about this either - sorry. Hope this helps, Guy > =20 > Thanks > =20 >=20 >=20 > On Thu, Sep 12, 2013 at 10:05 AM, Guy Helmer <guy.helmer@gmail.com> = wrote: > On Sep 12, 2013, at 2:33 PM, Jonathon Wright = <jonathon.s.wright@gmail.com> wrote: >=20 > > 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 >=20 > 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). >=20 > 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. >=20 > Guy >=20 > > On Thu, Sep 12, 2013 at 8:00 AM, Julian Elischer = <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> = 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=3D41875<http://forums.freebsd= .org/showthread.php?t=3D41875> > >>>>> 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%** > >>>> = 20v1.0.pdf<http://www.commoncriteriaportal.org:80/files/epfiles/nCircle%20= CR%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 > >>>> > >>>> "All that I will do, has been done, All that I have, has = not." > >>>> > >>> > >>> > >> > > _______________________________________________ > > 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" >=20 >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8573B6D6-0285-4167-9800-9DFC249694DA>