Date: Fri, 13 Sep 2013 08:23:19 -1000 From: Jonathon Wright <jonathon.s.wright@gmail.com> To: Gary Palmer <gpalmer@freebsd.org> Cc: "freebsd-security@freebsd.org" <freebsd-security@freebsd.org>, John-Mark Gurney <jmg@funkthat.com>, Julian Elischer <julian@freebsd.org> Subject: Re: FreeBSD Transient Memory problem? Message-ID: <CAGX1DMZnk4vBxF-KTO5Zvdu3ZwaA3QVbyB%2BThagWed5i0OWSdg@mail.gmail.com> In-Reply-To: <20130913164718.GC33898@in-addr.com> References: <CAGX1DMbQP=TggYQm-3hra0Od3gjgz5xQ8bEMMrueuhL6kuZMUA@mail.gmail.com> <20130912053559.GF68682@funkthat.com> <979901F9-5F25-4DF1-95A8-32473C55B25F@gmail.com> <52320144.2090807@freebsd.org> <CAGX1DMYAheUAV_eB4Z4R_YaMDx_LzrepEag5KyBC=EOxzhUiMQ@mail.gmail.com> <20130913164718.GC33898@in-addr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Well stated Gary. I need to divulge more information it appears. The reason I'm unable to effectively fight the semantic game, and not pay the auditors, etc. etc. is because the auditors are the DoD. We work for a private company that's contracted out to provide services to the DoD. But we still have to pass their inspections. As you all know, the DoD does not exactly see things in anything but black and white. So yes, my management is freaked out because the DoD auditors (paid for by the DoD btw) are finding issues that we have to resolve to keep the contract going. That's why my hands are tied. I'll give them credit though, they are allowing me to demonstrate FreeBSD's capability in this manner by providing documentation since FreeBSD does not have the cert. Thats the first non-black and white auditor check I've seen in years. We have lots of time and efforts invested in our architecture which is based on FreeBSD and thats why we're fighting to keep it, hence the start of this post. Thanks again for all the insights, I'll keep ya up to date. We have another month or so to work this, so we're still formulating an initial response. JW On Fri, Sep 13, 2013 at 6:47 AM, Gary Palmer <gpalmer@freebsd.org> wrote: > On Thu, Sep 12, 2013 at 09:33:34AM -1000, 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. > > If you search for "niap object reuse" you can find some information about > what they are talking about. I don't think you need to turn on Z malloc > option, it appears to be something else, although I'm not sure what TCB > means on the page I found. > > I also would suggest to management that your auditors haven't actually > defined a problem. They've made it sound like they have. > > > "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" > > No, their statement is wrong. They said they can't validate that it > does, not because they tested and found it doesn't, but because it isn't > on some mysterious list. Therefore the statement that the OS does not > ensure that residual data is scrubbed is incorrect. A more correct > statement is "the OS hasn't been validated to <etc>", not that it *will* > leak data. OK, it's semantics, but it's an important difference as they > claim the OS doesn't ensure data is secure when they know no such thing. > > By playing the semantic game, and by the above incorrect statement, they've > freaked your management out. Personally I wouldn't pay their bill until > they correct their statement and provide an explanation as to why this is a > bad thing, with examples and or references to the standard they claim > to be checking against. > > Regards, > > Gary >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGX1DMZnk4vBxF-KTO5Zvdu3ZwaA3QVbyB%2BThagWed5i0OWSdg>