Mountain Lion and Software Update

Mountain Lion introduces a small, yet significant change in how OS X clients communicate with Apple’s Software Update servers.

Mountain Lion clients by default now consult an HTTPS URL to check for updates on Apple’s servers.

This has the implication that you can no longer use DNS trickery with Mountain Lion clients to get them to access your internal SUS instead of Apple’s. Some organizations configured their internal DNS servers to resolve requests to swupdate.apple.com to an internal server.

The appeal of this approach (DNS hijacking) was that you did not need to touch any client machine to get it to use your internal Softwar Update server; any client using your network would “automagically” use your internal Software Update server.

HTTPS connections do certificate verification of the host. Since your internal SUS can’t offer a certificate proving it is Apple’s server (because it’s not!) a Mountain Lion client will refuse to talk to it. (It’s also possible that your internal SUS is not accepting HTTPS connections anyway, but even if you were to turn that on, it would not help.)

HTTPS prevents exactly the sort of DNS impersonation that made this hack work in the first place. Apple has closed that door.

In order to use an internal Software Update server (either Apple’s or Reposado) with Mountain Lion clients, the clients must be explicitly pointed to your internal server via MCX or by setting the preference using:
defaults write /Library/Preferences/com.apple.SoftwareUpdate CatalogURL <internalSUScatalogURL>

Explore posts in the same categories: Deployment, MCX, Mountain Lion, OS X, Security

14 Comments on “Mountain Lion and Software Update”


  1. I had guessed this was why our DNS hack wasn’t working, but it’s nice to have it verified. Thanks!

  2. jaydisc Says:

    Couldn’t you create a self-signed certificate for swupdate.apple.com and copy that certificate to the clients? Or sign it with an organisational certificate already installed on your clients?

    • GregN Says:

      If you are going to copy something or install something on all your clients, why not just make the proper configuration change? The entire reason people do/did DNS hacking was to avoid having to touch every machine.

      • jaydisc Says:

        Well, indeed the first solution would require that, but the second solution might refer to something already present, but yes, I agree; was just offering alternatives/ideas.

        Personally, I have always used the Workgroup Manager Guest Computer to push that setting to workstations.

    • SaxDaddy Says:

      The potential problem I see with that (I’m still getting up to speed myself) is that 10.8 defaults to only accept App Store and “identified” developers. This means you need to download a signed package, resign software with your Apple developer certificate or change the client setting. But just this week I was able to setup my internal swupd server for my company on 10.8 using http. The trick was the the previous URL of …8088/index.sucatalog won’t work because swupd 10.8 doesn’t setup this file automatically. But it does work with straight http.


  3. If you are using Profile Manager, you already have your own CA that your clients trust, so you could use it to sign the SSL cert. for your DNS hack. But if you use Profile Manager, you could also push the CatalogURL. And that’s more elegant.
    I have seen many hacks that work well today cause much pain later on, when other have to deal with it and its not properly documented or documentation lost etc. Imagine someone else taking over Software update Duties 2 years down the road, having to troubleshoot it not knowing you changed the DNS entries for swupdate.apple.com

    So: Hacks don’t pay.

  4. Matt Says:

    Well all the point of doing the DNS hack is to avoid changing the preferences. It’s really useful especially in school environment.
    Like when the laptop is on campus, all software update are going directly to the school software update. And as soon as the students leave the school, they can still use Apple software update back home for example.

    By setting the preference to use the local SUS, students cannot apply update if they are at home or during holidays.

    • Drew Says:

      Well, you could always do as we did and slap a lil app in their Applications folder (signed with your developer ID of course), to allow them to change it back at home.

  5. philipp Says:

    So in the end there is no way to re-establish the transparent local SUS like we used for years? No chance for DNS hack anymore?

    Thanks for any reply!

  6. skinlayers Says:

    I have to admit, this makes me sad. I’ve been using a wpad.dat file with polipo to cache Mac OS X updates. Its a shame too, considering that the packages are already signed, they don’t really need SSL while downloading.

    • Jeffrey Walton Says:

      > … they don’t really need SSL while downloading
      The first thing SUS does is fetch catalog files, which are an unsigned tar ball (*.GZ). The attacker can manipulate the catalog undetected. Its another Apple SECURITY FAILURE.

      > … packages are already signed…
      The “package” is not signed. Items or elements within the package are signed. That means the package can be tampered and go undetected.

      Schneier and Wagner introduced “Semantic Authentication” in 1996 after analyzing SSLv2. Apparently Apple did not get the memo. Its another Apple SECURITY FAILURE.


  7. […] reason for the error has its root in a change which Apple introduced with OS X 10.8.x, where Macs running 10.8.x and 10.9.x use an HTTPS URL to check for updates on Apple’s […]


  8. […] reason for the error has its root in a change which Apple introduced with OS X 10.8.x, where Macs running 10.8.x and 10.9.x use an HTTPS URL to check for updates on Apple’s […]


Comments are closed.


Follow

Get every new post delivered to your Inbox.

Join 191 other followers

%d bloggers like this: