From owner-freebsd-security@FreeBSD.ORG Thu Sep 12 20:05:43 2013 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 23C23778; Thu, 12 Sep 2013 20:05:43 +0000 (UTC) (envelope-from guy.helmer@gmail.com) Received: from mail-oa0-x234.google.com (mail-oa0-x234.google.com [IPv6:2607:f8b0:4003:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D18EA2399; Thu, 12 Sep 2013 20:05:42 +0000 (UTC) Received: by mail-oa0-f52.google.com with SMTP id f4so317431oah.39 for ; Thu, 12 Sep 2013 13:05:42 -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 :content-transfer-encoding:message-id:references:to; bh=xvSzGh8lGcWeYQzbVBtno4A9EbkXwCLbwLvcsegyThM=; b=x8JYMh1sWVm6RyXrRy8fGNww2df8QC2L3Bx1oarYm+hQHB1Uf2w4TbGzDkKs7d9IRs dYO93sB5BMxAS+ZwpFxmgCcPjRhPgWLE5bjUvs7m0bQJHBJq6Ys3MCOV6wxOoOxYufVm MoK2Se2j5NCop/gD7DoNRnqySgnSub+77CwXbFJ3/QzeD0vrZNpjX6AzL8hLbVrHeGja pZVC/YkqVoaBON/jJBpk0Iy4fXXrQco9uU44599YYrTKLHWV82p9ikAgBW7z1KXccesE FgROCFYekwgE5ymSF5oBaqdHywesRANyaTNneSSc8XtlpxW1fewmzRO6ry3TvLTvt0Gx FKng== X-Received: by 10.182.22.226 with SMTP id h2mr8593488obf.8.1379016342190; Thu, 12 Sep 2013 13:05:42 -0700 (PDT) Received: from [172.22.132.60] ([192.119.231.58]) by mx.google.com with ESMTPSA id d3sm8258513oek.5.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Sep 2013 13:05:41 -0700 (PDT) Content-Type: text/plain; charset=us-ascii 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 15:05:39 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: 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 21:36:44 +0000 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 20:05:43 -0000 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: >=20 > ---BEGIN >=20 > *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. >=20 > *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. >=20 > *Recommended Countermeasure(s):* Transition servers to an NIAP = approved OS. > Decommission the FreeBSD servers. > ---END >=20 > 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. >=20 > 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: >=20 >> On 9/13/13 1:49 AM, My Email wrote: >>=20 >>> My apologies, I have been replying too all, I hope that is the = correct >>> method. >>>=20 >>> 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! >>>=20 >>=20 >> 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. >>=20 >> But for all we know they are talking about people stealing punch = cards and >> photographing them.. >>=20 >> JW >>>=20 >>> On Sep 11, 2013, at 7:35 PM, John-Mark Gurney = wrote: >>>=20 >>> Jonathon Wright wrote this message on Wed, Sep 11, 2013 at 14:15 = -1000: >>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>> 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... >>>>=20 >>>> 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'. >>>>>=20 >>>>> The post has all the details. Let me know I need to repost in this = as >>>>> well. >>>>>=20 >>>> 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. >>>>=20 >>>> Link: >>>> = http://www.**commoncriteriaportal.org:80/**files/epfiles/nCircle%20CR%** >>>> = 20v1.0.pdf >>>>=20 >>>> It is possible someone else has received certification on a newer >>>> version, >>>> but I'm not aware of any at this time... >>>>=20 >>>> -- >>>> John-Mark Gurney Voice: +1 415 225 5579 >>>>=20 >>>> "All that I will do, has been done, All that I have, has not." >>>>=20 >>>=20 >>>=20 >>=20 > _______________________________________________ > 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"