Since this doesn't cause a system panic... multiple userland utilities have MAXPATHLEN problems? Is this reproducible with longer filenames and less depth? (If not: what cares about depth?)
So in theory if you wanted to take down a web server that allows for creating files in a directory structure you just have to nest less than 1k of them to start wreaking havoc? Yikes if so.
Not very related, but it reminds me that there are a lot of people who rack Mac Pros in data centers. Not Mac Mini. Mac Pros. Yes, the cylinder one. I guess it's mostly for graphics and rendering capabilities or when testing requires the original machines. People come up with all sorts of tricks because it is very inefficient - like vents [1] - or this other company who 3D-printed pieces to keep the Macbook Pros open at 7mm (=0,05 banana) [2].
That's possible many AV products do not look into archives past a certain limit sending out a zip file with say a PDF and a hidden payload in a sub directory beyond the lookup depth of the AV software used to be a common way to achieve AV avoidance.
commercial ZIP software however usually limits the maximum depth and file path name to the lowest common denominator which is 250 chars for compatibility with Windows, some software will have a "unix" mode in which the max limit is increased to 1024.
An OS X web server... As another comment mentioned OS X is hindered by the fact they refuse to use GPL 3 code http://meta.ath0.com/2012/02/05/apples-great-gpl-purge/. This results in their userspace code being out of date (i.e. they still use bash version 3.2) and having bugs like these.
I don't think anybody knows whether there is a real difference, but the increased strictness of GPL3 such as its anti-TIVOization (https://en.m.wikipedia.org/wiki/Tivoization) clauses certainly make a lot of lawyers concerned.
Where exactly the border lies between and not linking is a grey area, legally, that hasn't become clearer with GPL3.
It wouldn't surprise me to see bash go from the standard install, too. Apple is slowly removing all GPL code from its OS.
I hope they make ZSH the standard shell. It's similar enough to bash to not disrupt most workflows and Apple has been able to update it due to its permissive license.
I use ZSH as my main shell on OS X. I find it superior to bash in almost every way (especially with oh-my-zsh) except in ubiquity. Even so, I have no problem using bash if that's all that's available, the two shells are fairly compatible.
if someone uses your software in a way that is honoring the GPLv3, but you don't like, you lose any ability to sue or further restrict them. Even though the ghost of Steve Jobs (Forstall) is no longer haunting the building, Apple learned the lesson of "sue early, sue often", and Stallman/Moglen sort of got in the way of that with GPLv3.
Tivoization was another issue, especially with Apple's tendency to lock down their platform.
Does that affect regular OS X desktops/laptops? It makes sense for Apple TVs and iOS devices (well, as much sense as locking them down in the first place) but for OS X, the anti-TiVoization clause merely requires that the end user be able to replace those binaries. And there's always a way to turn off System Integrity Protection.
Or are they worried about something else, like the patent clauses?
Apple could agree to any software licenses they wish, but they choose not to with GPLv3. There is nothing legally that prevent them from giving users access to source code, nor giving users permission to change software running on devices that they have bought from Apple.
Apple refuse to do this. No one know for sure but the common suspicion is that they want to avoid competition by locking users to a single platform where apple has a artificial created monopoly.
Which core product would that be? GPL require that you give out source code of derivative works (work based on someone else work).
One could be accused to think that the core products of Apple is the devices that they sells. What clause in GPLv3 require that they give devices out for free?
This is because OSX uses a feature-limited (and apparently completely broken given this report...) BSD-derived userspace instead of the GNU software used with Linux, which are usually specifically designed to not have fixed limits of any kind.
That's because, license wise, they can't include GPL 3 licensed code, aka the GNU user space.
Also, this bug does not prove that the whole user space is completely broken. Many people use it daily without ever hitting these bugs. If you go looking for issues, you'll find them, just as you'll find them on Linux but in different places. Not to say this doesn't suck and we shouldn't fix them, but it's hardly proof of anything.
Where "can't" means "they don't want to because they want to reserve themselves the ability to screw their users by shipping devices with OSX or derivatives installed where the user cannot change the software, which the GPLv3 is specifically designed to prevent".
Considering handling paths is one of the most fundamental functions of the Unix tools and C library, having buffer overflows there is quite damning.
Regardless of your personal dislike of the vendor, there have been plenty of buffer overflows and other bugs in coreutils/fileutils. The Mac/BSD user space is by no means an exception.
The article references http://www.opensource.apple.com/source/Libc/Libc-1044.40.1/g... but there's nothing that particularly stands out as being the bug at a quick glance and it is designed to handle arbitrarily deep hierarchies; nonetheless this looks like an off-by-one to me (in fts_alloc):
len = sizeof(FTSENT) + namelen;
if (!ISSET(FTS_NOSTAT))
len += sizeof(struct stat) + ALIGNBYTES;
if ((p = malloc(len)) == NULL)
return (NULL);
/* Copy the name plus the trailing NULL. */
memmove(p->fts_name, name, namelen + 1);
It's a pretty minor bug, since I'd bet the chances of it causing a major exploitable vulnerability are quite low. A theoretical attacker can only control somewhat coarsely where a single byte with the value 0 can be written, and this is in userspace. Most of the time it probably lands in unused padding, and otherwise in an invalid address which causes a segfault.
p->fts_statp = (struct stat )ALIGN(p->fts_name + namelen + 2);*
Unless ALIGN aligns the pointer towards the lower address( which would be weird ), that +2 might get out of bounds depending on how many bytes is ALIGNBYTES.
Please correct me if I'm wrong.
Edit:
This is the header that defines the struct FTSENT:
ALIGNBYTES is probably 3 or 7, depending on what ALIGN does, but the +2 seems like a bug to me. I think the intended layout is [FTSENT][name][0][optional [possible alignment padding][struct stat]] which means that +2 should really be a +1. The total memory allocated should be
(I Googled 'site:opensource.apple.com "#define ALIGNBYTES" inurl:.h' and got my query rewritten without the quotes and the dots in the domain name. No, I did NOT mean to search for anything else. Then I browsed to the 2nd page and got the "we detected suspicious activity" CAPTCHA. WTF?)
Depending on the value of namelen, and the padding at the end of the struct FTSENT, struct p->fts_statp will occupy one byte out of bounds of the allocated memory.
The comment made in the code is incorrect:
Since the fts_name field is declared to be of size 1, the fts_name pointer is namelen + 2 before the first possible address of the stat structure.
namelen + 1 is the first possible address for the stat structure.
No one will ever read this, but I just wanted to point out that the whole allocation is simply incorrect.
Even with just namelen+1 you can still get undefined behavior. This is because if namelen is shorter than the padding of the object struct FTSENT, the beginning of the next object struct stat, will overlap with the previous object.
The correct solution is to make sure that the next object begins after the first one, and still remains inside of the allocated block. This is a good example, why the struct hack just isn't worth it, and it itself is arguably undefined behavior.
To allocate it all, remove the struct hack and simply call the malloc three times, once for each struct and then for the string. If one allocation is required, then allocate enough memory for all three objects separated by enough alignment padding. Doing this will allocate a couple of bytes more which is a couple percent overall, but at least your code will be correct. Since they don't pack the struct thus loosing bytes for internal padding anyway, I can't understand why the usage of the struct hack.
Seems like there's a lot more vuln with OSX in the last few releases.
I'm still using OSX for basic stuff like browsing but I rely on a linux VM to do the serious stuff. I know that my vm can be compromised if the host system is vulnerable but I feel safer.
I ended up just installing Arch on my MacBook. Runs surprisingly well. I'm able to share my home dir since its on a second partition, so I didn't really have to start from scratch. I haven't booted into OS X in weeks.
Have you considered how much of that might be due to Apple's takeover of the consumer space? There were fewer people looking for exploits and even fewer reporters covering them before they became the OS of choice for hundreds of millions of people.
If you believe Linux is that much better, well, you really ought to follow your distribution's security announcement list. Nobody in the general computing space has a track record which entitles them to cast aspersions at the competition.
46 comments
[ 1.6 ms ] story [ 90.5 ms ] thread[1] I especially liked this blog: http://photos.imgix.com/racking-mac-pros
[2] https://simbimbo.wordpress.com/2015/07/24/well-im-at-it-agai...
commercial ZIP software however usually limits the maximum depth and file path name to the lowest common denominator which is 250 chars for compatibility with Windows, some software will have a "unix" mode in which the max limit is increased to 1024.
They do not refuse, they cannot include it from a legal point of view.
Where exactly the border lies between and not linking is a grey area, legally, that hasn't become clearer with GPL3.
It wouldn't surprise me to see bash go from the standard install, too. Apple is slowly removing all GPL code from its OS.
I use ZSH as my main shell on OS X. I find it superior to bash in almost every way (especially with oh-my-zsh) except in ubiquity. Even so, I have no problem using bash if that's all that's available, the two shells are fairly compatible.
Tivoization was another issue, especially with Apple's tendency to lock down their platform.
Or are they worried about something else, like the patent clauses?
Apple refuse to do this. No one know for sure but the common suspicion is that they want to avoid competition by locking users to a single platform where apple has a artificial created monopoly.
One could be accused to think that the core products of Apple is the devices that they sells. What clause in GPLv3 require that they give devices out for free?
Also, this bug does not prove that the whole user space is completely broken. Many people use it daily without ever hitting these bugs. If you go looking for issues, you'll find them, just as you'll find them on Linux but in different places. Not to say this doesn't suck and we shouldn't fix them, but it's hardly proof of anything.
Considering handling paths is one of the most fundamental functions of the Unix tools and C library, having buffer overflows there is quite damning.
https://github.com/coreutils/gnulib/blame/master/lib/fts.c#L...
https://github.com/coreutils/gnulib/commit/49078a78
p->fts_statp = (struct stat )ALIGN(p->fts_name + namelen + 2);*
Unless ALIGN aligns the pointer towards the lower address( which would be weird ), that +2 might get out of bounds depending on how many bytes is ALIGNBYTES.
Please correct me if I'm wrong.
Edit:
This is the header that defines the struct FTSENT:
https://opensource.apple.com/source/Libc/Libc-1044.40.1/incl...
https://opensource.apple.com/source/OpenSSH/OpenSSH-95/opens...
https://opensource.apple.com/source/xnu/xnu-792.13.8/bsd/ppc...
https://opensource.apple.com/source/sendmail/sendmail-32/sen...
They align toward the higher address.
The comment made in the code is incorrect:
Since the fts_name field is declared to be of size 1, the fts_name pointer is namelen + 2 before the first possible address of the stat structure.
namelen + 1 is the first possible address for the stat structure.
Even with just namelen+1 you can still get undefined behavior. This is because if namelen is shorter than the padding of the object struct FTSENT, the beginning of the next object struct stat, will overlap with the previous object.
The correct solution is to make sure that the next object begins after the first one, and still remains inside of the allocated block. This is a good example, why the struct hack just isn't worth it, and it itself is arguably undefined behavior.
To allocate it all, remove the struct hack and simply call the malloc three times, once for each struct and then for the string. If one allocation is required, then allocate enough memory for all three objects separated by enough alignment padding. Doing this will allocate a couple of bytes more which is a couple percent overall, but at least your code will be correct. Since they don't pack the struct thus loosing bytes for internal padding anyway, I can't understand why the usage of the struct hack.
If you believe Linux is that much better, well, you really ought to follow your distribution's security announcement list. Nobody in the general computing space has a track record which entitles them to cast aspersions at the competition.
https://openradar.appspot.com/22671534