4 ms·
When you take money for writing and maintaining an OS you have to be competent to avoid fundamental design issues like this when you're going to have a bunch of
by blinkingled 10y ago
When you take money for writing and maintaining an OS you have to be competent to avoid fundamental design issues like this when you're going to have a bunch of downstream users of the code!
Read the TLDR - exploitation of dangling pointers aside you can't write code and/or design APIs that does or makes it easy to do what the TLDR says - hold or use a task struct pointer and expect the euid of that task to stay the same.
Many many places in the kernel do this and there are a great many very exploitable bugs as a result.
Ian Beer certainly is talented but that doesn't excuse Apple being so sloppy!
- tptacek 10y agoAha! I think I understand what has you confused. You seem to think that the TLDR describes some basic rule of XNU programming that people were already aware of and expected to follow. No. Ian Beer invented that rule. In this post. That's why the bug is such a big deal; it's why we call it a "new bug class". It's also why it's the TLDR of the post.
- blinkingled 10y agoWow straight up conclusion - I had it confused, right! It's not a, pardon me for the expression, fucking XNU specific programming rule - it is a general rule that was invented long before Ian got to it! You don't hold a reference counted pointer and operate on it without taking a :gasp: reference first - having that shit in your sample code is just, well extra shitty! Also, separately from the dangling pointer issue, the first sentence of the post is literally - This post discusses a design issue at the core of the XNU kernel!
- tptacek 10y agoYou are describing only the first big in this document. There are four. The timeline we're commenting on is for the last 3, which are not UAFs.