Apple Plugs Software Update Hole
hype7 writes "Apple's getting quick! Less than 5 days after the recently reported software update vulnerability was discovered, Apple have a patch plugging the hole. Apparently, packages now presented via the Software Update mechanism are cryptographically signed, and the new Software Update client 1.4.6 checks for a valid signature before installing any new packages."
As a Tibook owner I'm darn glad Apple is getting more serious about releasing security patches. Now that they've entered the server market (with the Xserve), they really have no choice.
Well, considering all the real bits and pieces to solve this problem are in the BSD install anyway, it's really just a matter of gluing the bits together (see the docs on how to verify the checksum on the patch). The data exchange for Software Update is just plain xml, so no breakage when stuffing in the checksum. DiskCopy already has this built in, so that didn't need to be touched either, and it means that Apple already had the checksums for all the .dmg updates handy.
;-)
I think this could easily have been a "Joe, Steve wants a fix for this before you leave today" problem followed up by a week or so of testing and final rollout.
The OS 9 Software Update is a whole other matter though, since the checksum code isn't just sitting around waiting to be used. It might take a while longer for that to roll out.
Gee, unix and xml don't suck after all.
A hacker now just has to do some more work. Instead of just the DNS misdirection, they now need to create a checksum for their bad/malicious code. The updater will query their fake update server for the now forged checksum and see it matches the fake update package that was retrieved from the same hacked up server.
Even if they automatically get the checkum from a specific IP or set of IPs, all one has to do is create a server with that IP and insert it in the network and get a few routers to change their IP routing tables.
If they use a third party to verify the downloaded checksum is authentic, that server itself is vulnerable to the DNS and IP routing 'man in the middle' attacks.
This just makes the haker's job a little more complex. But if they have privs to alter DNS on a server this is just two minutes extra work. This whole thing is just silly. The initial problem was a non-problem. The solution doesn't provide any substantial obsticle to someone that wants to perpetrate such an attack. There in fact is no solution other than a 1-1 split key system. I generate a public key one time and send it to Apple. They then use that key to encrypt/sign all the updates sent to me. I use the private key to verify/decrypt the update and install it. I know that only Apple has my public key so I can be safe.
The problem here of course is that Apple needs to store potentially millions of public keys on their servers, and use a lot of CPU to do the unique signing/encrypting as people request the updates.
The split key eliminates the man in the middle, as they have no way to get ahold of each user's public key. They can't fake one, and no amount of DNS or IP redirection (other than the initial sending of the public key) will allow them to masquerade as the authentic site.
Article X: The powers not delegated... by the Constitution...are reserved...to the people
1) If you download a package, and for some reason, it doesn't install right off (any kind of error, or even if you're just not ready yet), Software Update FORGETS IT HAS DOWNLOADED IT. This is particularly frustrating when you have just downloaded an 18 MB package over your modem, and you have to do it again.
2) If you download part of a package, of course, it doesn't use any kind of smart downloading process to pick up where it left off. Arg.
3) What is this with everything requiring 300 MB to install 20 MB pieces of software? Sure, that's sneezing space for those of you with 40 GB drives, but some of us are still running mere 5 Gig machines.
Libertarianism is rich wolves and poor sheep playing gambler's ruin for dinner.
web browsers would default to https
The problem lies in that to serve https requests, you need a certificate (logical). Now, if you want your certificate to actually identify you as who you really are, you need to be certified by a certificate authority (CA), which itself is certified by somebody else until a root certificate authority. The process of certification costs money, and doesn't take only a few minutes to complete. So in addition to the performance degradation due to the encrytion (not bad on a small server, but can grow quite fast), you'd be effectively limiting who can operate a web server. Or else, if the server's certificate doesn't go back to a root CA, you wouldn't have a certitude on the identity of the distant server.
As to how Unix handles the verification problem, the major distributors digitally sign (PGP usually) their packages with their (or one of their) private key. And what happens if the private key is compromised? Same thing as with any private key scheme: you're screwed.
I think you're right. They would be bitching about how slow Microsoft is with the update. But surely you're not suggesting Apple is getting a free ride in the Slashdot forums. Apple takes a hell of a beating here or haven't you noticed that the main discussion here begins with 5 "jokes" at Apple's expense?
The more daring observation would be:
"If this were a Linux distro putting out an update they would be praised for how quickly and efficiently they had handled the situation." Or at least they would be instantly forgiven for having taken 5 days.
You like your Macintosh better than me, don't you Dave? Dave? Can you hear me Dave?