FreeBSD Transient Memory problem?
Julian Elischer
julian at freebsd.org
Fri Sep 13 04:21:12 UTC 2013
On 9/13/13 4:33 AM, Jonathon Wright wrote:
> Thanks for those insights Guy. Makes sense that they are referring
> to security boundaries (inter-process related) only.
what's the name of the "security" company?
maybe we can publicly lambast them as idiots on slashdot.
> 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?
> 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?
> Do you have a link to nCircle or site (my GoogleFu is not very
> strong, I only got tripwire hits)
> Thanks
>
>
> On Thu, Sep 12, 2013 at 10:05 AM, Guy Helmer <guy.helmer at gmail.com
> <mailto:guy.helmer at gmail.com>> wrote:
>
> On Sep 12, 2013, at 2:33 PM, Jonathon Wright
> <jonathon.s.wright at gmail.com
> <mailto:jonathon.s.wright at gmail.com>> 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
> <julian at freebsd.org <mailto:julian at 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 at funkthat.com <mailto:jmg at 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=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%**
> <http://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
> <tel:%2B1%20415%20225%205579>
> >>>>
> >>>> "All that I will do, has been done, All that I have,
> has not."
> >>>>
> >>>
> >>>
> >>
> > _______________________________________________
> > freebsd-security at freebsd.org
> <mailto:freebsd-security at freebsd.org> mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-security
> > To unsubscribe, send any mail to
> "freebsd-security-unsubscribe at freebsd.org
> <mailto:freebsd-security-unsubscribe at freebsd.org>"
>
>
More information about the freebsd-security
mailing list