Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OS X 10.11 buffer overflow with deep filesystem hierarchy

cxsecurity.com

Post reply on HN
Print view View original

41–47 of 47 posts

Re: OS X 10.11 buffer overflow with deep filesystem hierarchy

#41

Post by just_curioussss »

anonbanker wrote: post #38
just_curioussss wrote: post #26

Earlier quoted context omitted.

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.

so the +2 is indeed out of bounds?

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.

Re: OS X 10.11 buffer overflow with deep filesystem hierarchy

#42

Post by anonbanker »

tedunangst wrote: post #10
trengrj wrote: post #8

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.

So all BSD systems have the same bug??

ITT: tedunangst asks a question he already knows the answer to. upvoted.

Re: OS X 10.11 buffer overflow with deep filesystem hierarchy

#43

Post by lmm »

daenney wrote: post #28
devit wrote: post #15

Earlier quoted context omitted.

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.

Which is a real indictment of C, when programs this simple have bugs this severe.

Re: OS X 10.11 buffer overflow with deep filesystem hierarchy

#44

Post by belorn »

matt4077 wrote: post #37
belorn wrote: post #34

Earlier quoted context omitted.

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…

Or maybe they just don't want to give away one of their core products for free.

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?

Re: OS X 10.11 buffer overflow with deep filesystem hierarchy

#46

Post by just_curioussss »

just_curioussss wrote: post #41
anonbanker wrote: post #38

Earlier quoted context omitted.

so the +2 is indeed out of bounds?

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.

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

Re: OS X 10.11 buffer overflow with deep filesystem hierarchy

#47

Post by just_curioussss »

just_curioussss wrote: post #46
just_curioussss wrote: post #41

Earlier quoted context omitted.

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.

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

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.

Post reply on HN