iOS, OS X apps sent into infinite dizzy DoS by this one weird kernel bug Kenton Varda has found a 'weird' kernel bug used in Apple gear that could result in trivial denial of service by remote attackers. The hacker and LAN gamer bod says the Darwin kernel vulnerability (CVE-2015-1105) now patched by Cupertino for iOS and OS X is "no Shellshock" but could cause apps like Google Chrome to crash and …
OS/X isn't the only culprit. Theres a reason Stevens seminal unix programming books became so popular since trying to do any serious coding based only on what was in the man pages was a painful and often futile experience.
Also am I confused or is it the journalist? The kernel event queue and TCP data queues are not the same thing and I'm not sure why a program would use the kernel queue to read TCP data anyway.
You can set up a kqueue for, say, a socket and if there's data in the TCP queue then your program is notified by a kevent. When you get that kevent you read() or recv() the data and the kevent is cleared from the kqueue.
On a Mac if there's OOB data in the TCP queue you also get the same kevent but this time with the EV_OOBAND flag set which you're not interested in and you never thought to check for. What you do is use a read() and recv() without the MSG_OOB flag as normal and as they don't read OOB data the kevent for that OOB data is never cleared. They also also don't read the in-band data in the TCP queue stuck behind the OOB data either, they just return no data.
As they return no data you just forget about it and go back to checking the kevent queue again.
So as the kevent was never cleared the kevent stays at the front of the kqueue while everything else stacks up behind it and the TCP queue fills up because read() and recv() return nothing.
Apple's fix was to stop generating kevents for OOB TCP data, which might break a program or two, not as many as all the programs that are out there that never thought of checking for OOB data.
On the subject of data building up in the queue - I wonder how other unix's cope with OOB data if the receiver never reads it? Could in theory a malicious app send so much OOB on a TCP stream that it fills up a buffer on the receiving end causing some sort of fault , or do most kernels use a ring buffer where data just gets overwriiten if not read?
TCP includes flow control, which should prevent this on a connection-by-connection basis. It is possible that you could create so many connections and fill them up to exhaust mbuf or other buffer use, but there are normally mechanisms that refuse connections if the target system is running short of resource.
I can't see OOB data being handled any differently.
There are also time-to-live timeouts on the packets, which normally mean that stale packets are discarded once they reach a certain age, to prevent the never read scenario.
It wouldn't happen with other UNIXes with kqueue or select() because you wouldn't tell it you're interested in OOB data (you don't know what it is so you didn't give it the flag to say you wanted it), you wouldn't get an event for it, and it wouldn't be stored.
However on the Mac you get OOB data events for free when you set up a kqueue asking for TCP data events and at that point things go wrong, from the Mac's point of view you're now interested in OOB data and that affects how read() and recv() work.
And that's why documentation is important.
It depends how far back you go.
If you look at the UNIX Version/Edition 7 man pages (admittedly much simpler than modern UNIXes), then they documented the behaviour of the system much more completely.
More recently (last thirty years or so), features have been added and copied to each UNIX (often reimplemented from another UNIX) implementation without the correct emphasis on the documentation. And don't get me started on the appalling state of Linux documentation, especially the complete abortion that is the man page/info system that appears to suggest that the documentation has been written, when in many cases, it hasn't.
Only yesterday, I realised that the both the AIX and Linux man page for tail do not include in either the prototype or the description the tail -200 filename type operation (it's deemed obsolete in POSIX V2, but still works, and I've been using it without thinking for 30+ years). This obsolete use is described in the Linux Info article on tail invocation, but not in the man page (RHEL 6.5).
What books allow are practical examples of how an interface is used, so that (lazy) programmers can crib other people's work without having to find out for themselves.
Not that I think that is a bad idea! I think that a lazy streak (of the right kind) is an essential feature of a good programmer or system admin. It encourages finding out how to do things efficiently, saving time and effort later.
After having implemented a complete TCP/IP protocol stack from the DDN white books for a real-time operating system in the early 1990's, a customer (truck engine manufacturer in Indianapolis) found some problems in dealing with out-of-band data. I have "fond" memories of sitting in a little office in a very noisy manufacturing plant debugging and fixing the code. It took about a week of effort, but I was able to nail the problem and make an appropriate fix in our code, which was pushed out to all of our users, including the US Navy.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
