On Sep 12, 2013, at 3:33 PM, Jonathon Wright <[email protected]> wrote:
> Thanks for those insights Guy. Makes sense that they are referring to > security boundaries (inter-process related) only. > > 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. 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. > > 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 > > Thanks > > > > On Thu, Sep 12, 2013 at 10:05 AM, Guy Helmer <[email protected]> wrote: > On Sep 12, 2013, at 2:33 PM, Jonathon Wright <[email protected]> > 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 <[email protected]> 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 <[email protected]> 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." > >>>> > >>> > >>> > >> > > _______________________________________________ > > [email protected] mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-security > > To unsubscribe, send any mail to "[email protected]" > > _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"
