
Remotely send Chrome and Node.js into infinite loops via OS X kernel bug - kentonv
https://blog.sandstorm.io/news/2015-04-08-osx-security-bug.html
======
maqr
Anybody remember this gem?
[http://en.wikipedia.org/wiki/WinNuke](http://en.wikipedia.org/wiki/WinNuke)

~~~
eli
I remember patching it and then scripting mirc to seek out the handle of the
person who sent it via the source IP.

~~~
pkrumins
I scripted mIRC to WinNuke everyone on join in all channels. Something like
this:

    
    
        ON *:join:#: {
            /run c:\winnuke.exe $gettok($address,2,64)
        }

------
vbcr
The last statement reminds me of Linus saying

 _we do not break user space_

 _If an application is utilizing a bug, it is not a bug but a feature_

~~~
mkj
Apple's general approach is "if it isn't documented, we can break it", a bit
different to Linux.

~~~
joakleaf
I think, Apple's general approach is:"We can break it." Documented or not.

Seems like they change stuff all the time. Especially on iOS.

~~~
valleyer
Can you provide examples of non deprecated API that Apple broke?

~~~
interpol_p
The recent Swift 1.2 release brought a whole load of code breaking changes.
None of Swift 1.0 was explicitly deprecated.

~~~
Sephiroth87
That's a bit different, they explicitly said Swift is a work in progress and
code compatibility is not guaranteed between versions...

~~~
Zikes
After 1.0 API changes really should increment the major version.

~~~
ebbv
Unless you say "We're probably going to break things." when you announce it,
which they did.

~~~
cozzyd
Perhaps they should have chosen a more appropriate version number then.

~~~
zwily
Apple doesn't claim to do semver

~~~
Zikes
Regardless, that is what developers have come to expect. Not that semver is
adopted wholesale, but at least don't break the API without incrementing the
major version.

------
chrisdotcode
I think the conclusion warrants repeating:

"The moral of the story? Confusing APIs are a security problem. If many users
of your API get it wrong in a way that introduces a security bug, that’s a bug
in your API, not their code."

------
adamnemecek
> Linux has epoll. BSD has kqueue. Windows has... well, about five different
> mechanisms that cover differing subsets of usecases and you can only choose
> one.

Aren't I/O completion ports fairly analogous to kqueue?

~~~
phs2501
AFAIK (and I'm not a Windows person, so feel free to correct me) I/O
completion ports are analogous to something like Linux's kernel AIO (asynch
I/O). The model is to start an I/O operation on an fd (providing a buffer) and
then be informed of its completion (with the data already copied into your
process space), rather than the traditional Unix polling model of being
informed when there is data waiting on an fd an then do a (non-blocking) read
on it. If you're used to writing traditional Unixy event-based network daemons
this seems pretty backwards.

One advantage of the aio model is that it at least theoretically allows "non-
blocking" I/O of a normal disk file, whereas none of the polling-based systems
I am aware of work with regular files. However, at least on Linux the kernel
aio is notoriously fidgety (as it still may block the process if you take
certain kinds of page cache misses; the solution is apparently to use O_DIRECT
to bypass the page cache which has its own bag of problems), and most people
fall back to using blocking reads with thread pools, or something like libeio
or libuv that handles all that crap for you. (There's also the POSIX AIO
that's built into glibc, but that done entirely in userspace [presumably with
thread pools] and uses signal-based completion notification, which is kind of
gross and probably pretty slow if you have a ton of I/O events happening.)

~~~
arrested
I thought events all were handled were through libuv.

------
danatkinson
As an FYI, the Chromium bug has now been unrestricted for public viewing -
[https://code.google.com/p/chromium/issues/detail?id=437642](https://code.google.com/p/chromium/issues/detail?id=437642)

------
Dylan16807
I wonder if OOB data is ever going to be fixed to allow more than one byte.

I can't quite comprehend how the implementation got so screwed up in the first
place. A two byte field in every header, supposed to be a pointer to designate
a range of data, OBVIOUSLY when it's set it should transmit exactly one byte
of information.

~~~
duskwuff
Unlikely. Almost nothing uses OOB data (and it's unclear what it's even useful
for!), so there's no demand to fix it.

More likely, I suspect, would be a gradual move to deprecate OOB data. It's a
poorly designed wart on TCP.

~~~
ketralnis
I thought that SSH used it to pass ^C up faster than the rest of the stream so
that you can quickly kill programs that flood the terminal. I've never
verified this though.

~~~
MBCook
The article says Telnet works that way, it seems reasonable to think SSH might
use it for the same purpose.

~~~
0x0
But the ^C should be encrypted. If SSH sets the URG flag on a packet
containing an encrypted ^C, it would be leaking plain-text - even for just one
byte :)

~~~
krakensden
Not just encrypted, authenticated- it would be bad if a MITM could send ^Cs
out to fuck with you at any time.

------
tinco
I was a bit confused about at what layer this OOB byte would be sent, I think
this article cleared it up for me[0]. TCP has a feature called TCP Urgent Data
which can be enabled by flipping a bit in the TCP header. BSD maps this to the
OOB feature as described.

This means that if your Node.JS app was behind a http proxy that's not
vulnerable, like nginx+passenger, you would've been safe. Just a TCP pass-
through would leave you vulnerable though.

All theory of course, since no one is really running a Node.JS server on OSX..
right?

0]
[http://www.serverframework.com/asynchronousevents/2011/10/ou...](http://www.serverframework.com/asynchronousevents/2011/10/out-
of-band-data-and-overlapped-io.html)

~~~
nostrademons
It's a bigger problem for Chrome. Imagine if you ran an ad on a major ad
network that loaded a banner from your server that sent a byte as TCP urgent.
It would lock up any Mac who visited a significant fraction of the Internet.

(Incidentally, a bug like this was what got me to switch from Netscape to
Internet Explorer back in 2000. Doubleclick ran an ad that included some
Javascript which locked up Netscape and hung the browser entirely, blocking
roughly 40% of the Internet for me. At that point I was like "This is
ridiculous, fix your damn software Netscape" and switched.)

------
wmf
I'm kind of disappointed that this bug doesn't have branding. :-)

~~~
thomasjudge
"oob-killer?" "oob-o'-death?"

~~~
xorcist
Both the other brands have been clever and played on what's being exploited.
(Heartbleed is bleeding data thorugh heartbeat, for example.)

How about "reURGitate"? It plays on URG, and regurgitate is something you can
do forever.

------
krishicks
They seem to have only fixed this on Yosemite.

I can reproduce the bug on Mavericks and Chrome 41.0.2272.118 after the
2014-004 update for Mavericks.

~~~
brazzledazzle
If true that strikes me as kind of shitty. I know Apple doesn't care much for
maintaining old versions and backwards compatibility but Mavericks isn't all
that old.

~~~
kentonv
Ehhh. Maybe. Keep in mind that this bug is probably one of the _least_ serious
of the dozens of bugs patched today, as there's very little damage you can
really do with it. Hardly anyone runs OSX servers, so you're not going to take
down any major web sites with this. You can crash someone's browser, but
that's actually already pretty easy to do with some javascript that eats a
bunch of resources. Chrome doesn't even consider DoS to be a security issue
because there's just nothing they'll ever be able to do about it anyhow.

If the bug in any way threatened data integrity or confidentiality, then yeah,
they should backport it. But for a DoS, I can see the case for not really
caring.

FWIW, for many of the bugs patched today, Apple did in fact backport to
Mavericks and even Mountain Lion, so it seems like they haven't completely
abandoned old versions.

~~~
userbinator
_You can crash someone 's browser, but that's actually already pretty easy to
do with some javascript that eats a bunch of resources. Chrome doesn't even
consider DoS to be a security issue because there's just nothing they'll ever
be able to do about it anyhow_

They could implement resource limits and stop consuming more resources once
those limits are reached.

~~~
kentonv
It would be challenging to tell the difference between a legitimate but
resource-hungry site and a malicious one. In the former case, the user may in
fact want the site to page everything else out to get the job done.

In any case, DoS attacks exist yet don't seem to be a big problem in practice,
probably because there's not much in it for the attacker.

------
shakeel_mohamed
I wonder if this is related to a wacky clipboard bug I hit today while VMWare
Fusion was open. Basically I copied & pasted a file within a VM, then copied
some text from Chrome on OSX and Chrome froze instantly.

------
caf
I think this would apply to a few common ircds running on affected versions of
OS X too.

------
saool
Such a twisted forewarning about the importance of net neutrality...

