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

81–89 of 89 posts

Re: Task_t considered harmful

#81

Post by abraham6464 »

blinkingled wrote: post #12
0x0 wrote: post #11

Copying my comment from the earlier submission that didn't gain much traction here: What an absolutely amazing tour-de-force of a devastating design flaw in all versions of macOS and iOS and tvOS and watchOS! The negotiations detailed in the bug report timeline about meetings between "senior apple and google leadership" for keeping this secret past the general deadline really underlines that.

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…

Pardon my ignorance, could you explain what "hot path" means in this context?

Re: Task_t considered harmful

#82

Post by wahern »

blinkingled wrote: post #57
tptacek wrote: post #46

Earlier quoted context omitted.

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 t…

AFAIU, the dangling pointer problem wasn't a defect in the kernel; it was a problem introduced by some module authors who misunderstood the ownership semantics of the API. It might not even have been a pointer, per se, but I guess that's beside the point.

The larger problem was an inherent TOCTTOU bug in the interface semantics between the BSD subsystem and Mach. AFAIU that wasn't a dangling-anything problem; the reference was still valid. It was a logic and design problem that could happen in any language, even in Rust, and even without resorting to unsafe code.

Re: Task_t considered harmful

#83

Post by notalaser »

sedachv wrote: post #66
notalaser wrote: post #61

Earlier quoted context omitted.

This is so, so true, that I wish there were enough beer in this world to gift you with. There's a lot of cruft in XNU, and there's even more of it in the rest of the system, but all this heap of hacks isn't just useless cruft that we'll be better off without. That heap of code also contains almost twenty years' worth of bugfixes and optimizations from more smart engineers than Apple can hope to hire and get to work t…

> This is so, so true, that I wish there were enough beer in this world to gift you with. There's a lot of cruft in XNU, and there's even more of it in the rest of the system, but all this heap of hacks isn't just useless cruft that we'll be better off without. That heap of code also contains almost twenty years' worth of bugfixes and optimizations from more smart engineers than Apple can hope to hire and get to work…

I was (obviously...) responding to this:

> 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.

They certainly don't have to throw everything away. Not having thrown everything away is one of the reasons why OpenBSD is a good example here. Remember all that quality code that was in place before Cranor's UVM? (Edit: actually, the fact that UVM is an improvement over it should say something, too...)

And, at the risk of sounding bitter, in my experience, very few companies have the capability to "commit to code quality", and I don't think Apple is one of them.

Edit: BTW, I really like your blog. You should write more often :-).

Re: Task_t considered harmful

#84

Post by sedachv »

notalaser wrote: post #83
sedachv wrote: post #66

Earlier quoted context omitted.

> This is so, so true, that I wish there were enough beer in this world to gift you with. There's a lot of cruft in XNU, and there's even more of it in the rest of the system, but all this heap of hacks isn't just useless cruft that we'll be better off without. That heap of code also contains almost twenty years' worth of bugfixes and optimizations from more smart engineers than Apple can hope to hire and get to work…

I was (obviously...) responding to this: > 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 . They certainly don't have to throw everything away. Not having thrown everything away is one of the reasons why OpenBSD is a good example here. Remember all that quality code that was in place before Cra…

> Remember all that quality code that was in place before Cranor's UVM?

So much before my time I was not even aware of it. For the uninitiated: https://www.usenix.org/legacy/events/usenix99/full_papers/cr...

> Edit: BTW, I really like your blog. You should write more often :-).

Thank you. :) Just this week I started thinking of getting back into it.

Re: Task_t considered harmful

#85

Post by aorth »

a-no-n wrote: post #2

Ever since installing 10.12.1, I've been having a bunch of processes randomly entering a quasi-paused SIGSTOP-ish state (neither closable, apps not "bouncing" (loading) and just not responding. Running Instruments, correlating logs and such doesn't identify any clear cause. I'm having to `sudo kill -CONT -1` in order to get things moving again. I'm wondering if it's related to XNU mitigations or just some spurious "s…

It's funny you mentioned processes entering a quasi-paused SIGSTOP-ish state. I swear I've been having tons of problems with Java/Tomcat the past week or so I've been on 10.12.1 (betas), and I keep thinking I broke my config by updating my Java version, changing my Tomcat config, or some other "system configuration entropy"! Nice to know I'm not alone and that I'm probably not crazy.

Tomcat 7.0.72 from Homebrew, Oracle Java 8u112, PostgreSQL 9.3 and 9.5.

Re: Task_t considered harmful

#86

Post by tptacek »

notalaser wrote: post #83
sedachv wrote: post #66

Earlier quoted context omitted.

> This is so, so true, that I wish there were enough beer in this world to gift you with. There's a lot of cruft in XNU, and there's even more of it in the rest of the system, but all this heap of hacks isn't just useless cruft that we'll be better off without. That heap of code also contains almost twenty years' worth of bugfixes and optimizations from more smart engineers than Apple can hope to hire and get to work…

I was (obviously...) responding to this: > 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 . They certainly don't have to throw everything away. Not having thrown everything away is one of the reasons why OpenBSD is a good example here. Remember all that quality code that was in place before Cra…

Hold on, because, I'm pretty familiar with pre- and post- UVM OpenBSD, because Arbor Networks shipped on OpenBSD (against medical advice) and ran into a number of really bad VM bugs that Theo couldn't fix because of the UVM rewrite!

Re: Task_t considered harmful

#87

Post by thenewwazoo »

Jerry2 wrote: post #78
tptacek wrote: post #45

Earlier quoted context omitted.

It's a pattern of privilege escalation bugs. If you run untrusted code on your machine, that code can obtain root or alter the kernel, potentially even if it's running as nobody. There is a relatively long sequence of attempts to band-aid the bug, all of which failed, because Ian Beer found a systemic flaw, not just a single point flaw. So, the other implication for users is a general sense of foreboding.

So Apple still has no real solution to this bug?

The real solution (refactoring how execve creates tasks) was release with 10.12.1 (and updates to prior versions of OS X too).

Re: Task_t considered harmful

#88

Post by a-no-n »

cormacrelf wrote: post #31
a-no-n wrote: post #2

Ever since installing 10.12.1, I've been having a bunch of processes randomly entering a quasi-paused SIGSTOP-ish state (neither closable, apps not "bouncing" (loading) and just not responding. Running Instruments, correlating logs and such doesn't identify any clear cause. I'm having to `sudo kill -CONT -1` in order to get things moving again. I'm wondering if it's related to XNU mitigations or just some spurious "s…

I did exactly this when my Mac ran out of memory yesterday. Safari hung with a 'your computer is running out of memory' warning (168 tabs open!) and I didn't want to lose them all by force quitting. But the Safari process itself wasn't "Not Responding" and we were back to 0% CPU. So I quit everything else, SIGCONT'd Safari, and it started responding again, so I tried unsuccessfully to close some tabs. Of course, Safa…

I have 16 GiB and 0 GiB was occurring.

Re: Task_t considered harmful

#89

Post by navaati »

amluto wrote: post #76

I would argue that the original underlying problem here is the idea that having execve() increase privilege is acceptable. It's necessary for legacy reasons (sudo, anyone?), but even then, it's barely necessary. "sudo foo" could be implemented by asking a privileged daemon to run foo and handing off access to the console to the daemon. On Linux, you can do PR_SET_NO_NEW_PRIVS to turn off this type of privilege gain,…

> "sudo foo" could be implemented by asking a privileged daemon to run foo and handing off access to the console to the daemon.

FYI that exists, it's called pkexec (yes, from polkit) :)

Post reply on HN