From owner-freebsd-security@FreeBSD.ORG Thu Sep 12 22:22:50 2013 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0939B42C; Thu, 12 Sep 2013 22:22:50 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D27022C8A; Thu, 12 Sep 2013 22:22:49 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r8CMMmkt004439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Sep 2013 15:22:49 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r8CMMmgf004438; Thu, 12 Sep 2013 15:22:48 -0700 (PDT) (envelope-from jmg) Date: Thu, 12 Sep 2013 15:22:48 -0700 From: John-Mark Gurney To: Jonathon Wright Subject: Re: FreeBSD Transient Memory problem? Message-ID: <20130912222248.GO68682@funkthat.com> Mail-Followup-To: Jonathon Wright , Guy Helmer , Julian Elischer , "freebsd-security@freebsd.org" References: <20130912053559.GF68682@funkthat.com> <979901F9-5F25-4DF1-95A8-32473C55B25F@gmail.com> <52320144.2090807@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 12 Sep 2013 15:22:49 -0700 (PDT) Cc: "freebsd-security@freebsd.org" , Guy Helmer , Julian Elischer X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 22:22:50 -0000 Jonathon Wright wrote this message on Thu, Sep 12, 2013 at 10:33 -1000: > Do you have a link to nCircle or site (my GoogleFu is not very strong, I > only got tripwire hits) nCircle was purchased earlier this year by Tripwire, hence why you only get tripwire hits now. Link: http://www.tripwire.com/company/news/press-release/tripwire-inc-acquires-ncircle/ > On Thu, Sep 12, 2013 at 10:05 AM, Guy Helmer wrote: > > > On Sep 12, 2013, at 2:33 PM, Jonathon Wright > > 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 > > 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 > > 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%** > > >>>> 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 > > >>>> > > >>>> "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" > > > > -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."