Mac OS X Security update is now in your Software Update control panel:
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Security Update 2003-08-14
- Thread starter MacRumors
- Start date
- Sort by reaction score
Threat (off a linux site, but likely applies to BSD based systems as well)
Issue:
======
Wu-ftpd FTP server contains remotely exploitable off-by-one bug. A local
or remote attacker could exploit this vulnerability to gain root
privileges on a vulnerable system.
Details:
========
An off-by-one bug exists in fb_realpath() function. An overflow occurs
when the length of a constructed path is equal to the MAXPATHLEN+1
characters while the size of the buffer is MAXPATHLEN characters only.
The overflowed buffer lies on the stack.
The bug results from misuse of rootd variable in the calculation of
length of a concatenated string:
------8<------cut-here------8<------
/*
* Join the two strings together, ensuring that the right thing
* happens if the last component is empty, or the dirname is root.
*/
if (resolved[0] == '/' && resolved[1] == '\0')
rootd = 1;
else
rootd = 0;
if (*wbuf) {
if (strlen(resolved) + strlen(wbuf) + rootd + 1 > MAXPATHLEN) {
errno = ENAMETOOLONG;
goto err1;
}
if (rootd == 0)
(void) strcat(resolved, "/");
(void) strcat(resolved, wbuf);
}
------8<------cut-here------8<------
Since the path is constructed from current working directory and a file
name specified as an parameter to various FTP commands attacker needs to
create deep directory structure.
Following FTP commands may be used to cause buffer overflow:
STOR
RETR
APPE
DELE
MKD
RMD
STOU
RNTO
This bug may be non-exploitable if size of the buffer is greater than
MAXPATHLEN characters. This may occur for example if wu-ftpd is compiled
with some versions of Linux kernel where PATH_MAX (and MAXPATHLEN
accordingly) is defined to be exactly 4095 characters. In such cases,
the buffer is padded with an extra byte because of variable alignment
which is a result of code optimization.
Linux 2.2.x and some early 2.4.x kernel versions defines PATH_MAX to be
4095 characters, thus only wu-ftpd binaries compiled on 2.0.x or later 2.4.x
kernels are affected.
Exploit:
========
We investigated and successfully exploited this vulnerability on x86 based
Linux system running 2.4.19 kernel. We believe that exploitation of other
little-endian systems is also possible.
Impact:
=======
Authenticated local user or anonymous FTP user with write-access could
execute arbitrary code with root privileges.
Issue:
======
Wu-ftpd FTP server contains remotely exploitable off-by-one bug. A local
or remote attacker could exploit this vulnerability to gain root
privileges on a vulnerable system.
Details:
========
An off-by-one bug exists in fb_realpath() function. An overflow occurs
when the length of a constructed path is equal to the MAXPATHLEN+1
characters while the size of the buffer is MAXPATHLEN characters only.
The overflowed buffer lies on the stack.
The bug results from misuse of rootd variable in the calculation of
length of a concatenated string:
------8<------cut-here------8<------
/*
* Join the two strings together, ensuring that the right thing
* happens if the last component is empty, or the dirname is root.
*/
if (resolved[0] == '/' && resolved[1] == '\0')
rootd = 1;
else
rootd = 0;
if (*wbuf) {
if (strlen(resolved) + strlen(wbuf) + rootd + 1 > MAXPATHLEN) {
errno = ENAMETOOLONG;
goto err1;
}
if (rootd == 0)
(void) strcat(resolved, "/");
(void) strcat(resolved, wbuf);
}
------8<------cut-here------8<------
Since the path is constructed from current working directory and a file
name specified as an parameter to various FTP commands attacker needs to
create deep directory structure.
Following FTP commands may be used to cause buffer overflow:
STOR
RETR
APPE
DELE
MKD
RMD
STOU
RNTO
This bug may be non-exploitable if size of the buffer is greater than
MAXPATHLEN characters. This may occur for example if wu-ftpd is compiled
with some versions of Linux kernel where PATH_MAX (and MAXPATHLEN
accordingly) is defined to be exactly 4095 characters. In such cases,
the buffer is padded with an extra byte because of variable alignment
which is a result of code optimization.
Linux 2.2.x and some early 2.4.x kernel versions defines PATH_MAX to be
4095 characters, thus only wu-ftpd binaries compiled on 2.0.x or later 2.4.x
kernels are affected.
Exploit:
========
We investigated and successfully exploited this vulnerability on x86 based
Linux system running 2.4.19 kernel. We believe that exploitation of other
little-endian systems is also possible.
Impact:
=======
Authenticated local user or anonymous FTP user with write-access could
execute arbitrary code with root privileges.
Powerbook G5
macrumors 68040
It sounds like this is a security fix for the "just in case", it may never be an issue, but it's good that Apple is finding and addressing any possible problems so we don't end up with a potential security risk.
But if you're not running ftp and your firewall blocks the port isn't this not really an exploit?
Re: Threat (off a linux site, but likely applies to BSD based systems as well)
I haven't examined the bug in depth, but it gave me a scare, so I thought I'd just give you guys my notes.
I doubt they would phrase it like that unless they believed that the problem was restricted to little-endian systems. Macs are big-endian.
Also, keep in mind that this is only applicable to you if you run FTP with a guest/anonymous login with write privileges, or don't trust one of your user accounts with root access.
Other than that, seems pretty scary. Remote root exploits are the worst kind.
I haven't examined the bug in depth, but it gave me a scare, so I thought I'd just give you guys my notes.
I doubt they would phrase it like that unless they believed that the problem was restricted to little-endian systems. Macs are big-endian.
Also, keep in mind that this is only applicable to you if you run FTP with a guest/anonymous login with write privileges, or don't trust one of your user accounts with root access.
Other than that, seems pretty scary. Remote root exploits are the worst kind.
Vulnerability
There is a list of unix commands that can be run in such a way to create the exploit, and thus, even with firewall on and ftp off, it is possible for a user of the computer (who is not admin) to run a file in such a way to gain access.
So since it is possible for a non Admin user to gain Root access via the exploit, it is a very serious security risk.
Please update immediately.
Thank you.
Jaedreth
There is a list of unix commands that can be run in such a way to create the exploit, and thus, even with firewall on and ftp off, it is possible for a user of the computer (who is not admin) to run a file in such a way to gain access.
So since it is possible for a non Admin user to gain Root access via the exploit, it is a very serious security risk.
Please update immediately.
Thank you.
Jaedreth
idea_hamster
macrumors 65816
Security 101 question....
Am I wrong or is this similar to the vulnerability that was discovered in the Windows systems?
They both use a buffer overflow and they both allow an unauthorized user to execute code on the target machine -- right?
Is there some reason why the *nix version of the buffer overflow vulnerability is less of a concern that it is/was for the Windows systems?
"Little-endian"? "Big-endian"? Is this explainable in a sentence or two?
I would love a bit of coaching on this if anyone's so inclined...
Am I wrong or is this similar to the vulnerability that was discovered in the Windows systems?
They both use a buffer overflow and they both allow an unauthorized user to execute code on the target machine -- right?
Is there some reason why the *nix version of the buffer overflow vulnerability is less of a concern that it is/was for the Windows systems?
"Little-endian"? "Big-endian"? Is this explainable in a sentence or two?
I would love a bit of coaching on this if anyone's so inclined...
Re: Vulnerability
Uhhh...and what exactly would that "list of unix commands" be?
The exploit is in fb_realpath, a function in the FTP daemon.
BTW, here's some exploit code:
http://www.derkeiler.com/Mailing-Lists/Securiteam/2003-08/0010.html
Anyone wanna try this against one of their own systems?
Uhhh...and what exactly would that "list of unix commands" be?
The exploit is in fb_realpath, a function in the FTP daemon.
BTW, here's some exploit code:
http://www.derkeiler.com/Mailing-Lists/Securiteam/2003-08/0010.html
Anyone wanna try this against one of their own systems?
Re: Security 101 question....
You're right, they are fundamentally the same coding error.
In this case, the UNIX version is less of a problem because you need certain access to get to the point where you can cause the overflow. On the Windows exploit, it is very easy to get to that point, and you don't need any privileges on the target machine.
In a way, it is due to the philosophical differences; on Unix-like machines, you typically can't get very far "in the code" without having some sort of permission, either enabled by the owner of the machine, or granted through a user account.
Internal byte order. Google is your friend.
http://info.astrian.net/jargon/terms/l/little-endian.html
Like I said, I haven't looked at the bug in depth, so I don't know how this applies here, but you don't usually bring that kind of stuff up unless it has something to do with the issue at hand.
You're right, they are fundamentally the same coding error.
In this case, the UNIX version is less of a problem because you need certain access to get to the point where you can cause the overflow. On the Windows exploit, it is very easy to get to that point, and you don't need any privileges on the target machine.
In a way, it is due to the philosophical differences; on Unix-like machines, you typically can't get very far "in the code" without having some sort of permission, either enabled by the owner of the machine, or granted through a user account.
Internal byte order. Google is your friend.
http://info.astrian.net/jargon/terms/l/little-endian.html
Like I said, I haven't looked at the bug in depth, so I don't know how this applies here, but you don't usually bring that kind of stuff up unless it has something to do with the issue at hand.
How prompt is Apple about incorporating Darwin security fixes? What I'm wondering is, when a Unix security flaw that applies to Darwin is discovered by others and reported on the Internet, is Apple pretty quick to apply the patch and issue a Security Update?
When was that report posted, jaedreth?
When was that report posted, jaedreth?
How Recent?
The report I quoted was posted on the 10th of August, this year.
Four days, not bad for Apple.
Jaedreth
The report I quoted was posted on the 10th of August, this year.
Four days, not bad for Apple.
Jaedreth
Powerbook G5
macrumors 68040
I say that Apple was pretty quick with the patch, especially considering they have their hands with with multiple projects as is.
robotrenegade
macrumors 6502a
displaced
macrumors 65816
Re: Security 101 question....
Similar ... but totally dissimilar 🙂
This bug is limited to those who run FTP software. The patch is pretty minor, and -- whilst theoretically quite nasty -- it does not replicate itself.
[edit: if this is the same bug as that which led to the r00ting of the GNU FTP server, then it's not theoretical any more.]
I've spent the past few days dealing with the MSBlast worm at work. This flaw caused the RPC server process (an integral part of the Microsoft Networking system) to fail. Windows' default response to this was a mandatory, non-cancellable reboot. Systems would not stay online long enough to download or serve the patch to them.
The Unix bug appears to affect a particular piece of FTP server software (apologies if this is incorrect - I need to read up on it). Are you free to use another FTP server? Of course! Could you use a different RPC server for Windows? Not a chance.
Antivirus software was fully up-to-date and functioning, but not particularly useful. It would detect and remove the worm, but because of the flaw, the machine would be reinfected within minutes.
Quite a headache, but we're sorted now. You're probably wondering why we weren't already patched. Only a very very brave admin configures Windows workstations to automatically apply MS patches. Chances are, you'll come in to work one morning and find every machine's unable to run one of your vital apps, or a setting's been changed 'for security', disabling something you've got set up on purpose.
We're implementing Software Update Services over the next few days to allow us to easily test, approve and distribute patches.
Gimme a break - I've only been there a month 😉 I can't start surreptitiously replacing Dells with Xserves just yet.
Just to bring things back on topic: OS X and other Unices, by their very design, have great advantages over Windows in these sorts of situations. Unix is 'shallow and wide' -- many task specific components working together, but not necessarily dependent upon each other, to form the whole environment. Windows is 'deep and narrow' - a precarious house of cards, where too many assumptions are made by the system about its own state. Guess which is more tolerant of faults and which is easier to fix with a good degree of certainty about the stability of the system after the fix is applied?
Administering Windows networks is a bit like trying to sword-swallow while someone's tickling your feet.
(And if that's not the weirdest analogy I come up with this week, I'll buy a hat and eat it.)
Similar ... but totally dissimilar 🙂
This bug is limited to those who run FTP software. The patch is pretty minor, and -- whilst theoretically quite nasty -- it does not replicate itself.
[edit: if this is the same bug as that which led to the r00ting of the GNU FTP server, then it's not theoretical any more.]
I've spent the past few days dealing with the MSBlast worm at work. This flaw caused the RPC server process (an integral part of the Microsoft Networking system) to fail. Windows' default response to this was a mandatory, non-cancellable reboot. Systems would not stay online long enough to download or serve the patch to them.
The Unix bug appears to affect a particular piece of FTP server software (apologies if this is incorrect - I need to read up on it). Are you free to use another FTP server? Of course! Could you use a different RPC server for Windows? Not a chance.
Antivirus software was fully up-to-date and functioning, but not particularly useful. It would detect and remove the worm, but because of the flaw, the machine would be reinfected within minutes.
Quite a headache, but we're sorted now. You're probably wondering why we weren't already patched. Only a very very brave admin configures Windows workstations to automatically apply MS patches. Chances are, you'll come in to work one morning and find every machine's unable to run one of your vital apps, or a setting's been changed 'for security', disabling something you've got set up on purpose.
We're implementing Software Update Services over the next few days to allow us to easily test, approve and distribute patches.
Gimme a break - I've only been there a month 😉 I can't start surreptitiously replacing Dells with Xserves just yet.
Just to bring things back on topic: OS X and other Unices, by their very design, have great advantages over Windows in these sorts of situations. Unix is 'shallow and wide' -- many task specific components working together, but not necessarily dependent upon each other, to form the whole environment. Windows is 'deep and narrow' - a precarious house of cards, where too many assumptions are made by the system about its own state. Guess which is more tolerant of faults and which is easier to fix with a good degree of certainty about the stability of the system after the fix is applied?
Administering Windows networks is a bit like trying to sword-swallow while someone's tickling your feet.
(And if that's not the weirdest analogy I come up with this week, I'll buy a hat and eat it.)
Wonder Boy
macrumors 6502a
that suggests that the creative department is charge of software updates as well as apple legal. I bet they have people who deal soley with this stuff.
Prompt security updates are almost always a good thing, but I can see a slight downside. Those with broadband connections can simply accept regular updates and not think twice, in a sense letting Apple be their security manager, keeping the O.S. up to date no matter how often these changes show up.
But imagine if there were updates every day or two. Low-speed (modem) users would have to check the size and description of each patch to decide if they want to take the time to download it, or whether to wait for yet another patch that might supercede it later anyway. If they weren't at risk for that particular security flaw (which is hard to judge if you aren't technical enough), they'd likely skip it.
I'm not blaming Apple. I think they are making the right choice: offer updates promptly, describe them, and let users decide when to install them.
But imagine if there were updates every day or two. Low-speed (modem) users would have to check the size and description of each patch to decide if they want to take the time to download it, or whether to wait for yet another patch that might supercede it later anyway. If they weren't at risk for that particular security flaw (which is hard to judge if you aren't technical enough), they'd likely skip it.
I'm not blaming Apple. I think they are making the right choice: offer updates promptly, describe them, and let users decide when to install them.
Re: How Recent?
"The realpath(3) function is used to determine the canonical, absolute pathname from a given pathname which may contain extra ``/'' characters, references to ``/./'' or ``/../'', or references to symbolic links."
Taken from :
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-03:08.realpath.asc
The bug was posted to the FreeBSD security list on the 4th, so 10 days, but still not bad.
The bug is in the C function realpath, part of the FreeBSD standard libraries, which i assume wu-ftpd borrowed and renamed fb_realpath. It is not limited to ftp servers, but as jaedreth mentioned, may affect a large list of software (stressing the may, since it depends how the software uses the function). The FreeBSD advisory above has a list of applications that use realpath.
Whether other applications are affected on OS X is another matter, but potentially it's serious.
"The realpath(3) function is used to determine the canonical, absolute pathname from a given pathname which may contain extra ``/'' characters, references to ``/./'' or ``/../'', or references to symbolic links."
Taken from :
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-03:08.realpath.asc
The bug was posted to the FreeBSD security list on the 4th, so 10 days, but still not bad.
The bug is in the C function realpath, part of the FreeBSD standard libraries, which i assume wu-ftpd borrowed and renamed fb_realpath. It is not limited to ftp servers, but as jaedreth mentioned, may affect a large list of software (stressing the may, since it depends how the software uses the function). The FreeBSD advisory above has a list of applications that use realpath.
Whether other applications are affected on OS X is another matter, but potentially it's serious.
Thanks for the info
I just did a quick search. I was surmising that it would affect BSD systems as well, since it affected OS X, and turns out I was right. Thanks again, great info.
Jaedreth
I just did a quick search. I was surmising that it would affect BSD systems as well, since it affected OS X, and turns out I was right. Thanks again, great info.
Jaedreth
I can see your point, but most of these security issues really only become a problem or risk when using a full time broadband connection. So being on dial-up saves you in a way. Did you know you can take your computer to any Apple store and hook up to get updates? Call ahead, and they will take care of you at no charge. Toting in your PowerMac isn't as bad as it sounds.
juniormaj
macrumors regular
Odd side effect?!
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.
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.
<OT>
Now wouldn't it even be cooler if you could just dial into an Apple Store and get updates for free? 😀
</OT>
10 days for Apple to respond isn't as bad as it sounds to me, at least. I guess they'd do some more tests of their own rather than just blindly copying the fixes from the community (or at least I'd like to think they'd to that). They are after all still maintaining v10.0, 10.1, 10.2, and 10.3.
But most users who don't have wu-ftpd up and running shouldn't be affected too much (unless there's another service/app that uses that same function). Also, has anyone tried replacing wu-ftpd with something "more" secure? I don't mean just downloading an app and running it instead of wu-ftpd, but have Apple's default choice point to another app instead.