Security Update 2003-08-14 Released

Delta-9 writes "Today, Apple released Security Update 2003-08-14, which 'addresses a potential vulnerability in the fb_realpath() function which could allow a local or remote user to gain unauthorized root privileges to a system.'" It's on Software Update, and will likely soon appear on the support downloads page.

Comments

Good work Apple

[wyvern5]

Nice to see Apple is responding more quickly to security problems. I didn't even hear about this through my regular channels until after I had seen the update in Software Update.

Some info about the vulnerability

[remahl]

The security update addresses the following vulnerability: http://isec.pl/vulnerabilities/isec-0011-wu-ftpd.t xt Users who haven't activated the FTP server in the Sharing preference pane should not be vulnerable in any way to this bug. Furthermore, FTP servers running with anonymous access, aren't vulnerable either (unless anonymous write access is enabled), since the overflow exploit requires creating deep hierarchies of directories. Only users with regular accounts on the machine can use this bug to gain more privileges on the machine. The advisory claims to have successfully exploited the problem on several Linux i386 platforms, but they "believe that exploitation of other little-endian systems is also possible". Note "litle-endian". This may suggest that the bug is not exploitable in a useful way on big-endian machines (like all Mac's, for example). Or it may simply suggest that they haven't investigated the matter thoroughly on big-endian processors. The advisory was posted some full two weeks ago, meaning that Apple was not as quick to respond as they normally are. Perhaps they were a bit too involved in Panther right now, and had to let this relatively minor insecurity wait a little while.

Re:Some info about the vulnerability

[Anonymous Coward]

The FTP server included with Jaguar and Panther is lukemftpd, not wu-ftpd.

But that's okay. Don't let the facts get in the way of your skreed. Carry on.

Re:Some info about the vulnerability

[Klaruz]

No, apple didn't use wu-ftpd, give them some credit, they used lukemftpd. Originally from netbsd I believe.

The realpath() function from bsd calculates the length of a resolved directory path. The problem is an off by one error. It actually affects more than than just an ftp deamon since it's a library function, just like the gzip vulnerabilty a while ago. See the sans report for more info.

3 days from disclosure to security update is pretty good though.

Re:Some info about the vulnerability

[Klaruz]

Anything but wu-ftp. I like pure ftpd, YMMV.

However, if you use os x just stick with the stock ftpd since it's not wu-ftp. Like I said earlier, the bug wasn't with the ftpd, it was a library call. Just run software update and get on with your life.

Re:Some info about the vulnerability

[zpok]

The advisory was posted some full two weeks ago, meaning that Apple was not as quick to respond as they normally are.

The East Coast has reverted to the stone age, my Windows machine is insulting me, but there's Apple with another Security Update for a *potential* weakness...

Damn, you've got to admire their timing ;-)

Ok, people. I'm really sorry.

[remahl]

It looks like I jumped the gun on this...On several levels...

First, wu-ftpd is not the ftp server in Mac OS X. lukemftpd is.

Second, the most relevant advisory is not the quoted one, but this one (which previously appeared on Slashdot): FreeBSD-SA-03:08.realpath.

As the name implies, the bug originates from FreeBSD, and potentially leaves a long list of programs vulnerable (listed in the advisory).

This means that the problem is broader than my original message anticipated. It means that other remote services may be vulnerable, including sftp.

Thanks to the anonymous user who brought my attention to my (pretty bad) mistake.

Please spread this information instead of the wrongful information in the parent post. Mod parent down.

Odd Side Effect?!

[juniormaj]

I've posted this elsewhere, also. I know this seems odd, but imagine my surprise. In my home/Documents folder I have a subfolder named "Unstuffed". I have dircted Stuffit to place all of its results in this folder. It's been there for over a year. After running todays security update the subfolder was renamed "Documents", and a file called "Documents.1" was created in the original "Documents" folder. So now, in my home/Documents folder I have a subfolder called "Documents" (with the contents of the old "Unstuffed" folder) and a strange zero k file called "Documents.1". Never seen that happen before.

OSX 10.1.5?

[HSpirit]

My reading of the issue on the FreeBSD advisory is that it is likely 10.1.x is affected by this too.

Can anyone confirm?

Is a fix from Apple likely? I would find it very disappointing if Apple have stopped issuing security fixes for this OS - even Microsoft support their previous generation products (Windows 2000 Professional, for example).

If not, given this affects the (open-source) Darwin core of the OS, is a patch to the affected library/ies a possibility?

Reboot Reqired (sigh)

[Jeremy Erwin]

Another update, another reboot. Sigh.. When is Apple going to stop requiring reboots?
And they do require them,as I discovered last night. I wanted to install 10.2.0 on another machine. Rather than try to download a whopping 100Megs of updates, I would use the 6 mini updates I already had to upgrade the computer to 10.2.6. And rather than repeat the install-reboot cycle a half dozen times, I would mount the other machine as a Firewire drive on my 10.2.6 machine. No reboots required, right?

Well, half an hour later, with the 10.2.6 upgrades installed, I boot up. Nothing except a grey screen with an Apple logo. No cyclic symbol. The only way to solve the problem was to reinstall 10.2.0, and upgrade piecemeal, rebooting each time.

Re:Reboot Reqired (sigh)

[mkldev]

I tend to ignore the request to reboot and simply force-quit the installer, then continue working until it is convenient to reboot (which may or may not be that day). The only exception is when I'm installing a new device driver. To make the device driver usable, I do a "sudo kill -HUP xxx" where xxx is the PID of kextd.

In the case of a security update that changes libraries, though, it's prudent to reboot, or at least shut down any daemon processes and restart them.... Anything newly launched will be bound to the new library, but anything already running will continue using the old one, hence any program that uses the buggy function needs to be restarted. A reboot is certainly the easiest way. :-)