Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Splitting atoms in XNU

googleprojectzero.blogspot.com

Post reply on HN
Print view View original

11–20 of 37 posts

Re: Splitting atoms in XNU

#11

Post by hanklazard »

eljimmy wrote: post #3

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?

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.

Re: Splitting atoms in XNU

#12

Post by dekhn »

eljimmy wrote: post #3

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.

Re: Splitting atoms in XNU

#15

Post by giobox »

onemoresoop wrote: post #6
eljimmy wrote: post #3

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?

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...

So long as it’s an iOS bug of course... the situation with macOS is pretty absurd.

Re: Splitting atoms in XNU

#16

Post by jmeyer2k »

eljimmy wrote: post #3

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 know where to look.

Re: Splitting atoms in XNU

#17

Post by ehsankia »

benatkin wrote: post #7

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...

Re: Splitting atoms in XNU

#18

Post by the_fonz »

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.

Re: Splitting atoms in XNU

#19

Post by [deleted] »

adtac wrote: post #9
Sendotsh wrote: post #5

That first paragraph is a ride and a half. 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]

Re: Splitting atoms in XNU

#20

Post by Someone »

”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.

Post reply on HN