Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
OS X Operating Systems Bug Security

Apple Releases Mac OS X Patches 84

phoric writes "According to eWeek, Apple has released security patches to fix 16 'highly critical' holes, one-third of which deal with the open-source Apache web server. Several of the fixes address exploits such as the bypassing of security restrictions, spoofing, and potential DoS attacks."
This discussion has been archived. No new comments can be posted.

Apple Releases Mac OS X Patches

Comments Filter:
  • by TFGeditor ( 737839 ) on Friday December 03, 2004 @04:09PM (#10990565) Homepage
    Seems odd. Is anyone aware of any malware that takes advantage of the exploits?
  • Cool! (Score:5, Funny)

    by wizbit ( 122290 ) on Friday December 03, 2004 @04:17PM (#10990681)
    Apple has released security patches to fix 16 'highly critical' holes, one-third of which deal with the open-source Apache web server


    I've never used Software Update to apply 5.333 fixes before. This should be fun.
  • by the pickle ( 261584 ) on Friday December 03, 2004 @04:22PM (#10990733) Homepage
    ...how many of these holes had exploits in the wild?

    0 / 16.

    Every last one of them was -- and still is -- theoretical.

    Do what you have to do in the name of "balanced reporting," though, eWeek.

    p
    • by Anonymous Coward
      Every last one of them was -- and still is -- theoretical

      Yep... as far as you know.

    • by Sancho ( 17056 ) on Friday December 03, 2004 @04:56PM (#10991130) Homepage
      It's a nice contrast to Microsoft, who has allegedly known about security bugs and waited until there were out-of-control exploits before issuing fixes.
    • by 99BottlesOfBeerInMyF ( 813746 ) on Friday December 03, 2004 @05:05PM (#10991258)

      Every last one of them was -- and still is -- theoretical.

      Well, not quite. The second Safari fix had a demo exploit published. I never got it to work on my system, but several people reported it working for them. (This was a pretty minor issue possibly tricking someone into thinking a pop-up was opened by another window). As for the other exploits, I don't know of any being leveraged either by a hacker or a worm, but that does not mean they were not found by anyone. The tiff and postscript overflows, for example, are not too different from exploits on windows and someone may have been using them.

      This patch encompasses about 5 possible remote code executions most of which were discovered by the open source community or by security firms. I find it encouraging that Apple is able to leverage the OS community to help secure their system, but it seems like Apple would benefit from some more thorough security reviews internally.

      Please note, I am not trying to pick on OSX here. OSX has an excellent security record, and I would trust it more than Windows or the average Linux distribution at this point. Eweek's coverage was not too bad, they mentioned them as potential vulnerabilities. I could have done without Secunia's 2 cents, and it might have been nice if they had emphasized that even with these vulnerabilities unpatched, there is little practical danger to the average user. All in all though, I did not think the article was too bad.

      • The second Safari fix had a demo exploit published. I never got it to work on my system, but several people reported it working for them. Well, I hope you called 800-SOS-APPL to see if they could help you get your machine exploited, too.
    • by Anonymous Coward on Friday December 03, 2004 @05:36PM (#10991595)
      Oh yeah? Here's an exploit in the wild, created just now: http://macslash.org/comments.pl/..namedfork/data [macslash.org]

      That's one serious hole. Hope they upgrade soon.
      • And that's OS X's fault how, exactly?

        Looks more like a vulnerability in Slashcode to me...

        p
        • by Anonymous Coward on Friday December 03, 2004 @08:18PM (#10993193)
          No, it has nothing to do with Slashcode. That exploit works regardless of what scripts you're running, and it also works to access files that are otherwise restricted. There are two reasons it's OS X's fault:

          First, Apple provides the faulty default Apache configuration that doesn't secure against this attack. No web admin should have to know intricate details of the operating system's file system to think up every single possible exploit that could come about due to idiosyncrasies in that particular system.

          Two, they put in that nonstandard behavior in the first place. This is the kind of thing that gets Slashdot up in arms about Microsoft all the time. We feel all smug that OUR systems don't have all these extra features with no thoughts to security. Well, Apple added an extra feature for HFS+ to access a file's data and resource forks through ..namedfork/data and ..namedfork/rsrc. No other system does this, and Apache certainly shouldn't have to have special code to check for it. The burden falls on Apple to make sure that their supplied tools and configurations take care of any possible security risks due to features such as this.

          It's not surprising that it took someone this long to discover the hole, and it's been there all along. How many other applications might be out there that restrict access to files based on name, but would be fooled by using the ..namedfork/data extension? I wouldn't be surprised if there are more out there. Since this isn't a standard Unix/POSIX behavior, the burden falls squarely on Apple.

          I really hope that everyone running an OS X web server runs this update quickly. Otherwise attackers will be able to read their scripts and other sensitive date - which they thought was blocked - and scrutinize it for bigger holes to truly exploit the systems. Yikes.

          More info here [apple.com].
          • are you sure that apache actually has special code to check for it, and that it's not something that's exposed at the standard library level?
          • There are two reasons it's OS X's fault:

            First, Apple provides the faulty default Apache configuration that doesn't secure against this attack. No web admin should have to know intricate details of the operating system's file system to think up every single possible exploit that could come about due to idiosyncrasies in that particular system.

            Two, they put in that nonstandard behavior in the first place.

            All true.

            Still, there's more blame to spread. "allow all, but these that we explicitly

        • by justMichael ( 606509 ) on Friday December 03, 2004 @11:52PM (#10994389) Homepage
          And that's OS X's fault how, exactly?

          Looks more like a vulnerability in Slashcode to me...
          Yeah, that was my first thought, then I tried it on my PowerBook which I use for development. It works on any file found under docroot, including .htaccess and it doesn't have to be the OS X install of Apache, I build my own and it works.

          I'll provide the link that the very helpful AC posted below [slashdot.org] in case it doesn't get modded up as I think people should see it.

          More info here [apple.com].
      • That doesn't work on slashdot, fyi
    • by Anonymous Coward
      Disagree... the Apache bugs are not hypothetical. Computerworld has a better writeup here: http://www.computerworld.com/securitytopics/securi ty/story/0,10801,98038,00.html
    • Every last one of them was -- and still is -- theoretical.

      So would you sooner have them wait until there are threats in the wild? I would call this rather proactive.
      Of course if you use your own compiled version of apache and are on top of it then you've probably patched these hole a long time ago.
  • by cuijian ( 110696 ) * on Friday December 03, 2004 @04:30PM (#10990833)
    Apple fixed a URL spoofing vulnerability in Safari with this release. (The URL shown in the status bar when you click on a link was not necessarily where you were going to be taken)

    Just today, a MSFT IE secutity tester posted an entry on the IE Blog that dismisses the vulnerabilty. He feels that allowing web sites to display arbitrary text on the status bar is a feature and that users need to learn that they can only trust the address bar URL field, and the lock icon in the status bar. IE users need to know that "the status bar text is not helpful in making trust decisions."

    I'm amazed that is the mindset of an security tester and even more amazed that he feels comfortable posting that viewpoint publicly on the IE blog. No wonder they have so many security problems!

    Here is the link to the blog:
    http://blogs.msdn.com/ie/archive/2004/12/03 /274330 .aspx
    • by MarkGriz ( 520778 ) on Friday December 03, 2004 @04:57PM (#10991135)
      I'm amazed that is the mindset of an security tester and even more amazed that he feels comfortable posting that viewpoint publicly on the IE blog. No wonder they have so many security problems!

      This amazes you?
      On the one hand, you have Apple fixing potentially exploitable holes.
      One the other hand, Microsoft regularly downplays holes with "Mitigating Factors"

      Nope, seems like business as usual to me.
    • "He feels that allowing web sites to display arbitrary text on the status bar is a feature"

      It is and it has been for quite some time. It's part of every major browser.

      It's really *not a vulnerability* at all. Anyone who doesn't examine the address bar before entering personal information is going to get duped *anyway*.

      It is no more a flaw than the alert() function. In a loop, the alert() function allows pages to prevent the browser from recieving input.

      Should we disable that too?

      What about a link that
      • I disagree.

        To the average user, there is a world of diference between what is displayed as part of the browser UI and the contents of a web page.

        When I go to nytimes.com it is clear to me and the average user that the browser vendor is not responsible for the content of the page.

        However, the average user does not expect that the web page has direct control over the browsers UI. When the browser puts up a lock icon indicating that the page is secure, we hold the browser responsible for making sure the pag
        • I think that your giving a little too much credit to the average user. Actually far too much credit. To the average user, there is no difference between whats displayed on a page, in a popup or as part of a window. Thats why those "YOUR COMPUTER IS BROADCASTING ITS IP" popups work so well, the average user has no idea how to tell that its a valid OS message or just some stupid popup.

          It was originally intended to be a feture, just some people chose to use it to cause problems. Then again, some people choose
          • It's possible that the average user has even more clueless than I estimate but that would only strengthen my arguement that browser manufacturers should go out of their way to protect the user.

            If something that was originally intendend to be a feature ends up a security risk and does not actually provide user benefit then that "feature" should be gotten rid of.

            I'm not arguing that we get rid of Linux or other things of value. I'm not claiming that we should all unplug from the net and hide in a closet.
      • by Anonymous Coward

        "I'm amazed that you find this an issue AT ALL. It IS NOT a security flaw."

        That would be true it it was called the arbitray text bar, but it isn't, it is the status bar, it should show me the URL of the link or tell me status info. Rename to the, "Whatever the fuck people want to sho up here" bar and I would not mind as much.

      • It can be a security flaw and a feature at the same time. Custom status titles are a good idea, definitely. However, when they spoof URLs, it becomes a security flaw. I haven't yet examined the fix, but hopefully Apple has eliminated the flaw in a clever way instead of eliminating the feature entirely.
    • "I'm amazed that is the mindset of an security tester and even more amazed that he feels comfortable posting that viewpoint publicly on the IE blog. No wonder they have so many security problems!"

      It's a widespread problem, this mindset, shared by lots and lots of admins, power users and people who happen to just spend too much time with their computer and thus know a teensy bit more than their neighbor...
  • by rritterson ( 588983 ) * on Friday December 03, 2004 @04:33PM (#10990867)
    FWIW, it worked great on my G5. The rest of the guys in the DSLR MUG haven't had any problem either()

    I, of course, cannot vouch for your sucess or failure, but no problems yet!
  • kudos to apple (Score:4, Insightful)

    by grocer ( 718489 ) on Friday December 03, 2004 @04:44PM (#10990982)
    ...for releasing 10.2.8 client and server patches, too...from someone waiting for Tiger.
  • by kuwan ( 443684 ) on Friday December 03, 2004 @04:50PM (#10991053) Homepage
    For more info on the update, here's the description from Software Update (click on the link at the bottom for the full Knowledge Base Article)

    Security Update 2004-12-02 delivers a number of security enhancements and is recommended for all Macintosh users. This update includes the following components:

    Apache
    AppKit
    HIToolbox
    Kerberos
    Postfix
    PS Normalizer
    Safari
    Terminal

    For detailed information on this Update, please visit this website: http://www.info.apple.com/kbnum/n61798
  • I read about this on MacSlash (I think that was yesterday) and I still don't see any updates in Software Update. Am I missing something here?
    • Re:I don't see it... (Score:2, Informative)

      by sokoban ( 142301 )
      Probably. Everyone else I've talked to says that it has shown up just fine. I think the 10.2.8 client patch came up a little late, but if you still don't see it try repairing permissions and the usual stuff. If worse comes to worst, download the patch with the standalone installer. It will be at: http://www.apple.com/downloads/macosx/

      BTW, the Mac OS X Downloads slashbox usually will show you any stand alone update and is really cool regardless.
    • I still don't see any updates in Software Update. Am I missing something here?

      I don't think it applies to System 7. :)

      Seriously, I wouldn't expect to see it applied to OS <=10.1

    • Not necessarily - nothing popped up on My Software Update (despite repeated checking) until about 8pm last night. I'm based in the UK.
  • Snappier! (Score:2, Funny)

    by patrick42 ( 212568 )
    Is it just me, or does this release make the whole OS seem snappier? Great jaerb, Apple! :)
    • by 42 ( 31931 )
      Maybe it is just because you rebooted! ;)
      • What are you, some sort of PC user? Reboots only make a difference on Windows!
    • by Anonymous Coward
      That's because one of the patches was to update the Job's Reality Distortion Field built into all Apple products.

      Previously, it would deactivate the first time the computer went to sleep mode, and wouldn't come back on waking.

      Now we all get constant Reality Distortion - just the way we like it!

      (Disclaimer: I own an iBook so I'm allowed to ridicule it.)
  • by Shag ( 3737 ) * on Friday December 03, 2004 @05:59PM (#10991867) Journal
    The on-duty editor didn't get my mail, I guess...

    Apple has not described these as "highly critical" to my knowledge.

    That label has been applied by Secunia [secunia.com], the Danish security company that has, in the past, gotten press for indicating that Windows is secure and OS X isn't [techworld.com], no matter what tests [usatoday.com] might show.

    The browser fixes are potentially significant, but the bulk of the others involve services that aren't even on by default, or things that most users wouldn't deal with.

    Sky falling, next 10 miles.

  • Error? (Score:4, Interesting)

    by azav ( 469988 ) on Friday December 03, 2004 @06:03PM (#10991913) Homepage Journal
    From the article:

    "Apple said the problem exists because its HFS+ file system handles file access in a case-sensitive way, while the Apache configuration blocks access in a case-sensitive way."

    Shouldn't that be case insensitive?
    • The first instance of "case-sensitive" should, indeed, read "case-insensitive."

      (The second instance of "case-sensitive" is correct as written.)
    • Re:Error? (Score:2, Funny)

      by cookd ( 72933 )
      Are you some kind of insensitive clod or something? :)
  • by madsenj37 ( 612413 ) on Friday December 03, 2004 @07:43PM (#10992895)
    Always remember to repair permissions first via Disk Utility. And the hard drive, if you have time.
  • Interesting note: (Score:5, Interesting)

    by ZackSchil ( 560462 ) on Saturday December 04, 2004 @05:37AM (#10995434)
    According to the details on the update, Apple patched an internal system bug that stopped other locally running programs from intercepting data entered into a secure text field. You know, the kind that shows up as dots when you write in it. Nice to see Apple protecting users from phishing spyware before it even exists in OS X.
  • by SillyWilly ( 692755 ) on Saturday December 04, 2004 @06:11AM (#10995489) Homepage
    Apple has issued a security update for Mac OS X, which fixes various vulnerabilities.

    1) A vulnerability in the Apache "mod_digest_apple" authentication can be exploited by malicious people to conduct replay attacks.

    2) Multiple vulnerabilities in Apache and mod_ssl can be exploited to inject potentially malicious characters into error logfiles, bypass certain security restrictions, gain escalated privileges, gain unauthorised access to other web sites, cause a DoS (Denial of Service), and potentially compromise a vulnerable system.

    For more information:
    SA8146
    SA10789
    SA11170
    SA11534
    S A11841
    SA12787
    SA12898

    3) A security issue in Apache results in access to ".DS_Store" files
    and files starting with ".ht" not being fully blocked. The problem is that the Apache configuration blocks access in a case sensitive way, but the Apple HFS+ filesystem performs file access in a case insensitive way.

    4) A security issue in Apache makes it possible to bypass the normal Apache file handlers and retrieve file data and resource fork content via HTTP. The problem is that the Apple HFS+ filesystem permits files to have multiple data streams.

    5) Multiple vulnerabilities in Apache2 can be exploited by malicious people to cause a DoS or potentially compromise a system, or by malicious, local users to gain escalated privileges.

    For more information:
    SA12434
    SA12540

    6) A security issue in Appkit causes secure text fields to not enable secure input correctly in some circumstances. This allows other applications in the same window session to read the entered characters.

    7) Multiple vulnerabilities in Appkit can potentially be exploited by malicious people to compromise a user's system or cause a DoS (Denial of Service).

    For more information:
    SA12818

    8) A vulnerability in Cyrus IMAP when using Kerberos authentication can be exploited by malicious, authenticated users to access other mailboxes on the system.

    9) A security issue in HIToolbox can be exploited by malicious users to quit applications in kiosk mode via a certain key combination.

    10) Multiple vulnerabilities have been reported in Kerberos, where the most serious potentially can be exploited by malicious people to compromise a vulnerable system.

    For more information:
    SA12408

    11) A vulnerability in Postfix when using CRAM-MD5 can be exploited by malicious users to send mails without being properly authenticated. The problem is that the credentials used to successfully authenticate a user can be re-used for a small time period, which can be exploited via replay attacks.

    12) A vulnerability in PSNormalizer can potentially be exploited by malicious people to compromise a user's system. The vulnerability is caused due to a boundary error when converting PostScript to PDF.

    13) A vulnerability in QuickTime Streaming Server can be exploited by malicious people to cause a DoS via a specially crafted DESCRIBE request.

    14) A weakness in Safari can be exploited by malicious people to trick users into visiting a malicious web site by obfuscating URLs.

    For more information:
    SA13047

    15) A vulnerability in Safari can be exploited by malicious web sites to spoof dialog boxes.

    For more information:
    SA12892

    16) A weakness in Terminal may result in the "Secure Keyboard Entry" menu setting erroneously looking like it is active when it's not.
  • by nordicfrost ( 118437 ) * on Saturday December 04, 2004 @10:10AM (#10995924)
    OK. This update b0rked my PowerBook up really well. Afteer an update and Repair Permissions (Always a good idea), I restarted the PB. After a seemingly normal reboot, it halted at Logon Window staring... And did not go any further.

    On Apple Discussions, arguably the best official tech solution pages from any major computer company, a possible solution has been posted.

    If the problems appear, reboot into single-user mode. Go to the /etc directory (type cd /etc and hit enter for those who seldom wander into Terminal)

    There you will find a screwed up file, 'ttys' and a backup of the same file called 'ttys.applesaved'. Overwrite the borken file by typing 'sudp cp /etc/ttys.applesaved /etc/ttys' and hit enter. Type in your admin password, hit enter. Reboot the machine, rejoice as you now get in.

    I was less fortunate, as the machine was the only ne at home so I never ot to read the advice. I did archive and reinstall, it worked surprisingly well. I have done this under Windows, and lost all settings ang programs. When the 10.3 system was in, even my desktop icons were right where I left them. I did another updated and it worked swell!
  • by HSpirit ( 519997 ) on Saturday December 04, 2004 @08:08PM (#10998691)

    Two of the vulnerabilities reported [apple.com] attempt to modify the

    /etc/httpd/httpd.conf
    configuration file used by Apache 1.3.

    Those MacOS X users (like me) who manually reconfigure their Apache configuration should note that the update (sensibly) will not modify a customised httpd.conf. If you fit into this category you should read the advice [apple.com] posted by Apple on how to manually update your httpd.conf to ensure your Apache is not serving up content which should not be available.

    • Oops... my mistake: Two of the vulnerabilities reported attempt to modify the...

      What I meant to say was: The fixes for two of the vulnerabilities reported attempt to modify the...

      My apologies...

    • Actually, as stated in the advice you linked to, "under some circumstances" it won't modify it. My http.conf is manually customized, and Software Update did actually patch it just fine (miraculously, it did so without breaking any of the customizations I did, like earlier software updates have sometimes done).

      I'm not sure what the circumstances are that prevent modification. I assume it would have something to do with whether or not you'd manually modified the specific section that contained the vulner

  • It looks like most of the Apache problems stem from Apple's own HFS+ filesystem and its lack of case-sensitive filenaming. HFS+ needs to be retired. I mean, what kind of *nix uses a default filesystem that is *not* case-sensitive? There's a myriad of worthy file systems out there (UFS being my personal favorite.) Before you Mac people flame me, I must point out that I am writing this on my iBook, which I treasure dearly.

"Show me a good loser, and I'll show you a loser." -- Vince Lombardi, football coach

Working...