FreeBSD Transient Memory problem?

Gary Palmer gpalmer at freebsd.org
Fri Sep 13 16:47:24 UTC 2013


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


More information about the freebsd-security mailing list