back to article 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 …

  1. Anonymous Coward
    Anonymous Coward

    Documentation has always been iffy for unix system APIs

    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.

    1. Hans 1

      Re: Documentation has always been iffy for unix system APIs

      You always needed books for serious coding, on any system I know of.

      VMS doc was pretty impressive, you still required books for serious coding.

      Windows docs (<command> /?) are, well, even less handy than the man pages ...

    2. Dan 55 Silver badge
      Boffin

      Re: Documentation has always been iffy for unix system APIs

      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.

      1. Anonymous Coward
        Anonymous Coward

        Re: Documentation has always been iffy for unix system APIs

        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?

        1. Peter Gathercole Silver badge

          Re: Documentation has always been iffy for unix system APIs @boltar

          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.

        2. Dan 55 Silver badge

          Re: Documentation has always been iffy for unix system APIs

          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.

    3. Peter Gathercole Silver badge

      Re: Documentation has always been iffy for unix system APIs @boltar

      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.

  2. Martin Summers Silver badge

    Buzzfeed Headline

    Please please don't lower yourself to keep using click bait headlines. I thought I was seeing one of those "get painfully thin using this one weird remedy" trashy articles. I thought the Reg had better standards.

    1. Handy Plough

      Re: Buzzfeed Headline

      Standards have been dropping for a long time...

      1. Anonymous Coward
        Anonymous Coward

        Re: Buzzfeed Headline

        Standards have been dropping for a long time...

        That's actually one of the reasons of hanging around - I'm mainly curious to see where this eventually ends up :)

  3. Spaceman Spiff

    OOB data

    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.

    1. Anonymous Coward
      Anonymous Coward

      Re: OOB data

      all of our users, including the US Navy

      You're one of the Village People?

  4. mevets Bronze badge

    Your confusion is my fault?

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

    ahem.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2022