Software Update Vulnerability
redmoss writes "I just saw this exploit for Software Update on Bugtraq. Quoting the discoverer Russell Harding: 'Mac OS X includes a software updating mechanism 'Software Update.' Software Update, when configured by default, checks weekly for new updates from Apple. HTTP is used with absolutely no authentication. Using well-known techniques, such as DNS Spoofing, or DNS Cache Poisoning, it is trivial to trick a user into installing a malicious program posing as an update from Apple.' Looks like people using Software Update need to be careful, as there is currently no workaround." Well, one workaround for this particular exploit is to not share a LAN with someone who would do that sort of thing.
Software Update is convinent, but it only allows you to update Apple software (and the occasional IE bug fix). This bug could just as easily be exploited to allow for a Mac computer lab to auto-update third party software, reducing the hassle of network-wide installs, and potentialy making the lab more secure by fixing bugs in other softare. Apple should provide this option, IMHO.
Or would it? All you'd have to do is wait for a legitimate update to be released and mask your software as that update (same filename/size/desc). The end user would have no idea they weren't updating to OS 10.1.6, but rather installing a trojan. Software Update is a trusted source for most users.
These exploit techniques could be used by a good blackhat to affect everyone on, let's say Rogers Cable, in a specific geographic region. Face, it: since this became a one-protocol world with fat pipes, we all trust upstream.
Are you big enough for your home DNS to point only at root?
"Flyin' in just a sweet place,
Never been known to fail..."
what are you talking about? red carpet verifies the gpg signatures on rpms before installing them. i suspect windows update does something similar.
Apple should sign all updates and Software Update should verify what it downloads against Apple's public key. An attacker would then have to modify the copy of Apple's public key on the victim's machine, or modify Software Update to disable the check, both of which would presumably require root privileges. Still not perfect, but an improvement.
How to solve most of our problems: 1.Lots of nuclear plants. 2.Cure aging.
1. I believe swscan.apple.com to be the correct source. The point is, that could be made to resolve to a different, hostile, IP address.
2. A public verification key? From apple? See, thats the problem. They don't do that currently. When they start to, they'll probably build it into the software update system, like they should have in the first place.
An interesting sidenote: I've been sniffing some SU traffic after reading all this, and noticed some interesting HTTP headers: Looks like Apple doesn't practice what they preach in terms of server software.
And wtf is that NetApp cache bullshit? Does everyone see that, or am I being transparently proxied somewhere?! OK, just checked some other stuff, the NetApp cache header is only present on my SoftwareUpdate connections. Something on apple's end? Does everybody see this?
(fwiw i'm using the incredibly simple tcpflow to watch my tcp traffic. ethereal is cooler, and lets me see non-tcp traffic too, but the current mac (fink) version has a very high suck factor. Sometimes ICMP packets don't show up, streams can almost never be reconstructed entirely, etc etc. Moving capture files off the mac over to a linux or bsd box for analysis is the only way I can seem to use ethereal for much of anything.)
__
Choose mnemonic identifiers. If you can't remember what mnemonic means, you've got a problem. - Larry Wall
Apple appears to have blundered, although I am still watching for further news on how bad. The key will be to watch how quckly (or how slowly!) they respond with an appropriate fix. If it takes two weeks, that's bad. If it takes 3 days I'm not going to complain about that. We'll see what happens. Until then, no SW update for me.
Meanwhile I actually sent Apple an email describing the problem and asking for a public advisory and a fix ASAP. Just doing my part.
You like your Macintosh better than me, don't you Dave? Dave? Can you hear me Dave?
There is a very simple workaround. Just add the following line to your /etc/hosts
/etc/hosts file but, I'm pretty sure that you people (/.ers) know how to do this already.
204.179.120.93 swquery.apple.com
Now if somebody tries the DNS attack it won't work as we hardcoded swquery.apple.com -> 204.179.120.93 You will of course have to activate your
I know I'm going to hell, I'm just trying to get good seats.
MacOS X doesn't use the hosts file except in single-user mode, but once you've changed the /etc/hosts file you can update the NetInfo database like so:
/etc/hosts
sudo niload hosts /
-- thinkyhead software and media
Are you serious? Doesn't Apple advertise that Xserve is the perfect server for mission critical purposes? You must be either kidding (which i hope is the case), or smoking crack, man.
Why did Apple add hotswap drives, advanced monitoring tools, and 24/7 technical support? For shits and giggles? Why did they add REDUNDANT disk arrays? To impress the ladies? Why do they advertise this box to hardcore sys admins? Because they want sys admints to buy it. Do sys admins rely on boxes to handle mission critical operations? Yes. Is that not PREACHING?
Why, yes, it is.