Comments on: Mountain Lion and Software Update

By: Jeffrey Walton

Jeffrey Walton — Tue, 16 Oct 2012 06:03:06 +0000

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

By: skinlayers

skinlayers — Wed, 26 Sep 2012 07:31:50 +0000

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.

By: jaydisc

jaydisc — Sun, 02 Sep 2012 12:29:34 +0000

Gatekeeper only checks the signing of the downloaded package, not the signing of the https certificate.

By: SaxDaddy

SaxDaddy — Sat, 01 Sep 2012 05:44:41 +0000

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.

By: philipp

philipp — Thu, 16 Aug 2012 12:43:13 +0000

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!

By: Drew

Drew — Thu, 09 Aug 2012 18:37:15 +0000

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.

By: Matt

Matt — Wed, 08 Aug 2012 05:37:17 +0000

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.

By: Andreas Schenk

Andreas Schenk — Fri, 03 Aug 2012 10:10:04 +0000

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.

By: jaydisc

jaydisc — Fri, 03 Aug 2012 04:39:05 +0000

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.

By: GregN

GregN — Fri, 03 Aug 2012 04:04:23 +0000

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.