No transcript (yet?) sadly, but this is a good high level overview. Looks like excellent and valuable work:
> ... we conducted a large-scale audit of FreeBSD kernel code paths accessible from within a jail. We systematically examined privileged operations, capabilities, and interfaces that a jailed process can still reach, hunting for memory safety issues, race conditions, and logic flaws. The result: roughly 50 distinct issues uncovered across multiple kernel subsystems, ranging from buffer overflows and information leaks to unbounded allocations and reference counting errors—many of which could crash the system or provide vectors for privilege escalation beyond the jail.
> We’ve developed proof-of-concept exploits and tools to demonstrate some of these vulnerabilities in action. We’ve responsibly disclosed our findings to the FreeBSD security team and are collaborating with them on fixes. Our goal isn’t to break FreeBSD, but to highlight the systemic difficulty of maintaining strict isolation in a large, mature codebase.
As long as there is no real liability for getting hacked and as long as companies don't want to pay for proper software development. And note that FreeBSD is one of the harder nuts in this sense. Any codebase beyond a few hundred lines will have one or more of these if you look hard and long enough. But: these 50 are now squashed and that's a nice Christmas gift.
If the companies that use this stuff commercially would contribute back 1% of the value they derive from using open source this could be bullet proof.
This should be mentioned in the talk, if I recall correctly. We’ve assumed “compromised jail” as a starting point to highlight the discrepancy between “root in jail” and “root on host” that has appeared with the invention of jails. And how some subsystems that were made “jail-aware” over the years, don’t take this distinction into account enough, unfortunately. Thanks for the feedback, much appreciated!
I wouldn't call it devastating just by dint of the issue count:
- Most issues do not become exploitable vulnerabilities.
- The prereq for these code paths is root in the jail, so an ordinary user would first require a privilege escalation bug to get root, which is where most security review is traditionally focused (these paths should be closed already).
I haven't seen whether the POCs can actually get to an escape, but this is great work and FreeBSD is better for it.
> 50 distinct issues? That's devastating. If these researchers found 50 issues, we all know there's more that 50 issues in the codebase.
That's rough but for a systematic search of a large system it seems reasonable. Theres a good chance that these 50 represent most the "easy" vulnerabilities if the researchers did a thorough job. In a way it seems more likely than if they found a smaller number.
That’s a fair take, yes. Ilja said that the entire subsystem for Linux on FreeBSD is also jail aware, but he didn’t even begin to look into that.
His process is briefly touched on in the talk. If I understood correctly he compiled a list of the most common jail privilege flags that exist and then searched the FreeBSD source code for those, investigating the code in those places.
No automated tooling was used, this was just done by reading the source code. Which Ilja has been doing as “light bed time reading” :p for as long as I’ve known him (25+ years).
No transcript (yet?) sadly, but this is a good high level overview. Looks like excellent and valuable work:
> ... we conducted a large-scale audit of FreeBSD kernel code paths accessible from within a jail. We systematically examined privileged operations, capabilities, and interfaces that a jailed process can still reach, hunting for memory safety issues, race conditions, and logic flaws. The result: roughly 50 distinct issues uncovered across multiple kernel subsystems, ranging from buffer overflows and information leaks to unbounded allocations and reference counting errors—many of which could crash the system or provide vectors for privilege escalation beyond the jail.
> We’ve developed proof-of-concept exploits and tools to demonstrate some of these vulnerabilities in action. We’ve responsibly disclosed our findings to the FreeBSD security team and are collaborating with them on fixes. Our goal isn’t to break FreeBSD, but to highlight the systemic difficulty of maintaining strict isolation in a large, mature codebase.
> The result: roughly 50 distinct issues uncovered across multiple kernel subsystems
> Our goal isn’t to break FreeBSD, but to highlight the systemic difficulty of maintaining strict isolation in a large, mature codebase.
50 distinct issues? That's devastating. If these researchers found 50 issues, we all know there's more that 50 issues in the codebase.
I really think we need to start seriously considering using SeL4 as a base for our operating systems. How long can we keep building on top of sand?
As long as there is no real liability for getting hacked and as long as companies don't want to pay for proper software development. And note that FreeBSD is one of the harder nuts in this sense. Any codebase beyond a few hundred lines will have one or more of these if you look hard and long enough. But: these 50 are now squashed and that's a nice Christmas gift.
If the companies that use this stuff commercially would contribute back 1% of the value they derive from using open source this could be bullet proof.
Looks like great work, worth mentioning it starts with assumption of being root in jail.
This should be mentioned in the talk, if I recall correctly. We’ve assumed “compromised jail” as a starting point to highlight the discrepancy between “root in jail” and “root on host” that has appeared with the invention of jails. And how some subsystems that were made “jail-aware” over the years, don’t take this distinction into account enough, unfortunately. Thanks for the feedback, much appreciated!
I wouldn't call it devastating just by dint of the issue count:
I haven't seen whether the POCs can actually get to an escape, but this is great work and FreeBSD is better for it.https://drive.google.com/file/d/1M7R8m5zniNsnTu06UdE7EzIqUCA...
Beautiful stuff. Thanks!
> 50 distinct issues? That's devastating. If these researchers found 50 issues, we all know there's more that 50 issues in the codebase.
That's rough but for a systematic search of a large system it seems reasonable. Theres a good chance that these 50 represent most the "easy" vulnerabilities if the researchers did a thorough job. In a way it seems more likely than if they found a smaller number.
That’s a fair take, yes. Ilja said that the entire subsystem for Linux on FreeBSD is also jail aware, but he didn’t even begin to look into that.
His process is briefly touched on in the talk. If I understood correctly he compiled a list of the most common jail privilege flags that exist and then searched the FreeBSD source code for those, investigating the code in those places. No automated tooling was used, this was just done by reading the source code. Which Ilja has been doing as “light bed time reading” :p for as long as I’ve known him (25+ years).
how does someone gets so good to be able to find so many issues by just reading the code? practise isnt all it takes i assume
Great news.
Someone just did a great work on security audit and made FreeBSD Jails a lot more secure.
This is what security audits are for.
Thanks! And thank you for your valuable news newsletter.
Great talk!
Thanks! It was fun to work on, these past three months.