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

Comments

stating the obvious, but...

[siliconwafer]

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.

they probably had it done anyways...

[aveng0]

the reason it was so quick, was that they had probably included these crypto-features in their new upcoming os release(s)... they could have just done a diff ... but who knows? maybe they are quick! - david

Re:they probably had it done anyways...

[JohnsonWax]

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. ;-)

socially engineered hole...

[diablo943]

what a great way to sneak in a little trojan... spoof apple's own software update function and provide it for everyone under the guise of apple acting swiftly to patch a hole. put it up on a spoofed apple page and even provide a verification checksum to ease any suspician. ah well. would make a good movie twist...

Now let's turn the tables.

[Anonymous Coward]

ALL that this quasi-"hole" came down to was, "Wow! If you download software updates from apple.com over the internet, you are susceptable to man-in-the-middle attacks!" what a surprise. I mean, it's a VERY GOOD THING apple has plugged this, i'm just saying if they hadn't no one would have really been hurt :)

Anyway, though, let's just check: how do the other OSes handle this same problem? Someone in another thread claimed that Windows Update used some kind of "SHA-1" hashing, or something. OK. What about the Unix world? How does apt-get validate the checksums of the "new packages" it receives when you run apt-get update? How does "red carpet" do the same? What about the BSD ports system? When you go to www.solaris.com or www.redhat.com or www.kernel.org, and you see on the news page that there's a big new security patch, and you download it, how do you know that that's real and you aren't just looking at something sitting on a compromised router somewhere, masquerading as those sites?

I am just curious.

Maybe if the government would stop dicking with everyone and intentionally making it difficult to widely implement ssh and scp (scp is the ftp/ssh thing, right?) on a large scale in software projects such as web browsers, we'd have scp everywhere by now, and web browsers would default to https, and the public keys for ftp.apple.com and ftp.microsoft.com and ftp.debian.org would all be logged in the "trusted public keys" files of those respective OSes by default, and this wouldn't be a problem, becuase netscape and internet explorer would give you big warning signs everywhere when the ftp site you are looking at isn't the one you think it is.. and everyone would be just that much safer from being subject to service interruptions because of social engineering.

Re:Now let's turn the tables.

[Papineau]

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.

Not a solution, just requires a different attack

[gerardrj]

So now the packages are signed with some sort of checksum, like PGP or GPG or MD5. But the whole verification process is automated. So the installer now goes and gets the checksum from an Apple server.

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.

Other Problems with Software Update

[namespan]

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.

Re:And if this was Microsoft

[feldsteins]

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.