Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Security Businesses Apple

Software Update Vulnerability 92

Posted by pudge from the oh-goody dept.
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.
This discussion has been archived. No new comments can be posted.

Software Update Vulnerability More

Software Update Vulnerability

Comments Filter:

  • It's not a bug, it's a feature! (Score:3, Interesting)

    by tristan-b ( 251953 ) <gunk@mac.com> on Monday July 08, 2002 @02:10PM (#3843958)
    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.
    • It would be nice if SU did provide a feature so that third parties could register their software with SU, and it could then be kept up to date transparently. Of course, this would only be a feature if the user got to pick the non-Apple software to be updated. Having a method where some client I install sets up SU to automatically keep spyware updated, and not telling me about it, would be most unpleasant.
    • I agree, this could be invaluable to sys admins.

      Rather than going through the agony of installing sshd on each and every client computer, and then writing a bash script to scp updated files as necessary, just have each client poll a central http server (hidden from the Internet by a firewall, of course) for bug updates. Then you just need one person at each workstation to click "okay" and install the thing.

      Just because the Mac is now Unix-based, doesn't mean we should give up the ease of use and convenience that made the Mac great in the first place.
    • It's called "Fink" and "apt-get". You can configure your sources for apt-get in whatever way you like.

      Granted, it's still a bit shaky on Macintosh OS X, but it's getting better.

    • If you're in a lab environment, Macintosh Manager and NetBoot should be able to help with the software distribution problem.
  • The Mac news sites are very thorough, and I always read about new updates before I see them on Software Update. Also, I don't install everything listed. I've marked as inactive several foreign language updates, and some AirPort updates, as I only speak English and don't have an AirPort card.

    • 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.
      • A trojan that's the same size as an OS update? I'd think that a trojan wouldn't need more than a few kilobytes to do its damage. Many major updates in X even give you the EULA before the download starts. I doubt many Trojan authors would duplicate that.

    • I don't think you quite saw the vulnerability. It's not a matter of hacking the Apple SU server, but rather the individual resolution to the server, or other similar methods aimed at the end user.

      I always check the response from others before applying updates as well (yea VersionTracker). But, if someone targetted my network (DNS servers for example) _I_ would be the only one affected by the exploit with this particular attack.

      So, all someone has to do is coordinate an attack on you with an update from Apple, you go read the reports, people say "Great update, no problems," and you go ahead and apply the updates across your machines. All the while, your DNS server was hacked, and your machines are actually connecting to some eroneous source that just installed a backdoor... and while it's at it, installs the Apple update to appear real.

      For now, you need to just trust that your local network and DNS is secure. But some form of host certification should really be applied to ensure that the app is connecting to a valid machine... much like web browsers can do when connecting to an SSL server.

      Just my $0.02. :)

      -Alex

  • True Of All Updaters (Score:2, Informative)

    by dthable ( 163749 )
    This is true of all those Automatic Update tools, including Red Carpet and Windows Update. They all use DNS to find the software on the Net and then install the modules without too much fuss. The only real work around is to know what you're installing. Download from what you believe to be the correct source, always look for a public verification key and then install it.

    • Re:True Of All Updaters (Score:3, Informative)

      by Anonymous Coward
      what are you talking about? red carpet verifies the gpg signatures on rpms before installing them. i suspect windows update does something similar.
      • what are you talking about? red carpet verifies the gpg signatures on rpms before installing them. i suspect windows update does something similar.

        erm, except the gpg signature comes from the same person supplying the malicious file..... oops.

        • Um, but the key used to sign the signature is known by the updater, which has the public key locally, and so the signature file would need to be used with a different key, which the client program would recognize as different. The whole point of PGP/GPG is that the key of the signer is known and trusted. If you could hack the client to recognize a different key, then that would be a problem. Otherwise, the only way would be to crack the GPG key ... oops.
    • The only real work around is to know what you're installing. Download from what you believe to be the correct source, always look for a public verification key and then install it.

      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:
      Accept-Ranges: bytes
      Date: Mon, 08 Jul 2002 07:01:41 GMT
      Content-Length: 7286
      Content-Type: text/plain
      Server: Netscape-Enterprise/3.6 SP3
      Etag: "ea810-1c76-3d20f5eb"
      Last-modified: Tue, 02 Jul 2002 00:38:03 GMT
      Via: 1.1 netcache04 (NetCache NetApp/5.2R1D8)
      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 [circlemud.org] 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.)

  • Right... (Score:2, Insightful)

    by Clue4All ( 580842 )
    Well, one workaround for this particular exploit is to not share a LAN with someone who would do that sort of thing.

    You mean like the thousands of users on my cable network that I share a DNS server with? I'm not sure I trust them too much, but I can't really do much about that.
    • I'm just glad I can trust all these students here at the college.

      I often ask myself why I want to work at a college when the students are so good at hosing systems. I'm glad I don't deal with them more often than I do.

      Most of the students who are supposed to know about this kind of stuff don't (there are exceptions) and the ones who shouldn't know it do.

      I need to figure out who is upstream a little better.

  • Not Sharing a LAN? (Score:3, Funny)

    by Jeremiah Cornelius ( 137 ) on Monday July 08, 2002 @02:38PM (#3844170) Homepage Journal
    I guess Pudge's "Not sharing a LAN with someone who'd do that was meant to be enclosed in tags!
    <sarcasm>
    Well, one workaround for this particular exploit is to not share a LAN with someone who would do that sort of thing.
    </sarcasm>

    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?

  • "Easy" solution (Score:3, Interesting)

    by bnenning ( 58349 ) on Monday July 08, 2002 @04:27PM (#3844997)
    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.

  • Looks bad. How rapid a response? (Score:3, Interesting)

    by feldsteins ( 313201 ) <scott @ s c ottfeldstein.net> on Monday July 08, 2002 @07:24PM (#3846099) Homepage
    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.

  • No easy fixes... (Score:2, Insightful)

    by MacDork ( 560499 )

    This is an old trick. Remember the stink raised recently about users 'uncapping' their cable modems? Same idea. It's a problem here primarily because the install runs as root.

    The solution is a bit hairy though. Let's say Apple builds authentication into the "SoftwareUpdate" mechanism. That doesn't stop someone from spoofing a third party software updating mechanism. It also doesn't stop someone from writing malicious software that poses as shareware. I downloaded a shareware app last week that asked for Admin privileges just so the installer could drop the application in /Applications.

    And should Apple build authentication into the installer process from the ground up, everyone will be wringing their hands with concerns about how Apple selects who gets signed. It will strongly resemble the code signing thing Microsoft said it would start doing in future versions of Windows. (Though, I'm more apt to trust Apple to 'do the right thing' when it comes to *not* stifling the competition.)

    Even then, a malicious code writer could craft an install process that 'looks' like Apple's long enough to get a password and then pipe it to sudo with something like java.lang.Runtime.exec(). Anybody that thinks Apple should/will have a solution to this problem in a few days really ought to rethink the problem a bit. It has as much to do with educating end users about code signing, security, privileges, and encryption as it does with any software fix Apple finally does produce.

    The irony here is this isn't a problem until an end user enters a password and clicks "OK". It isn't automatic like some javascript launched Outlook attachment. Whoever posted this 'testing' software could have done the same with Windows, or one of a thousand other auto-updating programs on the net, but chose Apple. Why? In my estimation he is tired about hearing how secure and virus free Macs are.

    • And should Apple build authentication into the installer process from the ground up, everyone will be wringing their hands with concerns about how Apple selects who gets signed.

      I doubt it, since Software Update is only used to update Mac OS itself.

      It will strongly resemble the code signing thing Microsoft said it would start doing in future versions of Windows.

      Not really, since MS is talking about requiring code to be signed, while we're talking about having Apple sign updates for their own software. Debian signs their updates, right? Does that make them evil, too?
    • "Anybody that thinks Apple should/will have a solution to this problem in a few days really ought to rethink the problem a bit."

      It is entirely possible on the other hand that they have been addressing this issue for the last several months while developing OS X 10.2 and that the fix is right around the corner. Maybe not a few days but within a few weeks is reasonable. Especially as they are looking for high marks from the government regarding security.

  • No workaround my @$$ (Score:4, Informative)

    by red5 ( 51324 ) <gired5&gmail,com> on Monday July 08, 2002 @08:13PM (#3846308) Homepage Journal
    There is a very simple workaround. Just add the following line to your /etc/hosts

    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 /etc/hosts file but, I'm pretty sure that you people (/.ers) know how to do this already.

    • The NetInfo method (Score:4, Informative)

      by Slur ( 61510 ) on Monday July 08, 2002 @08:29PM (#3846376) Homepage Journal
      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:

      sudo niload hosts / /etc/hosts
    • That's a nifty 'solution' but it doesn't prevent someone from spoofing the traffic from that particular IP address. So someone could pretend to be 204.179.120.93
      • I never said it was a "'solution'" I said it was a workaround. If they could do all that they could easly spoof off Verisign and then HTTPS is fucked also. So whats your point?
        • My original post was taken the wrong way.

          It was not an attack on your idea, sir.

          I was merely pointing out to others who may have interpreted it as a solution and felt they were safe that this did not eliminate the vulnerability.

          --jquirke
          • I wasn't affeneded at all. Not quite sure what made you think that. Perhaps it's the '!' in the subject line.

            Wow, getting called "sir" I feel all giddy now. :)

            And yes you're right it wont be fully secure till they have cripto singned updates.
        • Actually you're mistaken.

          To spoof verisign and https it would require that you have a valid cert(yes it is possible to make them).To spoof a connection that used a false cert would alert the user to that fact. The fact of the matter is that apple swupdate doesnt even use SSL! So it doesn't matter if you can spoof SSL. This is why redhat up2date uses gpg, because if it is spoofed, they cant SIGN the packages! AND YOU KNOW YOU HAVE BEEN HACKED! Because you can't prevent the hack with the way the internet works! You can detect if the programmers who made the system are semi security minded.

          Apple is not that.
          • To spoof verisign and https it would require that you have a valid cert(yes it is possible to make them).To spoof a connection that used a false cert would alert the user to that fact. The fact of the matter is that apple swupdate doesn't even use SSL! So it doesn't matter if you can spoof SSL.

            The story says that the vulnerable is because apple uses http and not https. My point was that if you can spoof IPs you cloud easly spoof both the https server IP and the signing authorities IP. Thus bypassing any https connection. Unless public keys for all the signing authorities are included with every https implementation.

            Anyhow it's a workaround. It workaround this exploit. Hopefully apple will update software update to use crypto signed packages and SSL connections. Till then I'm keeping the line in my /etc/hosts and checking every update first.
      • I think the point was that it made things a lot harder. DNS servers are relatively easy to hack, compared to spoofing someone else's IP address.

        Obviously the workaround isn't perfect. What if apple changes the IP of their update server? What if they use akamai to host the updates, and the IP that was posted is actually some server halfway around the globe from you?

        It's not perfect, but give the man some credit for being creative, will ya? :)
    • There is a very simple workaround. Just add the following line to your /etc/hosts
      204.179.120.93 swquery.apple.com

      Oh, sure, and we're just supposed to trust that your DNS hasn't already been poisoned? :)

    • Why not just do it in NetInfo?

      1) open it up /Applications/Utilities/NetInfo Manager
      2) click the lock to authenticate.
      3) use the browser to go to /machines/
      4) click the "Create New Directory" button.
      5) modify the new directory you just made to have these attributes:
      key:ip_address value:204.179.120.93
      key:name value:swquery.apple.com
      key:serves value:./local
      6) save the modified netinfo database. it will ask you if you "REALLY" want to do it. if you're sure, agree.

    • As I posted on Bugtraq, no, that doesn't fix shit. Because I just arp flood your router, spoof the IP address, and you lose.

      Updates must be at least checksummed and really should also be cryptographically signed. Period.
  • Remind me why Microsoft's system ISN'T vulnerable to this?? If anything, it's more vulnerable, because a) people know about it and b) it's statistically certain there are exploitable holes in the update code.

  • Bug Fix (Score:2, Funny)

    by cappadocius ( 555740 )
    Luckily there's a bug fix! Just go to Software Update right now to get it.

    Oh, but only if you're on my campus network.

  • and one serious screw up of a installation app....is that the best you can muster after a year?

    Keep going, Apple. Maybe someday you'll be taken seriously as a operating system company and have thousands.

    Or at LEAST ship with one hole that you know about with Jagwire... that would probably jump start your reputation.
  • I'm not an expert on these things...
    (I know - then get off'a /. !!! )

    ...but could someone tell me why in an otherwise pretty secure and tight implementation of the rollout of OSX over the past 1+ year would Apple overlook something so seemingly obvious?

    Any theories (besides the one I read elsewhere that "steve was fresh from graduation from assclown school" -Techfocus)?

    And what's an assclown? I can't recall seeing one.

  • The vulnerability discussed above has now been addressed by an from Apple [apple.com]. I would say pretty fast work--the exploit page on /. is still available for posts when the patch is released. Also, as other posters have mentioned, a number of updaters from other vendors still don't sign their updates.

    It's clear that Apple has a security focus now--although they may not always get it right out of the box, they have responded quickly to the last 3 major holes, patching the system in days, not weeks.

Slashdot Top Deals

White dwarf seeks red giant for binary relationship.

Close