FreeBSD transient memory problem?

Hey all,

Our company just had a technical security validation team that gave us a recommendation to move from FreeBSD to different OS to "solve this problem".

Here is the verbiage of what they found:
"Object reuse cannot be verified:
FreeBSD cannot be verified that the operating system ensures transient memory cleansing (object reuse) features are in place. The Validation team has determined this to be a finding. By using this Operating System (OS) which does not ensure that no residual data from a former object exists, a malicious user could gain access to memory and OS objects that contain information. "

How they determined it was not disclosed, and not a fight I can stand on. The higher-ups are looking at me to answer this and assure them FreeBSD is okay, otherwise they are going to move us to another OS. :(

Please help, our shop has way too much time and effort put into our FreeBSD architecture to just move away. Documentation is what they need, something more formal, not just opinion please.

SK
 
scryptkiddy said:
"Object reuse cannot be verified:
FreeBSD cannot be verified that the operating system ensures transient memory cleansing (object reuse) features are in place. The Validation team has determined this to be a finding. By using this Operating System (OS) which does not ensure that no residual data from a former object exists, a malicious user could gain access to memory and OS objects that contain information. "
That quote seems to contradict itself.

Because the problem statement is that the reuse of objects can't be verified. Yet the description talks about not ensuring that no residual data remains in memory.

Still, fact of the matter is that this can apply too all common operating systems out there, unless you're using something which is specifically aimed at providing an high secured environment. Think about it; for starters most modern operating systems (this includes Windows) utilize a form of swap; where memory can be freed by paging out parts which have become somewhat inactive, thus automatically becoming more directly available for malicious use (Windows has had a very dark history regarding this).

In my opinion you don't need documentation and such. You need to ensure that your environment meets the requirements being set. Quite frankly I can't help wonder if you're not better of by switching to OpenBSD instead.

(Edit)

Are you sure that the quote above is a literal quote? What was being audited, in what context (PCI compliancy)? Because if I feed the problem statement as a strict search request to Google or Bing I end up on this forum thread. And there are a lot of discussions about becoming PCI compliant out there, including literal quotes from several compliancy tests.
 
(Added this, see edit reason) I'll post there too @wblock@, thanks for that.

Interesting thought.

We've discussed it here in our team and have no real answer for the higher ups yet who received the report from the team. They did say that the team's finding was based on this standard:

"Enforce the use of approved procedures for clearing, purging, reusing, and releasing system memory, media, output, and devices."

Digging deeper I was able to extract more information. Apparently, FreeBSD is not on an approved list of "protection profiles" of sorts for the security levels the team was looking for. Which is why they had no need to do any testing for the finding. They indicated that FreeBSD had never been "Common Criteria tested for APE, ASE, EAL(1-4)".

I did some research on the Common Criteria stuff, looks like its a methodology of sorts that has been implemented by the ICCC(?). Problem is they only do commercial (like Red Hat Linux) products, not open source, which explains why FreeBSD is not on there (nor OpenBSD most likely).

They are looking for something in the Handbook or other documentation that clearly states that the memory usage is blah blah... you know, whats stated in OP above. So... I might have to post another thread "How to migrate from BSD to Linux"...this sucks. x(

SK
 
Last edited by a moderator:
To put another spin on the matter this is something you can not prove or disprove formally. No matter what kind of guarantees you present about the supposed safety of the object re-use you can not do that for every conceivable program. Otherwise you would have a solution for the so called halting problem that is known to be a non-computable problem:

http://en.wikipedia.org/wiki/Halting_problem

In simple terms, there's not a single operating system out there that is provably safe in this regard.
 
"Enforce the use of approved procedures for clearing, purging, reusing, and releasing system memory, media, output, and devices."

When I did this kind of stuff this was all physical. Generally any system with a hard drive be it a computer or office copier would have its persistent memory removed and destroyed if it had every processed sensitive or personal/financial information. This meant nothing as far as the operating system is concerned and I would be interested in seeing what they are reading that makes them think that.
 
kpa said:
To put another spin on the matter this is something you can not prove or disprove formally...

Yeah, I'm arguing that now, but to no avail... They do have RHEL Server 6 listed as being "approved for the Common Criteria" and gave us the lab that tested it, so I wrote it down:

Booz Allen Hamilton Common Criteria Testing Laboratory
900 Elkridge Landing Road
Suite 100
Linthicum, MD 21090

Come to find out the lab tests for FreeBSD 8.x (or any OS) is $25K. This is probably why FreeBSD hasn't been tested, as Open Source, its not any one named company that would front this bill, its a community of users and developers.

Kind of odd how this all happened, we get inspected once a year at best, but this is a first I've heard of the memory testing. As you stated, I can't prove it, I'd have to pay a lab to do it.

Appreciate the discussion guys, but it seems this is a battle that can't be won.

SK
 
Has anyone mentioned to your PHBs what their audit company's disability to understand fundamental computational problems is costing them?

How much did they pay for the audit? I'm guessing by the name of the lab that $25K is what they charge for spending 10 minutes to look up the operating system name in their list of approved systems. A real audit of the ca. 10 million lines of FreeBSD code is nowhere near that price.
 
scryptkiddy said:
Come to find out the lab tests for FreeBSD 8.x (or any OS) is $25K. This is probably why FreeBSD hasn't been tested, as Open Source, its not any one named company that would front this bill, its a community of users and developers.
One important aspect: being open source has little to do with all this. Keep in mind that even Red Hat Enterprise Linux ('RHEL') is an open source product, though one with a commercial take. The open source aspect is why a project such as CentOS can exist.

Unfortunately I think your chances of convincing the upper bras are slim. Because in general the motivation for such audits isn't so much to determine the overall security but to make sure that the responsibility ("certification") has been covered.
 
ErikCederstrand said:
I'm guessing by the name of the lab that $25K is what they charge for spending 10 minutes to look up the operating system name in their list of approved systems. A real audit of the ca. 10 million lines of FreeBSD code is nowhere near that price.

I spoke with the lab, it takes around 4-6 months, and they sent me the link to the site that explains the process. Pretty intense, in depth and thorough. Personnally, I think its a waste of time, because it is a fundamental problem with any OS.


ShelLuser said:
One important aspect: being open source has little to do with all this. Keep in mind that even Red Hat Enterprise Linux ('RHEL') is an open source product, though one with a commercial take. The open source aspect is why a project such as CentOS can exist.

Unfortunately I think your chances of convincing the upper bras are slim. Because in general the motivation for such audits isn't so much to determine the overall security but to make sure that the responsibility ("certification") has been covered.

First part, true, but RHEL did pay for the lab test, they have a Common Criteria certification. I don't think FreeBSD Foundation will do that.

Second part, yup, perfectly stated. They need someone to take the responsibility (a vendor) if a security incident ever occurs due to the OS certification level.

Good discussion all, thanks for the thoughts.

SK
 
You could throw the book on them.

Prior to that, use a text marker to highlight the chapters about memory management, the page daemon and when memory pages are cleared. In FreeBSD, you can only get memory assigned to you which is zeroed out by the OS.

Holes can only be poked into this by side channels like shared memory usage - this kind of holes can come from sloppy GL drivers, for example. This is one reason I so strongly dislike the trend of "pushing it all to the kernel" for graphics, sound and whatnot.
 
Interesting, I didn't even know there was a book on the Design and Implementation of FreeBSD. Very cool, I'll see if I can get access to one online somewhere since we are on a time limit.
 
Hey @Crivens, do you happen to have the page that references that in the book (or copy paste that part in here as a reply). I've been reading through chapter of Memory Management, and I don't see it.
 
Last edited by a moderator:
Sounds to me more like the analyst doesn't know whether FreeBSD clears objects after they were removed from memory or not, but re-worded it to make it sound like he knows what he's talking about, rather than write words to the effect of "I don't know if FreeBSD is safe".


edit:
Show the higher ups the list of published security advisories for RHEL6 vs. FreeBSD.
 
scryptkiddy said:
Hey @Crivens, do you happen to have the page that references that in the book (or copy paste that part in here as a reply). I've been reading through chapter of Memory Management, and I don't see it.

I have the 2005 print version at hand, and there is at page 188/189 the definition of the different memory types. Of interest is #5, the free memory. This states that the free memory list is seperated in two parts, zeroed pages and not zeroed pages. The page daemon takes pages from the dirty end of the list, zeroes them, and then puts them on the other end of the list where zeroed pages are. When a new page is needed to serve a pagefault, the type of request determinates from which end the page is taken: IO drivers which will fill it with new data can use dirty pages, page faults from anonymous memory (stack, heap area, ...) will come from the zeroed end. This chapter is a good entry point into the matter.

In case this is not enough, you might kindly ask the guys for a copy of the linux operating system design handbook. And please let us know if that exists and where it can be found ;)
 
Last edited by a moderator:
Crivens said:
In case this is not enough, you might kindly ask the guys for a copy of the linux operating system design handbook. And please let us know if that exists and where it can be found ;)

* Linux is not an OS!
* Here is a link to where you can get all the information, tools, and HOW TO build your own custom Linux system (kernel+OS).
 
youngunix said:
* Linux is not an OS!
* Here is a link to where you can get all the info, tools, and HOW TO build your own custom Linux system (kernel+OS).

No, Linux is not an OS. And we had tons of threads trying to determinate what it is ;)

The link you provided is basically the equivalent of "make buildworld", or did I miss something? The book I mentioned, and referenced to, contains the kernel details and descriptions of the inner workings of the FreeBSD kernel. The How Things Are Done and the Why Is It Done Like This parts of the kernel. That is something that I would like to see for Linux, at roughly the same accuracy and detail. Also for Windows, or any other OS/Kernel/... where someone wants to do an audit like the OP is dealing with.
 
throAU said:
Show the higher ups the list of published security advisories for RHEL6 vs. FreeBSD.

Made me chuckle. Comparing a summary of RHEL6 CVEs to FreeBSD 8.3 CVEs shows both with a single memory corruption vulnerability. While the FreeBSD entry is scored higher (potential arbitrary code execution) the RHEL one is more pertinent to the poster's issue (potential memory leak). And RHEL6 has a significant number of additional... features. To be fair, this could be ascertainment bias, particularly if RHEL6 has been subjected to more aggressive auditing.
 
Back
Top