Well it's ironic
It's ironic that MoKB have replied to my post about dmg kernel panics by accusing me of not:
reading, checking and…[being] willing to say something that doesn't make sense at all.
They also continue to imply that dmg crashes really are a new discovery. Apparently it’s not enough that I'm a disk utility developer and therefore stand really quite a considerable chance of having seen one. No, it seems that it only happened if I announced it publicly, which I didn’t.
In fact, I reported such a bug to Apple so long ago that it’s now no longer listed in the “My Originated Problems” page on their Bug Reporter. I think I even sent them a dmg file that triggered a kernel panic when it opened, though it’s possible that I just documented the bug in question. The particular bug that I reported was certainly fixed, I know that much.
I also quite enjoy the way that they quote my remark about crashes not necessarily being (or implying the existence of) exploits and use it to imply that I’m some kind of Mac zealot. What they don’t say is that I mentioned that this criticism wasn’t operating system specific. I’m just as unhappy about similar leaps of faith (“Oh, it crashed… well that must be an exploit then!”) on the Windows side.
They then go on to say that “the definition of a 'crash' in kernel-land has quite a few possible meanings”. Ignoring the ungrammatical nature of that sentence, they proceed to conflate types of crash with causes of crashes, then fail to define the term “exploit” in any kind of meaningful way.
But let’s be clear, and let’s define “crash” and “exploit” (something MoKB’s post said it was going to do, then didn’t):
- crash
- …to break down or cause (a computer system or program) to break down completely…
- exploit
- vt to gain control of a computer system or program (usually without authorisation) by taking advantage of a flaw in the design of that system or program. — n a tool or technique for gaining control of a computer system or program.
The former definition comes from The Chambers Dictionary. The latter is my own. I haven’t included all the other meanings of the two words, since they aren’t in dispute here. It should be quite clear from the definitions that crashes and exploits are quite distinct things, contrary to what Brian Krebs’ article implies.
Now, it is true that some crashes are indicative of an exploitable bug, and that still others can be misused as part of a deliberate denial of service attack. But a crash is not an exploit. It doesn’t even mean that an exploit is possible! Interestingly, despite disputing this fact when I originally mentioned it, MoKB go on to state it themselves, saying that
Basically exploiting a bug a [sic] in kernel-land requires some conditions to be met:
and then listing a few such conditions (there are more that they don’t mention).
Anyway, MoKB people, please understand that I have a lot of experience with low-level issues. You aren’t going to steamroller your way through me by claiming that I’m just some random Mac blogger (which isn’t true) or that I “don’t understand”. I do understand; I used to work as an embedded systems developer and even before that I was patching bugs in software I owned, breaking into computer games so I could cheat, re-writing bits of my machine’s operating system so they worked better, etc… These days, I write disk utilities, though I still tinker with other things.
Trying to mischaracterise me as someone who “doesn’t know what they’re talking about” because I happen not to agree with you is just a very good way to make yourselves look foolish. But go right ahead, if you’re determined.
Do you have any other point to make besides "crashes aren't exploits"? Because security people, by and large, have learned the hard way that that's the wrong way to think; the history of memory corruption vulnerabilities since 1995 is of continuously weaponizing problems that weren't believed exploitable before that.
Who are you trying to convince? It sounds like you're writing for the Mac audience, not the security audience, so why even bother talking about "low-level details"?