Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Apple Businesses

Apple Plugs Software Update Hole 181

Posted by CmdrTaco from the plugging-the-holes dept.
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."
This discussion has been archived. No new comments can be posted.

Apple Plugs Software Update Hole More

Apple Plugs Software Update Hole

Comments Filter:

  • Apple (Score:2, Funny)

    by FigBugDeux ( 257259 )
    Was there a worm hole in the apple?

  • That's a good thing. (Score:3, Funny)

    by vegetablespork ( 575101 ) <vegetablespork@gmail.com> on Saturday July 13, 2002 @10:16AM (#3877117) Homepage
    We wouldn't want all those people more intelligent [slashdot.org] than the rest of us to get rooted.

  • how do you update? (Score:3, Funny)

    by Anonymous Coward on Saturday July 13, 2002 @10:16AM (#3877119)
    Do you use the software update mechanism to update the software update mechanism?

    • Re:how do you update? (Score:2, Informative)

      by Anonymous Coward
      No go here
      http://docs.info.apple.com/article.html?artnum=7 53 04

      http://docs.info.apple.com/article.html?artnum=7 53 04#checksum
    • No, actually you download it from Apple's web site and verify the integrity of the downloaded file using the instructions on the web site, using sha1 to get a checksum and compare it to the one they give there. That way you ensure the update is the right file, and from now on you can use software update securely.

      Checksum info [apple.com]

    • Re:how do you update? (Score:2, Informative)

      by CyberBry ( 196935 )
      Yes, the update is available in Software Update.
      Here's what the description says:

      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
  • IIRC, doesnt MS's Windows Update already do something like SHA1 (or some other algorithm) signiture checking?

  • Good for Apple! (Score:1, Redundant)

    by dpbsmith ( 263124 )
    Subject line says all...

  • stating the obvious, but... (Score:3, Interesting)

    by siliconwafer ( 446697 ) on Saturday July 13, 2002 @10:24AM (#3877170)
    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.

  • Actually, it's only half-fixed... (Score:5, Insightful)

    by imac.usr ( 58845 ) on Saturday July 13, 2002 @10:24AM (#3877173) Homepage
    ...that is, until this is backported to OS 9.

    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 don't think most OS 9 users are worried about getting rooted by script kiddies.

    • OS9 and OSX are VERY diferent from the ground up. I would be surprised if fundamental security issues that are found in one, exist in the other.

      Cheers

    • Re:Actually, it's only half-fixed... (Score:5, Informative)

      by KFury ( 19522 ) on Saturday July 13, 2002 @12:33PM (#3877818) Homepage
      and to prevent Classic from becoming its own security hole.

      This wouldn't be a problem for the average user running OS X and classic, since the OS 9 version of software update wouldn't ever be launched. Only the Os X version would be activated regularly to check for updates.

      True that until they patch the OS 9 version similarly there will be a lingering risk for people running OS 9 as their primary OS, but not for those using it in Classic mode.
      • This wouldn't be a problem for the average user running OS X and classic, since the OS 9 version of software update wouldn't ever be launched.

        Actually, Classic regularly launches OS 9's Software Update on my Cube, every Monday night. A holdover from when I was using OS 9 as my main system, more than 1 year ago.

        I realize now that the reason I didn't deactivate it is because I'm not an average user. I thought I was just being lazy ;-)

    • Actually, from what I understand (ok, someone on #macdev mentioned) that OS9 security updates are already digitally signed.
    • Since Apple isn't going to be releasing more software for OS 9, you should just disable OS 9 software update, and you won't have any problem.

      Knowing that there will be no more OS 9 updates, why would someone be running OS 9 Software Update anyway?

      • There are likely to be continual updates/bug fixes to the classic/Mac OS 9 software components. For example there was a recent CarbonLib update.

        It is true that there are no major updates expected as Apple has stated that they are not going to make any, but bug fixes and possibly efficiency updates will likely continue for some time.

  • 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
    • Speaking from experience, yes, often times a whole bunch of features are developed and then they sit on it. It makes more marketing sense to release things in increments.

      Hard to tell whether this is right or wrong...but at least they released this quickly after the flaw was announced.
    • 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. ;-)

  • And if this was Microsoft (Score:1)

    by Anonymous Coward
    people would be screaming about how slow and inefficient they were.

    Hypocrites.
    • 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.

  • check the authenticity of this update too (Score:5, Informative)

    by Kevinv ( 21462 ) <kevin.vanhaaren@net> on Saturday July 13, 2002 @10:38AM (#3877233) Homepage
    if you want to make sure this update is valid you can read the update info and verify the checksum [apple.com]

    or for the extra paranoid, check the secure page [apple.com]
    • Is either of these really secure? A checksum is to be used to make sure the download worked, not to make sure the file has not been replaced my malicious code. And can't a secure page and DNS can be forged? A certificate can be checked, but who does?

      Am I wrong?

      • Yes,a checksum is based on the data in the file. If you change any data in the file you get a different checksum.
      • If you sign an md5 checksum of your code with a private key(this is what code-signing is), you can easily write software that will only install the program if the cryptographically signed checksum sent along with the program matches the md5 of the program when decrypted. In fact, I'm working on a project that uses this very method right now. Of course, this relies on the private key being well protected. In general, the private key should always be on a computer disconnected from all networks. This way, the program has to be manually signed, and can't just be signed by a machine (or a hacker). As long as the client side software is secure, and the private key is kept off the network on the server side, there should not be any problems.

      • Not Quite (Score:5, Informative)

        by Llywelyn ( 531070 ) on Saturday July 13, 2002 @02:09PM (#3878299) Homepage
        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.
        • 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.

          If you can prevent physical access to your machine (if you can't you're sunk anyway, period) then it's generally sufficient to have your checksum list stored on a floppy which is not write-enabled.

          Storing it offsite but online doesn't help; storing it offsite and not online makes it unusefully unwieldy.

      • I'm sure they would send you a CD with the update and a password to get in to the encrypted diskimage on the CD, if you just ask... and send a check for $20 (processing/shipping fees).

      • Re:check the authenticity of this update too (Score:5, Informative)

        by thrig ( 36791 ) on Saturday July 13, 2002 @03:21PM (#3878596)

        There was also a post to the security-announce list [apple.com], signed with Apple's Product Security key [apple.com], which you can verify with a live person [apple.com] if you really feel like it. The post contained the website notes, plus SHA1 checksum of the installer disk image. Given current security technology, Apple covered their bases quite well.

      • That's only true if the checksum to be checked is embedded in the file that is downloaded with no independent way of verifying the checksum.

        Since Apple has provided a web page with the checksum listed you can check the signature yourself. They also used the SHA1 method for generating the checksum, which guarantees there can be no other file/message with the same signature.

        If you use Apple's secure page to independently check the checksum the following steps need to take place to present a false update:

        a) DNS spoof Apple.com
        b) Get a forged SSL certificate in apple's name (not impossible, remember someone got a Microsoft certificate not too many months ago)
        c) provide your own update and the signature for that update

        Not an impossible scenario, but not an easy one either.

        Assuming you got a real software update the scenario becomes more difficult by adding a public key signature on the update, so now the private key (assuming they aren't signing them with multiple keys) also needs to be cracked to provide a bogus update.

        The most likely source of a bogus update becomes an insider at Apple using the legitimate software update process to provide a properly signed bogus update.

  • Good turnaround Apple (Score:3, Insightful)

    by PierceLabs ( 549351 ) on Saturday July 13, 2002 @10:44AM (#3877272)
    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.
    • 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.

      Speak for yourself dude. Personally, I enjoy being rooted-- sometimes several times a day. Remember: it's only naughty if you want it to be.

  • funny X (Score:1)

    by Anonymous Coward
    so you think X acts odd?
    look at good old mac os 9 where holding down the mouse button would freeze every process of copying or deleting files.

    so what?
  • 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...
  • It's better that SU looks at checksums of incoming packages, I agree.

    But how does it verify the checksums it matches?

    If SU is looking up a list of checksums on a web site somewhere, what stops this attack from happening again?

    Just set up another spoofed web server that dishes out checksums for bogus packages, and SU thinks everything is okay...
    • As I understand it, it's not just using checksums, which I agree could still be open to attack. It's requiring all the packages it installs to be cryptographically signed - i.e. Apple must sign all packages they release with THEIR private key and the Software Update client has a copy of Apple's public key in order to be able to verify the signatures. If the signature can't be verified, it won't install the package - i.e. for a malicious third party to be able to install something on a user's machine via Software Update not only would he have to DNS spoof as before but he would also have to obtain Apple's private key from somewhere, which I would hope/expect is fairly difficult. This is the same practise as RH, Ximian et al. use...

  • Funny (Score:1, Insightful)

    by Anonymous Coward
    Slashdot is funny. When Microsoft announces a patch for Windows two days after a security hole is found, they get bashed for publishing insecure software.

    When Apple fixes a hole five days after acknowledging it, they're praised for being so quick to patch it.

    • Re:Funny (Score:5, Insightful)

      by jamie ( 78724 ) <jamie@slashdot.org> on Saturday July 13, 2002 @12:37PM (#3877834) Journal
      "When Microsoft announces a patch for Windows two days after a security hole is found, they get bashed for publishing insecure software. When Apple fixes a hole five days after acknowledging it, they're praised for being so quick to patch it."

      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 [cunap.com]

      http://online.securityfocus.com/archive/1/280964 [securityfocus.com]

      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!

    • Just checking (Re: Funny) (Score:5, Informative)

      by Anonymous Coward on Saturday July 13, 2002 @01:00PM (#3877942)
      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.

    • Linux is Funnier (Score:2, Insightful)

      by feldsteins ( 313201 )
      The real truth of the matter is that it's not Apple who gets a free ride here at Slashdot - it's Linux. Usually when a Linux distro is patched/updated the story on the front page ( and it's always on the front page) usually includes the word "drool" and at least one exclamation point. Apple takes their lumps here same as Microsoft. Worse in many ways because more than half the people here are at least dual-booting a MS OS. Almost none are using an Apple one. But when do the Linux guys get criticised here? About anything?

      And just for the record [slashdot.org].
  • Yes, but can we trust the software update to software update? 8-)

    • Re:software update (Score:3, Informative)

      by jamesoutlaw ( 87295 )
      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"
      :)
    • Funny you should ask, because Apple has answered that exact question. On the download page for the update you will find instructions on how to verify the SHA checksum of the installer.
  • Yeah, but what if they want to add new features and remove bugs and security holes from the software update hole patch?

    Then they'd have to make a "Software Update Security Hole Patch software update/security hole patch".

  • Yes, you can update software update using software update.

    Here's it's description of the path:
    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

  • Now let's turn the tables. (Score:2, Interesting)

    by 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.
    • and web browsers would default to https

      Who wants that? Encrypting everything is usually not the answer. Since usually you don't really care if you're browsing a website securely or not, and https incurs performance-damaging overhead, I would be hesitant to use an https-always browser.
    • 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 wouldn't want to encrypt everything. But I wouldn't mind if everything was cryptographically signed. I mean EVERYTHING. Including email traffic because then spammers could be traced better. Then you could filter on a CA or lack there of.

      Ok, back to reality.

  • New softwareupdate command (Score:4, Informative)

    by znu ( 31198 ) <znu.public@gmail.com> on Saturday July 13, 2002 @01:17PM (#3878052)
    This update also adds the command-line updating tool that comes with Xserve. See 'man softwareupdate'.

  • Not a solution, just requires a different attack (Score:3, Interesting)

    by gerardrj ( 207690 ) on Saturday July 13, 2002 @02:14PM (#3878321) Journal
    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.

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

      • The solution where there is one private key used to sign, and they give out the public key has a few issues:
        For someone to steal a single private key is rather trivial. Getting enough CPU together to brute force the private key is relatively simple, especially for a hacker that has compromised many systems and can easily install a distributed key generator on all of them. As was seen by several recent worms/viruses it would be possible to install such a client of literally tens of thousands of systems. Since you can have both encrypted and decrypted versions of the protected information, checking for a good key is easy.

        If, in my method, a hacker was to get hold of a public key or two (or a hundred), only a few people or sites would be affected. All the other keys would not be compromised. The risk of wide-spread corruption is almost nil. A hacker would need to get the account information and the account's encrypting key before a successful redirection would work and install the modified code.

        Apple already has the infrastructure of the iTools system for storing the private keys for each site/user/system and for the authentication for updates. The only thing that would remain is to be sure they have enough CPU power to to on-the-fly signing for each request. This is the scenareo I see: Create a public/private key pair using an Apple supplied utility (or GPG) Log in to iTools and send them the public key (using SSL) later: SWU queries Apple for any new packages If packages are available, SWU sends the iTools account info (using SSL) Apple retrieves your public key and uses it to sign the appropriate packages SWU retrieves the signed packages and verfies them against your local private key If they pass muster the packages are installed. Many people will say the single signer model is safe enough. That may be true, but don't for a moment think that it actually eliminates the risk of wide-spread distribution of fake updates. The multiple signers model does.

        • Re:Not a solution, just requires a different attac (Score:3, Insightful)

          by Anonymous Coward
          For someone to steal a single private key is rather trivial. Getting enough CPU together to brute force the private key is relatively simple, especially for a hacker that has compromised many systems and can easily install a distributed key generator on all of them. As was seen by several recent worms/viruses it would be possible to install such a client of literally tens of thousands of systems. Since you can have both encrypted and decrypted versions of the protected information, checking for a good key is easy.

          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.

        • Getting enough CPU together to brute force the private key is relatively simple, especially for a hacker that has compromised many systems and can easily install a distributed key generator on all of them.

          I think you underestimate the difficulty of brute-forcing RSA-style keys... RSA-129 (which is about 426 bits long) took 1600 computers 8 months to factor back in 1994. That was the part that could be distributed over multiple machines. Then it took a supercomputer with 16384 processors 45 hours to solve the 4GB matrix that came out of the distributed part of the process.

          It's not gonna be a piece of cake to crack the 1024 bits keys that are the minimum people use these days, even if you do have tens of thousands of machines to do the distributed part. And after you're done with that, where are you gonna get a computer that can solve a multi-gigabyte matrix in a reasonable amount of time?

          • I know ciphers are hard to break. But they are not impossible to break, and certainly not difficult to steal. If (when?) the Apple encrypting key is compromised, potentially the entire Apple community would be affected. Apple could almost totally eliminate that risk with the multiple/unique signing keys method. If they want to fix the problem they should really fix it with something that addresses the 'worst case' scenareo.

            • > I know ciphers are hard to break. But they are not impossible to break

              While this is a valid point, I doubt it poses a plausible threat in this particular case, primarily because public key encryption is so widely used. If anyone wanted to spend enormous amounts of resources to crack such keys, the chances are, they won't be going after Apple's Software Update servers and it's relatively small number of clients.

              The same has been seen with viruses. It's not necessary that viruses and worms are more difficult to write for Macs (although thay may be the case), but a simple matter of economics. Why write a virus that would, at most, infect 2-4% of the world's computers when, for the same (or less) effort, 90% of the world's computers can be targetted?

              • Good point. But that could also be said about the initial 'problem'. If someone where going to do a MiM attack via DNS spoof, why would they target Apple and not Microsoft, or Adobe or Id(or whoever makes the latest game).

                I think the problem with your statement though is that it qualifies as security by obscurity. Claiming relative safety because of a relatively small size is just bad voodoo.

                As for the cracking issue, I'm be far less worried about someone cracking the cipher than I am someone emailing it out of the building, or someone hacking in and downloading it.
  • 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.

    • The "Installer" application has a bug in which it miscalculates the space required for an update or install. It's a silly bug, but since most new Macs have a hard drive of 30GB or more even 300MB is hardly anything.
    • The resume on failure is a problem
      You can find all the successfully downloaded updates in "/Library/Receipts". You can double-click the packages in there to install the update, copy the update to another machine and install it, burn it to CD for later use, etc.

      On the down side, Apple doesn't seem to advertise they they store all the update packages there, so some people can't figure out where all the HD space is going.

      • What you find in /Library/Receipts are just that, receipts, not the whole package. If you want to keep a whole package you have to save it from the Software Update program just after it has finished the install, otherwise it gets deleted.
      • actually the packages in /Library/Receipts contain everything except for the actual payload. That is, they have the Readme, install information, file list, etc., but not the actual files. That's why they're called "Receipts".

        For example, the very large (400MB+) developer tools package has a receipt of size 616k.

        In order to save the package to install later or on other machines, you have to select Update:Save Update before you click the "Install" button in Software Update.
      • /Library/Receipts does not contain the updates - it contains, as the name suggests, receipts for the updates. These receipts contain the bill of materials (.bom) for the package and various other components of the update. They lack one crucial bit of the actual update package, however - they do not have the compressed archive of the new files! Essentially, it's all the package metadata stripped of its data.

        The receipts folder is not really "where all the HD space is going". On my system it totals 32 MB for all the 10.1 updates, language packages, dev tools, etc. I'll tell you what's REALLY to blame - did you know there's a directory called "usr" on your disk that you can't even SEE? It's using up almost 240 MB on my disk! Of all the nerve....

  • hmmm (Score:4, Funny)

    by owenc ( 255848 ) on Saturday July 13, 2002 @04:20PM (#3878786) Journal
    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.

  • HOWTO report security problems to Apple (Score:3, Informative)

    by aelvin ( 265451 ) on Saturday July 13, 2002 @10:18PM (#3879843)

    If you need to report a security problem to Apple, there are instructions on the Apple Product Security [apple.com] page.

    It boils to an email to product-security@apple.com [mailto]. Encrypt sensitive information using Apple's product security PGP key [apple.com], 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 [sourceforge.net] and related tools, which are perfectly suitable for PGP, including rudimentary integration with Mail.app.

  • software update CLI tool (Score:3, Informative)

    by flamingnight ( 234353 ) <chris.garaffa@nOSpAM.gmail.com> on Saturday July 13, 2002 @10:23PM (#3879863)
    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.
    • Man this is going to make my job keeping client machines up to date a lot easier!

      SOFTWAREUPDATE(8) System Manager's Manual SOFTWAREUPDATE(8)

      NAME
      softwareupdate - system software update tool

      SYNOPSIS
      softwareupdate [item ...]

      DESCRIPTION
      Software Update checks for new and updated versions of your software based on information about your computer and current software.

      If you give no arguments, a list of available software updates is determined and displayed. Each entry includes the item name, description, version, and size.

      For each item name you give, the corresponding software update is downloaded, unarchived, and installed.

      softwareupdate must be run as root.
      ...

  • softwareupdate (Score:1, Informative)

    by Anonymous Coward
    One cool new thing in the Software Update Security Update... it adds a file to /usr/sbin/ called softwareupdate. Looks like darwin users may soon be able to keep upt odate as well

  • Note (Score:5, Insightful)

    by theolein ( 316044 ) on Saturday July 13, 2002 @11:57PM (#3880212) Journal
    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.
  • However, I would have thought that would be standard practice in this day and age, most everything else done by major companies has some sort of cryptographic signature in this sort of context...

Slashdot Top Deals

Order and simplification are the first steps toward mastery of a subject -- the actual enemy is the unknown. -- Thomas Mann

Close