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.hel...@gmail.com
<mailto:guy.hel...@gmail.com>> wrote:
On Sep 12, 2013, at 2:33 PM, Jonathon Wright
<jonathon.s.wri...@gmail.com
<mailto:jonathon.s.wri...@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
<jul...@freebsd.org <mailto:jul...@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
<j...@funkthat.com <mailto:j...@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@freebsd.org
<mailto:freebsd-security@freebsd.org> mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to
"freebsd-security-unsubscr...@freebsd.org
<mailto:freebsd-security-unsubscr...@freebsd.org>"
_______________________________________________
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
