21–30 of 47 posts
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…
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…
https://github.com/coreutils/gnulib/blame/master/lib/fts.c#L...
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…
There have been a couple of recent changes to the latest GNU version of that related to flexible array members: 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...
Earlier quoted context omitted.
There have been a couple of recent changes to the latest GNU version of that related to flexible array members: https://github.com/coreutils/gnulib/blame/master/lib/fts.c#L... https://github.com/coreutils/gnulib/commit/49078a78
This part is also suspicious: 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...
sizeof(FTSENT) + namelen + 1 + (padding + sizeof(struct stat))
Earlier quoted context omitted.
This part is also suspicious: 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...
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 sizeof(FTSENT) + namelen + 1 + (padding + sizeof(struct stat)) (I Googled 'site:opensource.apple.com "#define ALIGNBYTES" inurl:.h' and got my…
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.
Earlier quoted context omitted.
This part is also suspicious: 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...
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 sizeof(FTSENT) + namelen + 1 + (padding + sizeof(struct stat)) (I Googled 'site:opensource.apple.com "#define ALIGNBYTES" inurl:.h' and got my…
Earlier quoted context omitted.
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 an…
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.
Earlier quoted context omitted.
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.
> As another comment mentioned OS X is hindered by the fact they refuse to use GPL 3 code They do not refuse, they cannot include it from a legal point of view.
Or are they worried about something else, like the patent clauses?
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.