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

Task_t considered harmful

googleprojectzero.blogspot.com

Post reply on HN
Print view View original

51–60 of 89 posts

Re: Task_t considered harmful

#51

Post by pcwalton »

tptacek wrote: post #47
wyager wrote: post #38

Earlier quoted context omitted.

Apple needs to take a bit of those tens of billions of dollars they have sitting around and spend it on starting from scratch with something that's not horrifically crufty. The quality of their software is lagging so far behind the quality of their hardware right now. Realistically, I think we may just be at the point where operating systems and all the stuff the companies put on top of them are too complicated to ke…

So far as the current state of the art in computer engineering goes, we don't know how to completely rewrite a system as complicated as XNU without creating fresh batches of implementation errors. So this is a little like suggesting Apple use its hundreds of billions of dollars to build an iPhone battery that only needs to be recharged once a month. We may someday get an XNU rewrite, but probably not until software e…

> We may someday get an XNU rewrite, but probably not until software engineering produces a new approach to building complex systems reliably that works at the scale (here: number of developers and shipping schedule) Apple needs.

It's conceivable to perform a gradual transition away, though. They could demote Mach to a fast IPC system that just augments BSD, similar to the way the kdbus/bus1 proposal for Linux does. That would be difficult and a long-term project, but it would fix the underlying issue in a way that mostly retains userspace compatibility. Driver compatibility would be more difficult, of course…

Re: Task_t considered harmful

#52

Post by tptacek »

pcwalton wrote: post #51
tptacek wrote: post #47

Earlier quoted context omitted.

So far as the current state of the art in computer engineering goes, we don't know how to completely rewrite a system as complicated as XNU without creating fresh batches of implementation errors. So this is a little like suggesting Apple use its hundreds of billions of dollars to build an iPhone battery that only needs to be recharged once a month. We may someday get an XNU rewrite, but probably not until software e…

> We may someday get an XNU rewrite, but probably not until software engineering produces a new approach to building complex systems reliably that works at the scale (here: number of developers and shipping schedule) Apple needs. It's conceivable to perform a gradual transition away, though. They could demote Mach to a fast IPC system that just augments BSD, similar to the way the kdbus/bus1 proposal for Linux does.…

That's true, but if you undertake a difficult and long-term project, you want the outcome to be decisive. Mach is ugly and a nest of bugs, but kernels implemented in C/C++ are bug magnets with several orders of magnitude more force.

My prediction is that we don't ever see an XNU refactor/ redesign/ rewrite so long as C/C++ is the kernel implementation language.

Re: Task_t considered harmful

#53

Post by pcwalton »

tptacek wrote: post #52
pcwalton wrote: post #51

Earlier quoted context omitted.

> We may someday get an XNU rewrite, but probably not until software engineering produces a new approach to building complex systems reliably that works at the scale (here: number of developers and shipping schedule) Apple needs. It's conceivable to perform a gradual transition away, though. They could demote Mach to a fast IPC system that just augments BSD, similar to the way the kdbus/bus1 proposal for Linux does.…

That's true, but if you undertake a difficult and long-term project, you want the outcome to be decisive. Mach is ugly and a nest of bugs, but kernels implemented in C/C++ are bug magnets with several orders of magnitude more force. My prediction is that we don't ever see an XNU refactor/ redesign/ rewrite so long as C/C++ is the kernel implementation language.

No argument there. :)

Re: Task_t considered harmful

#54

Post by wyager »

tptacek wrote: post #47
wyager wrote: post #38

Earlier quoted context omitted.

Apple needs to take a bit of those tens of billions of dollars they have sitting around and spend it on starting from scratch with something that's not horrifically crufty. The quality of their software is lagging so far behind the quality of their hardware right now. Realistically, I think we may just be at the point where operating systems and all the stuff the companies put on top of them are too complicated to ke…

So far as the current state of the art in computer engineering goes, we don't know how to completely rewrite a system as complicated as XNU without creating fresh batches of implementation errors. So this is a little like suggesting Apple use its hundreds of billions of dollars to build an iPhone battery that only needs to be recharged once a month. We may someday get an XNU rewrite, but probably not until software e…

SeL4 is an indicator of things to come. We can build complicated OSs with extreme reliability; the up-front cost is just higher than most companies are willing to spend right now, because customers don't yet realize that it's technically possible to avoid the huge costs associated with software failure in exchange for slightly higher amortized software costs.

Re: Task_t considered harmful

#55

Post by blinkingled »

hueving wrote: post #49
blinkingled wrote: post #12

Earlier quoted context omitted.

Yeah - the failed mitigations followed by a "long term" fix was interesting as well. Apple literally had to change execve() this late in the OS's development cycle to allocate new task and thread structs(that's two extra allocations and copies in hot path!) to fix it for good. That this design problem lingered around for so long doesn't look good for Apple - it's one thing for a use after free bug in obscure piece of…

>(that's two extra allocations and copies in hot path!) I've never really thought of process spawning as a hot-path (in the hundreds+ of calls per second sense). What software so heavily relies on spawning so many processes so quickly that the overhead of malloc would be noticeable?

On UNIX systems fork+execve is a very commonly used code path - build a piece of software using make for example and the compiler process is forked/exec'ed lot of times, web servers like Apache used multiprocess model for long time etc. Yeah you could decide to not care about fork+exec* performance but what I am familiar with (Linux land) a lot of optimizations go into making fork/exec faster.

Also my bigger point though was not that it was in hot code path (although I would prefer to not be in a position where I need to change execve to add two allocs and copies if I can avoid it) - it was that they had to change execve() this late in the OS's development cycle to fix this long standing bug - typically you get to a point where you don't really need to touch core OS code and when you do you risk adding new issues to a central piece of code.

Re: Task_t considered harmful

#56

Post by 0x0 »

gulpahum wrote: post #37
drinchev wrote: post #8

I'm still with 10.11. I don't plan to update soon, since the benefit of Siri, Photos and the other major features is quite small, compared to the risk that I might loose working days if something goes wrong ( I'm a freelancer ). As far as I read in the article there will be 10.12.1 ( the final fix ) which will have that part of the kernel refactored. I hope Apple will also support 10.11 and issue an update with the s…

I got an update to 10.11 El Capitan yesterday, which probably fixes the vulnerability. You can see the fix in Apple's support page, have a look at the bottom of the page about "System Boot": https://support.apple.com/en-us/HT207275 It looks like even 10.10 Yosemite got a fix. Here's a full list of security fixes Apple has made to its software: https://support.apple.com/en-us/HT201222

Sure looks like it, 10.10 + 10.11 + 10.12 is listed under the "System boot" CVE-2016-4669 entry. That must have taken quite the effort to backport!

Re: Task_t considered harmful

#57

Post by blinkingled »

tptacek wrote: post #46
blinkingled wrote: post #12

Earlier quoted context omitted.

Yeah - the failed mitigations followed by a "long term" fix was interesting as well. Apple literally had to change execve() this late in the OS's development cycle to allocate new task and thread structs(that's two extra allocations and copies in hot path!) to fix it for good. That this design problem lingered around for so long doesn't look good for Apple - it's one thing for a use after free bug in obscure piece of…

This is kind of a "perfect storm" situation for Apple. At least three vectors are converging: 1. Apple inherited OSX from NeXT, and with it the Mach subsystem. Mach overcomplicates XNU. 2. XNU has become incredibly popular by dint of being shipped in the iPhone. Avie Tevanian probably did not see that coming when they designed the original BSD/Cocoa/XNU/whatever architecture. Regardless: it is now difficult to make s…

Keep in mind that this is a dangling pointer problem that is a stupid design mistake and Apple's own kexts used the same vulnerable pattern for years before Project Zero had to disclose it to Apple after which there were two failed mitigations and a fix that changes core OS code!

That's not very justifiable no matter how many storms and twisters you throw in the mix ;) I am not going to argue but for OS development this looks bad that it wasn't even looked at much rather fixed for so long given many of Apple's kexts had the same issue.

[Also this isn't an isolated problem by the way - look up the thread and you'll find two other egregious errors including one involving execve that was pointed to Apple in vain. Not long ago I could just remove and insert a kmod and that would lock up the system - go ahead and argue that's not a hot path or nobody does that but it does speak to general lack of code and testing quality. To their credit Apple fixed that particular one though when I reported them.]

Re: Task_t considered harmful

#58

Post by 0x0 »

tptacek wrote: post #43

Bug 1: Many XNU drivers save task_t's on the heap without bumping their refcount. 1. Attacker creates process A and B 2. B->A send task port Bt 3. A->XNU request IOKit framebuffer client for Bt 4. A ditches Bt, retains client 5. Kill B; Bt in client now dangling 6. Trigger creation of privileged C, unrelated to A & B 7. C inherits memory once used by Bt 8. A use retained framebuffer client to write C's memory What's…

In particular about "pattern of UAFs scattered throughout XNU", there was missing memory management of task_t references in the sample code for kext drivers. So it wouldn't be enough to just add the missing retain calls in the Apple XNU kexts, because there may be an unknown number of third party kexts out there. Perhaps not as many as windows has device drivers, but it's still the same type of thing. Can you imagine if every windows device driver turns out to have copy-pasted privesc bugs?

In fact I think there was a similar bug-in-the-templates requiring a world-wide recompile in Microsoft MFC/ATL, perhaps it was this one https://blogs.msdn.microsoft.com/vcblog/2009/08/05/active-te...

Re: Task_t considered harmful

#59

Post by yuhong »

tptacek wrote: post #48
softawre wrote: post #29

Interesting timeline stuff here: https://bugs.chromium.org/p/project-zero/issues/detail?id=83...

It's funny, but I think it's written that way on purpose, not just as snark. It's a little tricky to keep track of what happened here. There are 4 bugs in this post, and (I think) 2 different timelines: the UAF timeline for the first bug, and the TOCTTOU timeline for the 3 subsequent bugs. What's important to understand about the three TOCTTOU bugs is that there's a "right" fix for that bug, and a series of wrong fix…

I wonder if it was really the CEO or was it someone else, and who it is probably is here.

Re: Task_t considered harmful

#60

Post by duaneb »

wyager wrote: post #54
tptacek wrote: post #47

Earlier quoted context omitted.

So far as the current state of the art in computer engineering goes, we don't know how to completely rewrite a system as complicated as XNU without creating fresh batches of implementation errors. So this is a little like suggesting Apple use its hundreds of billions of dollars to build an iPhone battery that only needs to be recharged once a month. We may someday get an XNU rewrite, but probably not until software e…

SeL4 is an indicator of things to come. We can build complicated OSs with extreme reliability; the up-front cost is just higher than most companies are willing to spend right now, because customers don't yet realize that it's technically possible to avoid the huge costs associated with software failure in exchange for slightly higher amortized software costs.

I don't think I've ever seen a complicated OS based on SeL4, and it is the opposite of complicated itself.

I don't think SeL4 means much for macOS/iOS.

Post reply on HN