Home > Security > Relax on Apple

Relax on Apple

Apple fixed their server. There are scenarios in which the clients are vulnerable, but it’s servers we need to worry about right now, and Apple did right by fixing their server.

Categories: Security
  1. Mike
    August 1, 2008 at 4:27 pm

    Apple should be held accountable just like any other company would be. Macworld wrote an excellent article on the subject:

    http://www.macworld.com/article/134793/2008/07/apple_dns.html

  2. Pilgrim
    August 1, 2008 at 4:49 pm

    Dude. Please. No more Chris Crocker blind links.

  3. Mando
    August 1, 2008 at 11:03 pm

    Chris Crocker – LMAO!

  4. Lars
    August 2, 2008 at 2:28 am

    Why is there a link to YouTube in the text?

  5. Ian
    August 2, 2008 at 4:58 am

    Why the stupid Britney Link?

  6. starbuck
    August 2, 2008 at 5:11 am

    I actually liked that link 😛

  7. August 4, 2008 at 10:34 am

    Well…it appears that Apple DIDN’T patch BIND after all, on the client side at least with no firm answer on the server side…nice Apple…really nice.

  8. August 4, 2008 at 10:35 am

    Well…it appears that Apple DIDN’T patch BIND after all, on the client side at least with no firm answer on the server side…nice Apple…really nice.

    http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9111363&intsrc=news_ts_head

  9. Ian
    August 4, 2008 at 11:55 am

    @Mando

    This is the point of the blog… Dan is saying to leave apple alone because they did the server at least. Unfortunately, it’s not clear from Dan/CERT/ISC what the risk is from the client not being patched compared to the server unless you read/understand the gory details of how Dan’s attack actually works.

  10. Mando
    August 4, 2008 at 2:33 pm

    well…if you read the article, you will note that the server patch is dubious as well.

    i understand the importance of this vulnerability and I find it unacceptable for apple (i own several of their products) to release a patch (server and client) so late in the game. and to see that the “patch” doesn’t doesn’t do a thing, that makes me wonder about the QA (or lack thereof) at apple.

    i would submit that the client patch is an important part of the solution, though not as elevated as the server patch.

  11. Marcos
    August 4, 2008 at 11:37 pm

    I’m with Mando on this one. I also own several Apple products, such as an iPod and a Mac SE/30. Right now, I’m afraid to even listen to my music. (Note: I’m always afraid to listen to music, mostly because I am afraid of man-in-the-middle attacks. I am so disturbed by the idea that someone might be intercepting my music requests and playing back subtly altered songs that I can’t sleep at night. This will be night 241.)

    Still, I think I can forgive Apple for forgetting to patch the OS X client and my iPod, given how they raced to get the server patch out the door.

  12. Ian
    August 5, 2008 at 11:12 am

    @Mando

    From the article, I don’t read anything that says there is anything massively wrong with the server patch other than it was late. Client, different story, though.

    Which bits of the story are you referring to?

  13. Bill Cole
    August 5, 2008 at 4:42 pm

    Let’s make sure we all understand what Apple did, since clearly Storms, Kelzer, and others have failed to understand it but published anyway…

    They ship all versions of MacOS with some version of BIND. For client versions of the OS, it is switched off but can easily be set up by anyone capable of setting up BIND. They make it relatively easy to switch on and configure in the Server version.

    Apple put out updates that included the new ‘P1’ versions of BIND with port randomization for both the desktop (aka “client” ) and “Server” versions of MacOS 10.4.11 and 10.5.3. If you’ve installed the update and need to confirm this, just run ‘/usr/sbin/named -v’ in a shell. Apple did not change the OS stub resolver and they did not implement port randomization in the socket subsystem. This is why the stub resolver is still using sequential ports: it uses a new socket for each query and does not specify the port. That’s not anywhere near as dangerous as having a recursive resolver using a single port or easily predicted ports.

    Dan has said that the problem is in the design of DNS and that port randomization is not really a fix, it just makes the guessing game a lot harder. That guessing game has to be made hard with randomization for recursing resolvers because it is fairly easy for an attacker to get a recursive resolver to send him some query packets to look at and analyze for a pattern. There is no way with a stub resolver such as Apple’s to send queries anywhere but where its own config files (usually a simple standard /etc/resolv.conf, but potentially a more complicated setup) say to send queries. The stub doesn’t do recursion, so it doesn’t send query packets (with its predictable port numbers) to arbitrary bad guys based on what a user tries to resolve.

    The vulnerability Dan discovered is not that query source port numbers are not randomized. The vulnerability is that DNS queries can be answered credibly by anyone who knows a small number of details about the query (a design flaw in DNS) and that an attacker could reduce that to just brute-forcing the 16-bit transaction ID for a recursive resolver with a fixed query source port because discovering that fixed port is easy and DNS itself tells the world where all of the recursive resolvers will be expecting to get answers from.

    Attackers may well get around to targeting stub resolvers, but it is hard to see how using sequential source ports on stub resolver queries really helps an attack based on forged replies. The attacker still would need to get some sample packets from the stub resolver to know where in the sequence to target and what IP address to spoof in the replies, and getting those packets is usually tantamount to have the query packet you want to spoof a reply to, in which case the variability of the source ports does not matter.

  14. Ian
    August 6, 2008 at 2:38 am

    @Bill Cole:

    Sequential ports could be really bad though… a hacker could simply constantly spoof using a static port number and wait for the stub resolver to come to you!

  15. D C
    August 14, 2008 at 8:48 pm

    Piggy backing off of Bill Cole’s comments, of which I agree – if in a corporate/organization environment, keeping a firewalled local caching server, forwarding downstream, should make the sequential ports on the clients moot – the only way to intercept stub queries, heading to your internal LAN DNS server, would be to breach the network itself. This was also a measure recommended by CERT. Also from CERT:
    “Stub resolvers are also vulnerable to these attacks, so system administrators should patch stub resolvers that issue queries in response to attacker behavior and that may receive packets from an attacker.”

    As Bill eluded to, most stub resolvers aren’t in positions to issue queries responding to attackers, or receiving packets from them, since they never touch the outside world for requests. This means you only have to worry about the downstream DNS server that your local server is getting responses from and passing onto your resolvers.

    I would like to see it patched on the client..but this may be more difficult to rework lookupd and its dependents.

  1. August 6, 2008 at 4:09 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: