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

21–30 of 89 posts

Re: Task_t considered harmful

#21

Post by Sidnicious »

garblegarble wrote: post #16
a-no-n wrote: post #14

Earlier quoted context omitted.

Thx. For an encore: /* must be run as root */ #include main(){for(;;){kill(-1,SIGCONT);sleep(10);}} and a .plist. Temporary hackaround.

What does -1 do, send that signal to all processes?

I was going to say that it signals launchd's process group — every process spawned by launchd, which always runs with PID 1. However, the `kill` manpage confirms your hunch:

  -1      If superuser, broadcast the signal to all processes; otherwise
          broadcast to all processes belonging to the user.
(This is on macOS/iOS, Linux might have slightly different semantics.)

Re: Task_t considered harmful

#22

Post by 45h34jh53k4j »

saynsedit wrote: post #13

The sad reality is that black hats have been exploiting this class of bugs for years .

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.

Re: Task_t considered harmful

#23

Post by [deleted] »

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…

[deleted]

Re: Task_t considered harmful

#24

Post by [deleted] »

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…

[deleted]

Re: Task_t considered harmful

#25

Post by wyldfire »

frou_dh wrote: post #10
d_rc wrote: post #6

“Considered Harmful” Essays Considered Harmful -> http://meyerweb.com/eric/comment/chech.html

Much like linking to xkcd 927, this is more tiresome than the 'offences' themselves.

The best xkcd-pedantry-twist is 1589 IMO. :)

https://xkcd.com/1589/

Re: Task_t considered harmful

#26

Post by twoodfin »

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…

10.12.1 was released two days ago, which probably motivated the timing of this (excellent) writeup.

Re: Task_t considered harmful

#27

Post by zitterbewegung »

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

Re: Task_t considered harmful

#30

Post by blumentopf »

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…

Business as usual with macOS. The other day I was browsing the ocspd source code. Turns out it calls openssl using system(). So openssl is officially deprecated on macOS and yet they're using it internally to handle certificates?! And there's an enlightening comment:

    /* Given a path to a DER-encoded CRL file and a path to a PEM-encoded
     * CA issuers file, use OpenSSL to validate the CRL. This is a hack,
     * necessitated by performance issues with inserting extremely large
     * numbers of CRL entries into a CSSM DB (see ).
http://opensource.apple.com/source/security_ocspd/security_o...

ocspd was introduced with 10.4. A decade ago. And that's really the problem with macOS: There's no refactoring of old hacks, but rather just bolting on of ever more new stuff.

Post reply on HN