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

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

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.

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

[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