5 ms·

They probably hunt exploits like that, but what is quite likely is that they have access to stolen Apple source code and scour it for type overruns like the one

They probably hunt exploits like that, but what is quite likely is that they have access to stolen Apple source code and scour it for type overruns like the one in CoreGraphics that is the cause of this exploit. I would estimate that the majority of exploits are the result of source code theft, leaks of potential vulnerabilities from people who have access to the source code and social engineering. There isn't anything particularly special about a "Mossad" trained or "NSA" trained hacker. They are engineers like many of us and prefer the path of least resistance. Trying to brute force buffer overruns without having source code access is tedious. Why go to all the effort to black box exploits when you can take advantage of source code analysis. I mentioned in another post about why people would leak to the press, when you most likely will get caught and fired. Leakers of a different caliber will leak source code to governments and companies like NSO and have much less likelihood of being caught and much higher remuneration.

saagarjha 5y ago
> I would estimate that the majority of exploits are the result of source code theft, leaks of potential vulnerabilities from people who have access to the source code and social engineering. No. Some Apple source code has publicly leaked (iBoot) but stealing this kind of stuff is bound to leak. And reversing binaries for vulnerabilities is not that much harder.
marcan_42 5y ago
You estimate wrong. I've been in infosec for over a decade. We look at binaries. It's not that hard. In fact, it's often easier, since type conversion errors are often a lot more apparent in a disassembly, where you can see exactly what operations are being performed without having to know exactly what the language rules around signedness and integer promotion are, and without having to follow through complicated type hierarchies. Similarly, a good optimizer will strip away layers of software abstraction and make what's actually happening more evident. There is value in source audits, but you're wrong that exploits come out of stolen source. That's exceedingly rare, and usually quickly publicly leaked when it happens.
- ShroudedNight 5y ago
  > Similarly, a good optimizer will strip away layers of software abstraction and make what's actually happening more evident. I can attest to this, I've found it's frequently far more satisfying to debug at -O3 than -O0. At O3, the disassembly really lays bare the invalid assumptions that were relied upon.
- diskzero 5y ago
  I respect your expertise and agree that good tools can help find potential vulnerabilities. You aren't the first person to say that exploits created as a result from source code theft are rare and the theft is quickly publicly leaked when it happens. Why do you think this? I would think that unethical players like NSO Group would have even more motivation to ensure the use of stolen source code is never revealed.
  - marcan_42 5y ago
    Because I've been doing this for years and I know how we find exploits; we don't need source. Why would NSO need it? NSO isn't an "unethical" player, they are "ethical" within their own twisted ethics (that most of us don't agree with). They aren't a spy organization outside the law, they're a company building tools for (supposedly) law enforcement. Being caught doing something blatantly illegal like using stolen source code would be the end of them. They can't afford that risk. They have absolutely no need to use source code. There are zillions of binary-only techniques for finding exploitable bugs (e.g. fuzzing). Source code just isn't nearly as useful as you think it is. If you want a practical example: just a few weeks ago I got ahold of a peculiar, wholly undocumented embedded device (can't even find teardowns on the Internet, no public firmware downloads, etc) and within one day I had a remote root exploit working - this wasn't using an existing CVE in a library, this was a bespoke bug in this device's firmware, and the exploitation involved reverse engineering two authentication token algorithms and a custom binary communications protocol. No source code. Obviously this isn't iOS, which is quite bit more hardened, but that should give you an idea of just how easy it is to find exploitable bugs with just something like Ghidra, if you know what you're doing (I was: I was looking specifically for a kind of bug likely to exist, to narrow down the possibilities of where it might be present, and eventually found a suspicious point of attack surface that indeed turned out to be vulnerable; then it was just a matter of reverse engineering enough of the protocol and token requirements of that code to be able to actually trigger it remotely). I was actually kind of annoyed it took as long as a couple hours to find it (once I had a decent understanding of the rest of the system); I was expecting even less, but it turned out they did a better job than I expected avoiding some of the classic mistakes - but not a good enough one :).

saagarjha 5y ago

> I would estimate that the majority of exploits are the result of source code theft, leaks of potential vulnerabilities from people who have access to the source code and social engineering. No. Some Apple source code has publicly leaked (iBoot) but stealing this kind of stuff is bound to leak. And reversing binaries for vulnerabilities is not that much harder.

marcan_42 5y ago

You estimate wrong. I've been in infosec for over a decade. We look at binaries. It's not that hard. In fact, it's often easier, since type conversion errors are often a lot more apparent in a disassembly, where you can see exactly what operations are being performed without having to know exactly what the language rules around signedness and integer promotion are, and without having to follow through complicated type hierarchies. Similarly, a good optimizer will strip away layers of software abstraction and make what's actually happening more evident. There is value in source audits, but you're wrong that exploits come out of stolen source. That's exceedingly rare, and usually quickly publicly leaked when it happens.

ShroudedNight 5y ago
> Similarly, a good optimizer will strip away layers of software abstraction and make what's actually happening more evident. I can attest to this, I've found it's frequently far more satisfying to debug at -O3 than -O0. At O3, the disassembly really lays bare the invalid assumptions that were relied upon.
diskzero 5y ago
I respect your expertise and agree that good tools can help find potential vulnerabilities. You aren't the first person to say that exploits created as a result from source code theft are rare and the theft is quickly publicly leaked when it happens. Why do you think this? I would think that unethical players like NSO Group would have even more motivation to ensure the use of stolen source code is never revealed.
- marcan_42 5y ago
  Because I've been doing this for years and I know how we find exploits; we don't need source. Why would NSO need it? NSO isn't an "unethical" player, they are "ethical" within their own twisted ethics (that most of us don't agree with). They aren't a spy organization outside the law, they're a company building tools for (supposedly) law enforcement. Being caught doing something blatantly illegal like using stolen source code would be the end of them. They can't afford that risk. They have absolutely no need to use source code. There are zillions of binary-only techniques for finding exploitable bugs (e.g. fuzzing). Source code just isn't nearly as useful as you think it is. If you want a practical example: just a few weeks ago I got ahold of a peculiar, wholly undocumented embedded device (can't even find teardowns on the Internet, no public firmware downloads, etc) and within one day I had a remote root exploit working - this wasn't using an existing CVE in a library, this was a bespoke bug in this device's firmware, and the exploitation involved reverse engineering two authentication token algorithms and a custom binary communications protocol. No source code. Obviously this isn't iOS, which is quite bit more hardened, but that should give you an idea of just how easy it is to find exploitable bugs with just something like Ghidra, if you know what you're doing (I was: I was looking specifically for a kind of bug likely to exist, to narrow down the possibilities of where it might be present, and eventually found a suspicious point of attack surface that indeed turned out to be vulnerable; then it was just a matter of reverse engineering enough of the protocol and token requirements of that code to be able to actually trigger it remotely). I was actually kind of annoyed it took as long as a couple hours to find it (once I had a decent understanding of the rest of the system); I was expecting even less, but it turned out they did a better job than I expected avoiding some of the classic mistakes - but not a good enough one :).