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

71–80 of 89 posts

Re: Task_t considered harmful

#71

Post by tptacek »

blinkingled wrote: post #69
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…

Bingo! That's a beer shot :) Oh too much code, bad code, we inherited it, throwing out away won't work etc are baloney excuses without meat. All it takes is the will to hire and commit the right resources with an objective of increasing code quality. I mean take this bug itself - Apple did fix it but only after GPZ was on their arse. No reason they couldn't have reviewed it themselves and fixed it.

Hasn't the vulnerable code been here for over a decade? Why do people think this was an easy bug to spot? There are dozens of extremely qualified people looking for these things. I think there's a reason there isn't a Nemo Phrack article about this bug: it was hard to spot, and required a flash of insight about the competing lifecycles of objects in two different domains (POSIX and Mach).

Re: Task_t considered harmful

#72

Post by tptacek »

blinkingled wrote: post #70
tptacek wrote: post #67

Earlier quoted context omitted.

The dangling pointer isn't the interesting part of the bug --- dangling pointers are, to a first approximation, the key component of all UAFs, which are a 15 year old bug class. The interesting bit about this bug is how they arrived at the dangling pointer: they had to manipulate at least three different object lifecycles in the kernel, one of of which involved a credential passing trick that is not super common in n…

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…

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

Re: Task_t considered harmful

#73

Post by rictic »

saynsedit wrote: post #68
45h34jh53k4j wrote: post #22

Earlier quoted context omitted.

GPZ finds a entirely new class of vulnerability, Apple takes 4 months to patch and resolve. And you claim this has been exploited for years. There is 0 evidence of this, and such a claim demands proof. I would be happy to apologise if you could find one example of exploitation prior to a few days ago when it became public.

The point of the 0-day black market is to not reveal these attacks publicly. If there were public proof of this in the past it would have been fixed in the past. Take my word for it when I say there are upper echelons of black hats that are stockpiling unknown 0-day exploits like this and presently using them in the wild. Or dismiss me as irrational and continue with the belief that all bugs are unknown until white h…

There is a middle ground between "all bugs are known on the black market" and "no bugs are known only on the black market."

Re: Task_t considered harmful

#74

Post by blinkingled »

tptacek wrote: post #72
blinkingled wrote: post #70

Earlier quoted context omitted.

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…

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

Wow 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!

Re: Task_t considered harmful

#75

Post by __s »

notalaser wrote: post #61
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…

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…

But I am on the Linux side & wouldn't want to touch anything that is xterm or macOS again (suckless's st ftw)

Also currently running on a nice pure wayland system, no need for that X11 cruft

Re: Task_t considered harmful

#76

Post by amluto »

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, and it's even required for certain purposes. I would love to see someone develop a distribution that enables no_new_privs for all processes.

Re: Task_t considered harmful

#77

Post by tptacek »

blinkingled wrote: post #74
tptacek wrote: post #72

Earlier quoted context omitted.

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

Wow 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,…

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

Re: Task_t considered harmful

#78

Post by Jerry2 »

tptacek wrote: post #45
empath75 wrote: post #36

Can someone explain what this means for the end user?

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?

Re: Task_t considered harmful

#79

Post by EGreg »

dsr_ wrote: post #5
EGreg wrote: post #4

By whom?

The author(s) of the statement, who are hoping to convince you to adopt the same position.

But this passive voice with the subject omitted suggests that the article is a summary of a larger sentiment.

When Dijkstra says something is considered harmful, he is speaking on behalf not just of himself but others.

Re: Task_t considered harmful

#80

Post by mwfunk »

zitterbewegung wrote: post #27
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 really don't think they will release an update since after every 10.x release they stop doing updates for the previous release. See https://en.wikipedia.org/wiki/MacOS#Release_history

They do security updates for previous releases.
Post reply on HN