Mac OS X 10.3.4 Released

sizemoresr writes "The 10.3.4 Update delivers enhanced functionality and improved reliability for Mac OS X v10.3 'Panther' and is recommended for all users. Key enhancements include: improved file sharing and directory services for Mac (AFP), UNIX (NFS), PPTP, and wireless networks; improved OpenGL technology and updated ATI and NVIDIA graphics drivers; improved disc burning and recording functionality; iPods connected via USB 2.0 are now recognized by iTunes and iSync; additional FireWire audio and USB device compatibility; updated Address Book, Mail, Safari, Stickies, and QuickTime applications; improved compatibility for third party applications; previous standalone security updates."

Comments

No fix on recent exploits

[jeffasselin]

From what I could see by carefully reading the technical info on it, it doesn't appear to fix the recently discovered protocol handler exploits, apart from the earlier fix for the help: exploit (which doesn't appear to cure ALL help: exploits).

These exploits are serious, and will require a significant overhaul of the protocol handler code as well as a possible revision on the handling of downloadable disc images in Safari (which is a factor in many of the exploits). Yes, they could have waited, but if 10.3.4 was already ready, I'd prefer for Apple to release it on time and give us the fixes they can right now, and then work on the recent problems to provide us a good security patch (or maybe a 10.3.5) when they've fixed it.

Re:No fix on recent exploits

[ghutchis]

No, I've upgraded and can confirm it does not fix any exploits that were not fixed by the recent security update patch (i.e., only the help/runscript exploit).

I'd agree that a careful overhaul is needed to properly fix these exploits. But the clock is ticking on the exploit problem!

-Geoff

Re:No fix on recent exploits

[pediddle]

Wrong, it can be done with autorefreshes, and the articles linked from both (three?) of the recent Slashdot articles prove it. In the latest version, the downloaded .img file doesn't even show up in Safari's download window, so you don't even know it's happening!

Try it, the proof of concept hack does just this.

Re:No fix on recent exploits

[spitzak]

Nonsense. I tried the exploit and it worked. Visiting a web page popped up the finder where it displayed an ftp site, and it then ran a command off this site. It did this all without any intervention of mine except for the initial click to go to that web page. If I clicked and then walked away I would not even see the finder pop up, and I'm not sure if I could have killed it even if I did see the finder. This is a nasty and serious exploit and your denying it is not going to make it go away.

It sounds like the problem is that programs can register as "protocol handlers" and this is done automatically when the finder sees the file. On Windows (and I guess on Linux) this is done only if you actually run a program (and if a web page could cause a program to be run you have a much more direct exploit).

It does seem this could be fixed by not installing any handlers until the program is first run. Not sure how hard this is to do or why Apple has not done it yet. It sould also be the responsibility of anybody doing a protocol handler to not do anything dangerous no matter what command line arguments are passed (perhaps url's should add "--" before any arguments so that switches are never passed, any switches should be done by making different protocol handler names).

Re:No fix on recent exploits

[MonkeyBoy]

From the front page of [url=http://www.macintouch.com]Macintouch[/url] today:

The solution I came up with seems to work perfectly so far, only takes a few seconds to implement, and doesn't require installing any third-party software as other solutions I've seen do:

Go to /Applications/Firefox.app/Contents/MacOS/chrome
O pen all.js in any text editor, though preferably vim. :)
Search for the term "protocol-handler".
Under the two lines addressing "mailto" and "news", add the following lines of code:
pref("network.protocol-handler.external.hel p" , false); // disable help protocol
pref("network.protocol-handler.external. disk" , false); // disable disk protocol

Restart Firefox.

Thanks!

[Apiakun]

Ahh, thank you ssh and apple for allowing me to do this: ($:~)-> softwareupdate -i MacOSXUpdate10.3.4-10.3.4 Now my box will be nice and updated before I even leave work.

Re:Thanks!

[Guy Harris]

I'm pretty sure wake-on-lan is possible

It is - see, for example, a knowledgebase article on it - but that's "wake on magic packet" (or Magic Packet(TM)) wake-on-LAN, not the more general packet matching wakeup that some network interfaces support.

I.e., the machine won't automatically wake up when you try to ssh into it; you need to send it a Magic Packet(TM) to wake it up. A packet-matching wakeup might be able to match incoming unicast packets to the machine, broadcast ARP requests asking for the MAC address corresponding to the machine's IP address, and other packets that it would need to respond to, so that attempting to ssh into it would wake it up, without making it respond to various random broadcasts and multicasts for which it wouldn't have to wake up (e.g., a broadcast ARP request for somebody else's MAC address, assuming it doesn't have to reply to that for e.g. proxy ARP purposes).

However, wake-on-Magic-Packet(TM) might be sufficient for the purposes of the person to whom you responded; I think one purpose for which it was intended was to allow administrators to wake up sleeping machines in order to do various remote administrative operations - including the remote software updates that they wanted to do.

Re:Thanks!

[mdray]

Yes, wake on magic packet works. I have my ADSL router set up to forward traffic destined for 9/UDP ('discard' port) on the ADSL interface to be sent to the broadcast address (where my Mac will see it) on my LAN.

I then use wakeonlan (perl script) to send a magic packet to the router from the internet, which wakes the Mac up. After this I can ssh in to my Mac (port forward for SSH configured on the ADSL router).

The only problem is that I only get 30 seconds of connectivity before my Mac goes back to sleep. I think this is the amount of time the machine waits for me to type my password on the console, as if I'd woken it up by clicking the mouse. Does anyone have a workaround for this? It's *REALLY* annoying :I

Re:Thanks!

[xil]

man pmset. You probably want to 'sudo pmset -a sleep 0' when you log in.

we are talking a major update here

[falcon5768]

its like 41 megs! Wonder if burning support means more supported cd-rw drives

This should help.

[Padrino121]

Apple's KB article on the 10.3.4 update. http://docs.info.apple.com/article.html?artnum=257 64

Re:Hopefully it fixes the recent exploits

[MisterSquid]

However, I wish Apple would provide more information on their updates.

Apple always provides complete information about their updates in the Apple Knowledgebase. The information for the 10.3.4 update is here.

URL Handler Exploits appear to be fixed...

[EverLurking]

Well, rebooted just fine. No issues yet. Browsing and E-mail working well, grabbed my home Wireless 802.11b/g with WPA just fine, if anything, reception is LESS flaky now (fewer dropouts seen on AP Grapher and fewer random loss of connectivity).

Doesn't seem any slower or faster.

Most importantly, it looks like some of the URI handler problems/security holes are now patched as well. I had uninstalled the "Paranoid Android" Haxie before the update (to make sure there weren't any install issues) so it was no longer running.

It looks like none of these exploits seem to work any more after the 10.3.4 update.

Nice work,

DaveC

Re:URL Handler Exploits appear to be fixed...

[EverLurking]

The remote disk image mounts and I can see the AppleScript MalWare program, but it doesn't execute on its own. This is without any protective measures taken (no redefinition of URL Handlers and no 3rd prarty protective programs).

I was able to run the applescript manually by clicking on it and it brought the "you have been owned" dialogue box, then when you click on the OK button it exits and dismounts the image automatically. So I know I waited long enough for everything to download. Heck I waited like 5 minutes incase of delayed execution. Nope, the hole is closed for me.

Note, stopping the execution of the remotely mounted program WON'T protect the user from his stupid self if he/she blindly executes unknown programs/scripts downloaded indiscriminately from the internet, but then again, nothing can protect a dumb ass from themselves.

Caveat Emptor,

DaveC

Re:URL Handler Exploits appear to be fixed...

[pudge]

I just ran the Paranoid Android example exploit on a basically unmodified Mac OS X 10.3.4 user account, with no extras or RCDefaultApp or changed settings etc., and it ran just fine. The hole is still there. The "you have been owned" dialogue came up without any interaction from me.

Re:URL Handler Exploits appear to be fixed...

[EverLurking]

Yes they did work pre 10.3.4, that's what prompted me to use Paranoid Android. I had uninstalled Paranoid Android before updating to 10.3.4

Again, I've tried all four links and none autoexecute, they just bring up the remote .dmg or ftp folder with the example code in them. NONE of these programs executed for me.

Is this some residual side effect of having had Paranoid Android on my computer? (ie. are there lasting changes despite having it uninstalled that keeps these programs from running? Paranoid Android used to bring up a confirmation dialog when I clicked on the "Open Energy Saver..." menu option of my Menu Bar Battery Icon asking if it was ok for a URL type file to be executed with System Preferences. Now that it's uninstalled, it no longer does that so I KNOW Paranoid Android is now completely gone, even went into /Library and delete the Haxie PreferencePane.) A few others have reported that the URL Handler exploit doesn't work anymore after the update.

I did NOT previously modify any URI Handlers by hand nor did I delete any applications prior to this update. If being protected is an isolated effect, I'm glad I got lucky I guess.

DaveC

Re:URL Handler Exploits appear to be fixed...

[cft_128]

On my 'virgin' 10.3.3 machine unchecking "Open Safe files after downloading" in Safari preferences stops at least this exploit. No matter what it mounts the image, but with "Open Safe files after downloading" unchecked it will not run the script that is in the image.

Exploits are Fixed

[EverLurking]

If you try the various example exploit links, you will find that while the remote disk images/ftp servers do mount, none of the ssh, applescript or other commands on them are executed. Thus the URL Handler exploit hole appears for now appears to be a non-issue while retaining the convenience of being able to mount remote files/disk images.

See this post for the links to the exploit examples I tested against. (I had not modified any of my URL handlers at all, and had already uninstalled "Paranoid Android" prior to updating so my system was unprotected from the old URL exploits).

While the immediate danger seems to be gone, the halcyon days of being a OS X User seem to be gone now that we have the attention of the various asshole hacker/script-kiddies out there. Just a matter of time before some other hole is found (but it is inevitable with any software as complex and interoperable as an Operating System).

Still, I'll take my chances with OS X over Windows ANY day.

Re:Cummulative update skip earlier files?

[Anonymous Coward]

Does this update skip updates that were already released, downloaded and installed?

The 41MB one contains only the 10.3.3->10.3.4 update, and security patches in between there. There's also a combo version (80MB+ for 10.3.0 -> 10.3.4) which contains all the other updates & security fixes also.

If you're up to date with 10.3.3 + security patches then most of that 41MB is the new update.

ALL exploits still work under 10.3.4

[daveschroeder]

I've put up a test page at http://test.doit.wisc.edu/, and the exploit still works via afp, ftp, disk, and downloadable file in the default configuration of Mac OS X 10.3.4.

To protect yourself, you still MUST:

- disable "open safe files after download" in Safari

- disable the following protocols (or reassign to a helper other than Finder):

afp
ftp
disk
disks

and additionally:

telnet
ssh

and/or install Paranoid Android

Hopefully Apple will find a reasonable resolution for this soon.

Re:ALL exploits still work under 10.3.4

[EverLurking]

Tried all those links, none auto execute the programs on the auto-mounted directories. Beginning to think this is a residual effect of having had Paranoid Android on my system.

DaveC

Re:ALL exploits still work under 10.3.4

[EverLurking]

Yup, just did each and every one of them, twice even (reload button) after 1-2 minutes, the disk/remote file may have mounted but the program never executes on its own.

Hmmmm....Since I can't try it now, someone who has these a system where these exploits work, try installing Paranoid Android 1.2 (though under 10.3.3 I had at initially installed P.A. 1.0, then upgraded to 1.1 then 1.2 as each release came out), then verify that it works and pops up the appropriate warning dialogue. Then, uninstall Paranoid Android and see if these exploits work anymore.

Honest, I'm not getting any more response to ANY of the exploit links beyond mounting of images/directories. Some one help me verify this before I start doubting my own eyes. I suppose I could try a reboot and see if the vulnerability comes back, but then again, I'm protected now (somehow!!! and yet URL Handlers locally still work, it'd be good to be able to reproduce this) and why screw with a good thing?

DaveC

Re:ALL exploits still work under 10.3.4

[93 Escort Wagon]

RCDefaultApp is a simpler way to take care of this. It installs as a Preference Pane, and lets you assign default handlers to (or unassociate completely) the various protocols like afp:, disk:, etc.

As a bonus you can use it to change your default browser without first having to launch Safari. :-)

Re:Safari is way faster

[pualo]

This change is not present in the 10.3.4 version of Safari. Dave Hyatt writes in the comments to his blog:

It's a placebo. The Safari in 10.3.4 contains only a handful of fixes and is no faster than previous versions.

He also later writes/;

I suppose something could have made it faster. In our internal tests it's no faster. As far as WebCore code, there are a slew of bugs fixes, but those are mostly for the regressions from 1.1.

I was being protected by Privoxy!!!

[EverLurking]

I finally figured out why I wasn't getting hit by the sample exploit code when others were. It was Privoxy preventing auto-refreshes that executed the code after mounting the image. Not a bad side effect really. I must have had Privoxy Disabled when I was testing the exploits out on 10.3.3

OK, so my setup is apparently somewhat resistant for now, not bullet proof but nice to know: 10.3.4, disabled the "Open Safe files" option, running Privoxy (which is set to default actions)

The help viewer URL problem is apparently patched and so is the SSL hole (according to another post on this page) so that is a comfort. Not the cleanest fix but in my case it works well.

Sorry for the wild goosechase or if I mislead anyone into thinking the problem had completely disappeared. On first inspection, it REALLY did seem to me that I wasn't vulnerable...well I wasn't, but no thanks to Apple.

DaveC

Re:the _real_ question is......

[chrismear]

I know the comment was a joke, but in case anyone's interested, the update apparently fixes an issue where the Stickies app would access the hard drive every five minutes, even when idle.

X11

[pr0nbot]

With multiple monitors, X11 applications now seem to start in the primary monitor rather than in the leftmost monitor.

Re:Questions for Xserve running 10.3.3 Server

[for_usenet]

There are separate releases of the 10.3.4 update for BOTH the client and server versions of X 10.3. SoftwareUpdate should take care of this "automagically" for you.

As for importance in a production environment, I would guess this set of patches/updates coming up are VERY important because of the holes in the operating system - leaving those unpatched leaves your entire network at risk. Best to depoly the patches on a test machine, and once everything checks out - deploy to all machines on the network that need it.

I have not had any experience with the server versions of OS X, but in my experience with the client versions, System settings ARE preserved (i.e. not over-written) with updates like this.

HTH

Re:anacron-like update?

[c13v3rm0nk3y]

I'd assume that this issue addresses the various OS X schedules, and not the Darwin cron daemon. The cron daemon is what drives the periodics scripts.

From a look at the Archive.bom file, cron was not touched in this update.

Of course, it's possible that Apple has some OS X specific hack around the cron way of doing things that was fixed in one of the other many files that this update affected.

I see no evidence to suggest this, however.