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."
We wouldn't want all those people more intelligent than the rest of us to get rooted.
Call (206) 338-5780 COLLECT for information about a genuine BA, BS, MA, MS, MBA, or Ph.D.
Do you use the software update mechanism to update the software update mechanism?
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.
True, Apple has said that OS 9 is dead, but there's a hell of a lot of installations out there, and they all use an insecure Software Update mechanism as well. Apple needs to do the right thing and fix it for those who haven't upgraded because they can't (like those with hardware whose drivers haven't been updated yet), and to prevent Classic from becoming its own security hole.
I use Macs for work, Linux for education, and Windows for cardplaying.
if you want to make sure this update is valid you can read the update info and verify the checksum
or for the extra paranoid, check the secure page
Apple has been really taking security seriously lately and this only helps to build confidence that the machine is capable of being used by more novice users who know nothing about the evils of being rooted.
The situation is not quite comparable...
The last n Microsoft security holes that I've seen have been discovered by security groups which reported them privately to Microsoft, and worked with Microsoft for typically a month or two to get the patch out. Then the vulnerability was announced the same day as the patch release. A few days or weeks later, an exploit for the vulnerability was posted someplace reasonably mainstream.
Not so here. The Apple vulnerability was just posted to bugtraq along with an exploit. No indication was made that any attempt to contact Apple was made, much less working privately with Apple while the problem was resolved.
http://www.cunap.com/~hardingr/projects/osx/exploi t.html
http://online.securityfocus.com/archive/1/280964
Also this wasn't the worst vulnerability ever found. If someone poisons your DNS server they really can do all manner of bad things to you; Software Update is (was) just one of many concerns you should have. Keep your DNS servers secure!
They've got a secure download site available.
:)
From the software update inforrmation:
"Security Update 7-12-02 delivers a more secure Software Update service to verify that future updates originate from Apple. If you would prefer to download this manually from a secure Apple server you can download the package at http://www.info.apple.com/kbnum/n75304"
Do you ever use telnet? Ever?
Do you use insecure POP3?
If either of these things is true, your passwords are flying through unprotected space every time you do either one, and you have no sane reason to complain about apple leaving apple software update with this "hole" for so long. If someone has the ability to exploit the software update "hole" mentioned here, they also have the ability to eavesdrop on all the traffic-- including passwords-- that you create when you do telnet, insecure POP3, or a number of other things.
I'd say the hypocrisy here is that we're considering it a horrendous hole that an apple network application was susceptable to man-in-the-middle attacks, but we're not, as members of the internet community as a whole, looking for ways that we can implement things such as ssh tunnelling or s/wan on a massive scale so that man-in-the-middle attacks can be wiped out at the root of the problem instead of having to be implemented individually in every single application in the universe.
This update also adds the command-line updating tool that comes with Xserve. See 'man softwareupdate'.
This space unintentionally left unblank.
Yes, so long as the means of communicating the checksum are secure (i.e., not prone to a man-in-the-middle attack).
Actually checksums have been used for years in order to ensure that a program has not been replaced with a malicious bit of code or modified in any way:
For instance, you want to make sure you haven't been hacked and ls hasn't been tampered with to hide the files? Have an checksum for it stored offsite and/or in a secure manner (encrypt it with a symmetric key and pray that key hasn't been compromised as well) and then compare with what pops up when you look at the file.
The idea is that if the file has changed at all, the checksum is going to be different.
Note though that in order for this to work the means by which you receive the checksum *must* be secure. They can be cleartext (such as in this case), but you must be able to confirm the source of the checksum is who you think it is.
Thus, it would be a poor way for the software update mechanism to operate (since the attacker could send a false checksum) but is okay for something like this.
Integrate Keynote and LaTeX
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
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.
Ever heared about public key cryptography? They sign their packages with their private key, and their public key is hard coded in the software. It's not just a checksum, it's a cryptographically signed checksum. It's pretty safe.
To sign a checksum for his bad code, the attacker needs to crack Apple's private key. Which can take a few weeks if you're the NSA, but a few hundreds years if you're anyone else.
Yeah, yeah, yeah, and Microsoft doesn't have bugs, either. They have service packs...and service packs...and service packs...
There ain't no rules here; we're trying to accomplish something.
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.
doesn't seem to be compatible with the 10.1.3.1337 update that came out yesterday :(. in fact, all my programs don't launch anymore. not even aol.
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.
You mean lets say they took over distributed.net and had around 28,149 (or more, since this was the active number of participants in rc5-64 yesterday, who could have multiple machines) machines trying to crack said keys. Lets see, they have been working on rc5-64 for 5 years now... Putting in some estimation for moore's law, lets say it would take 2 years starting now. So lets get it done in a 3 months period then we need 8 times as many machines. That means at least 160,000 compromised machines all contacting unknown network addresses over three months. If that is not noticed, that is one hell of a hacker. And thats assuming that Apple used something with an outdated keyspace thats only about as large as rc5-64.
In other words, yeah, it might not be the safest option out there. But its safe enough for me.
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?
If you need to report a security problem to Apple, there are instructions on the Apple Product Security page.
It boils to an email to product-security@apple.com. Encrypt sensitive information using Apple's product security PGP key, key ID 0x44E85F68, fingerprint AE43 8996 9250 78A6 D587 3CA8 2165 60D7 44E8 5F68.
Although PGP for Mac OS X is sadly still in suspended animation, others have mentioned the availability of MacGPG and related tools, which are perfectly suitable for PGP, including rudimentary integration with Mail.app.
Well, softare update is now available from the CLI:
...]
Welcome to Darwin!
[jupiter:~] root# softwareupdate
Software Update Tool
Copyright 2002 Apple Computer, Inc.
Your software is up to date.
[jupiter:~] root#
Also, the man page for software update says you can install (a) specific update(s) by name, by softwareupdate [item
Interestingly, it must be run as root, though Software Update via System Preferences only requires an Administrator's password -- this could just be because it sudo's, as an admin *can* sudo... Also, it was written (the CLI tool, or at least the man page) on May 2, 2002.
I appreciate, even though it is probably coincidental, that Apple did NOT attack the press for reporting this hole before they had a chance to plug it. It has been a reasonably quick, mature response. Unlike another company that we all know that seems incapable of fixing holes without having a go at all "enemies" on the side.