OS X 10.11 buffer overflow with deep filesystem hierarchy

Re:OS X 10.11 buffer overflow with deep filesystem hierarchy by userbinator on Saturday October 24, 2015 @07:57AM (#10443324)

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.

[ Parent | on HN ]

Re:OS X 10.11 buffer overflow with deep filesystem hierarchy by pixelbeat on Saturday October 24, 2015 @09:08AM (#10443486)

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

[ Parent | on HN ]

Re:OS X 10.11 buffer overflow with deep filesystem hierarchy by just_curioussss on Saturday October 24, 2015 @09:15AM (#10443496)

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

[ Parent | on HN ]

Re:OS X 10.11 buffer overflow with deep filesystem hierarchy by userbinator on Saturday October 24, 2015 @09:43AM (#10443563)

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 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?)

[ Parent | on HN ]

Re:OS X 10.11 buffer overflow with deep filesystem hierarchy by just_curioussss on Saturday October 24, 2015 @09:48AM (#10443580)

I found a couple different definitions:

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.

[ Parent | on HN ]

Re:OS X 10.11 buffer overflow with deep filesystem hierarchy by anonbanker on Saturday October 24, 2015 @02:31PM (#10444436)

so the +2 is indeed out of bounds?

[ Parent | on HN ]

Re:OS X 10.11 buffer overflow with deep filesystem hierarchy by just_curioussss on Saturday October 24, 2015 @02:41PM (#10444461)

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.

[ Parent | on HN ]

Re:OS X 10.11 buffer overflow with deep filesystem hierarchy by just_curioussss on Sunday October 25, 2015 @06:25AM (#10446533)

Note, this refers to: https://opensource.apple.com/source/Libc/Libc-1044.40.1/gen/...

[ Parent | on HN ]

Re:OS X 10.11 buffer overflow with deep filesystem hierarchy by just_curioussss on Sunday October 25, 2015 @10:44AM (#10446978)

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.

[ Parent | on HN ]

Re:OS X 10.11 buffer overflow with deep filesystem hierarchy by raimue on Saturday October 24, 2015 @12:01PM (#10443965)

Interestingly, this is actually the Libc code of OS X 10.10.5 Yosemite. Source code for OS X 10.11 El Capitan has not yet been released by Apple.

[ Parent | on HN ]