From owner-freebsd-security@FreeBSD.ORG Thu Sep 12 22:17:11 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 2DAC5121; Thu, 12 Sep 2013 22:17:11 +0000 (UTC) (envelope-from guy.helmer@gmail.com) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D6A362C20; Thu, 12 Sep 2013 22:17:10 +0000 (UTC) Received: by mail-ob0-f173.google.com with SMTP id vb8so424291obc.4 for ; Thu, 12 Sep 2013 15:17:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=ZFD6cPg4r7Pp9kABlDXfu6lffa9UY7NKufZBUfjRPw4=; b=cNoCAMPg7Mn6+U3GC4jCna//BXD+vSml3bZTQjzUjLEcgHLWek5NktDmc/70/NsXYA 5nRD/dF57ETzMd9x+jjmNOQES5eDrEROsFwW4/G+abicpJzYmR0/pWMsr8j3aiifxkWj AoXIBpFkO51UimuUB5ab5XEauPstn9WMILM55jJ7ZXV5MLrTexhbPgTdeLkyBdvRBnXr qQG6cAaimo8c0PERetK0i+AKWCZTehMl3r3YxClY/7Hp7fuzoYe2SNvNODXK1/GP5uhj vF/TKPm36wK7SQqcs1bJ4aQHCekvPbDvIZqC5nqhzstTo5j1P9veUco6hnYEzLbgFOv5 8bBA== X-Received: by 10.182.18.102 with SMTP id v6mr3686987obd.71.1379024229973; Thu, 12 Sep 2013 15:17:09 -0700 (PDT) Received: from [172.22.132.60] ([192.119.231.58]) by mx.google.com with ESMTPSA id j9sm9161914oef.8.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Sep 2013 15:17:08 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: FreeBSD Transient Memory problem? From: Guy Helmer In-Reply-To: Date: Thu, 12 Sep 2013 17:17:07 -0500 Message-Id: <8573B6D6-0285-4167-9800-9DFC249694DA@gmail.com> References: <20130912053559.GF68682@funkthat.com> <979901F9-5F25-4DF1-95A8-32473C55B25F@gmail.com> <52320144.2090807@freebsd.org> To: Jonathon Wright X-Mailer: Apple Mail (2.1508) X-Mailman-Approved-At: Thu, 12 Sep 2013 22:42:57 +0000 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-security@freebsd.org" , John-Mark Gurney , 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:17:11 -0000 On Sep 12, 2013, at 3:33 PM, Jonathon Wright = 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 = wrote: > On Sep 12, 2013, at 2:33 PM, Jonathon Wright = 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 = 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=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 > >>>> > >>>> 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