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.
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.
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.
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.
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.
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.
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.
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.
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.
I'm surprised they're still using a blogspot subdomain . Something like zero.google or projectzero.google would work (with redirects for existing links)
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 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.
”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.
36 comments
[ 4.1 ms ] story [ 78.3 ms ] threadYep.
> How often does discovery or research like this lead to a dead end?
Orders of magnitude more than the successful paths these days.
https://motherboard.vice.com/en_us/article/qvapxq/apple-ipho...
I'm guessing the salary must be higher than the rewards or they wouldn't do it tho.
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.
Props to Project Zero. There's some seriously talented people on than crew.
https://www.theverge.com/2018/11/28/18115264/google-fi-iphon...
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.
The moment I saw article was about a bug in native code I knew there would be a comment like
“I wonder if Rust could have helped here?”
At first I thought this was a convoluted HalfLife reference https://half-life.fandom.com/wiki/Xen
[…]
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.
The trick is you have to assume everything changed under you when you dropped the lock, and recheck everything