Splitting atoms in XNU(googleprojectzero.blogspot.com)
googleprojectzero.blogspot.com
Splitting atoms in XNU
https://googleprojectzero.blogspot.com/2019/04/splitting-atoms-in-xnu.html
36 comments
Blows my mind that there’s people who figure this stuff out. Do they just spend their day to day time at work attempting all sorts of variations of this kind of stuff? How often does discovery or research like this lead to a dead end?
They tend to be really smart and motivated people. For example, http://lcamtuf.coredump.cx/gcnc/ is not just a good guide to CNC, it's an amazing guide where you realize he learned half the unwritten rules just by thinking about them. http://lcamtuf.coredump.cx/rstory/ for the robots.
That seems like a good pointer, but what does CNC milling have to do with finding bugs in a virtual memory system?
The learning process. No one is teaching you how to find bugs in VM subsystem.
The author lcamtuf is a well-known security engineer and I was explaining, indirectly, that he's just inherently super-smart and curious and spends a ton of time figuring things out.
> Do they just spend their day to day time at work attempting all sorts of variations of this kind of stuff?
Yep.
> How often does discovery or research like this lead to a dead end?
Orders of magnitude more than the successful paths these days.
Yep.
> How often does discovery or research like this lead to a dead end?
Orders of magnitude more than the successful paths these days.
It's completely amazing to me too. As I understand it, one of the tools that the security research community uses is fuzzing (https://en.wikipedia.org/wiki/Fuzzing). I can at least understand how this sort of technique would help generate some leads.
I'd recommend the Security Now podcast by Steve Gibson if you're interested in this sort of thing. He does a great job explaining many of the exploits out there.
I'd recommend the Security Now podcast by Steve Gibson if you're interested in this sort of thing. He does a great job explaining many of the exploits out there.
Security Now ... woah ... didn't realize GRC was still around. I remember visiting ShieldsUP in the 90s. Site looks the same. More content, but the design has not changed. Those are some old gifs.
Apple pays handsomely for bugs, they have a bug bounty program (1). At some point there are fewer and fewer exploits and the system becomes harder to crack. All companies who care about security should have security bounty programs.
https://motherboard.vice.com/en_us/article/qvapxq/apple-ipho...
https://motherboard.vice.com/en_us/article/qvapxq/apple-ipho...
So long as it’s an iOS bug of course... the situation with macOS is pretty absurd.
Since this is Project Zero, the author has a salary and isn't allowed to collect the rewards.
I'm guessing the salary must be higher than the rewards or they wouldn't do it tho.
I'm guessing the salary must be higher than the rewards or they wouldn't do it tho.
When all software was in C and C++, that was rather common. I'd say there are less people today in the industry that can find out simplest assembler level exploits than it was at the peak of malware scene 15 years ago.
If you leave Ian Beer for even 5 minutes at a bus stop, he'll start poking the internals of the XNU kernel...
Presumably they have a large catalog of exploits that they sit on until they have an interesting exploit chain.
They often need some exploits to get the unencrypted kernel in the first place for analysis. If they were to reveal those exploits, they wouldn't be able to find any more exploits in the future.
Generally true, although the kernel is now unencrypted by default.
They know where to look.
”Quickly dropping a very important lock and retaking it is a common anti-pattern I've observed across the XNU codebase
[…]
This is trying to detect whether another thread acquired and dropped the lock while this thread dropped it then reacquired it. If so, the code checks whether there's still a vm_map_entry covering the current address its trying to copy and then bails out and looks up the entry again.”
I find that disconcerting. Apparently, the writers of this didn’t have a clear model of what locks are needed where, or (worse) they had a model, but knew it didn’t work.
Anybody writing that code should have seen this coming.
[…]
This is trying to detect whether another thread acquired and dropped the lock while this thread dropped it then reacquired it. If so, the code checks whether there's still a vm_map_entry covering the current address its trying to copy and then bails out and looks up the entry again.”
I find that disconcerting. Apparently, the writers of this didn’t have a clear model of what locks are needed where, or (worse) they had a model, but knew it didn’t work.
Anybody writing that code should have seen this coming.
Any sufficiently complex software will at some point require dropping and reacquiring a lock.
The trick is you have to assume everything changed under you when you dropped the lock, and recheck everything
The trick is you have to assume everything changed under you when you dropped the lock, and recheck everything
That first paragraph is a ride and a half.
Props to Project Zero. There's some seriously talented people on than crew.
Props to Project Zero. There's some seriously talented people on than crew.
Indeed, the most impressive part of this is that it's actually half a dozen different exploits carefully chained together to produce the final result. I can't even imagine the amount of perseverance required for each single sub-exploit. Mad props.
[deleted]
I constantly get a kernal panic on multiple machines under heavy load of the sort of trying to interlock destroyed mutex from within, according to the backtrace, com.metakine.handsoff.driver. I'm wondering if it's exploitable.
Is that a third party kernel extension? Sounds like a buggy one if so, and if it’s this <https://www.oneperiodic.com/products/handsoff/> then it might be lessening security instead of increasing it.
Yeap. I wouldn't say lessening unilaterally but with the nuance of changing the attack surface in different areas. IIRC "Hands Off!" is a firewall and an app firewall that can selectively limit disk and network access.
Not sure about the vulnerability of it, but it sounds like an unhandled race-condition.
Great deep dive into iOS use of tagged memory, and a good example that security needs to go all the way down the stack to actually be effective.
That is one contrived exploit.
That TL;DR is super condensed...
Why did they post this on April Fools?
At first I thought this was a convoluted HalfLife reference https://half-life.fandom.com/wiki/Xen
At first I thought this was a convoluted HalfLife reference https://half-life.fandom.com/wiki/Xen
It would be interesting to see how many of these bugs would be possible if an operating system written in Rust would be used.
I would treat any code allocating / deallocating / moving / locking memory by hand instead of using higher level constructs unsafe now that we know that it's possible to automate checking safety of the operations.
I would treat any code allocating / deallocating / moving / locking memory by hand instead of using higher level constructs unsafe now that we know that it's possible to automate checking safety of the operations.
I just noticed that they renamed Project Fi to just Google Fi. When I first saw this post, due to Project in the name I thought it was Google Fi. Good on them for changing the name. Maybe it's a sign that Google will be more consistent in their naming in the future.
Project Fi was graduated to Google Fi around November last year:
https://www.theverge.com/2018/11/28/18115264/google-fi-iphon...
https://www.theverge.com/2018/11/28/18115264/google-fi-iphon...