OpenBSD's new file(1) is now priv-separated • Hacker News Board

Re: OpenBSD's new file(1) is now priv-separated

#21

Post by raldi » Tue, Apr 28, 2015, 6:01 PM UTC

IvyMike wrote: post #19

raldi wrote: post #14

Earlier quoted context omitted.

http://en.wikipedia.org/wiki/Small_matter_of_programming

I think DasIch is saying "why allow file(1) to open sockets, write to arbitrary files, and run external programs"? Given the correct input, at least a month ago, it could do all of those things. (I am not sure that attempting to enforce this within the file(1) binary is optimal... after all, even though the attack surface is much reduced, file(1) could still have a bug somewhere prior to the sandboxing. If you could…

> why allow file() to open sockets

If by "open sockets" you mean open existing sockets in read-only mode, it's so that it can identify them as sockets. If by "open sockets" you mean create new sockets, I don't think it does do that:

https://github.com/threatstack/libmagic/search?utf8=%E2%9C%9...

> write to arbitrary files

It appears it only does this if running on OS/2 and investigating what's inside a compressed file. Under these conditions, a temporary file is necessary for platform-specific reasons:

https://github.com/threatstack/libmagic/blob/3dea7072b8d7e92...

It also writes to a non-arbitrary mmapped file (the magic database), because that's how such databases work; you query them by writing to them in a particular way:

https://github.com/threatstack/libmagic/blob/3dea7072b8d7e92...

> run external programs

I can't find any examples where it does that. Do you know of any?

Re: OpenBSD's new file(1) is now priv-separated

#22

Post by IvyMike » Tue, Apr 28, 2015, 6:30 PM UTC

raldi wrote: post #21

IvyMike wrote: post #19

Earlier quoted context omitted.

I think DasIch is saying "why allow file(1) to open sockets, write to arbitrary files, and run external programs"? Given the correct input, at least a month ago, it could do all of those things. (I am not sure that attempting to enforce this within the file(1) binary is optimal... after all, even though the attack surface is much reduced, file(1) could still have a bug somewhere prior to the sandboxing. If you could…

> why allow file() to open sockets If by "open sockets" you mean open existing sockets in read-only mode, it's so that it can identify them as sockets. If by "open sockets" you mean create new sockets, I don't think it does do that: https://github.com/threatstack/libmagic/search?utf8=%E2%9C%9... > write to arbitrary files It appears it only does this if running on OS/2 and investigating what's inside a compressed fil…

"It may be possible for such an attacker to execute arbitrary code with the privileges of the user running file(1)."

This is what I am saying...given the right input, file(1) could do anything and everything. Yes, it's only due to a bug in file(1), but still that's kind of ridiculous.

We have all sorts of things in place to protect against other bugs (for example, segmentation faults), and there's 27 years of evidence that we need some more help.

Re: OpenBSD's new file(1) is now priv-separated

#23

Post by bandrami » Tue, Apr 28, 2015, 6:32 PM UTC

viraptor wrote: post #10

Separation is done. 1/3 points done: https://news.ycombinator.com/item?id=9441262 I didn't realise openbsd had a seccomp equivalent, but I'm happy it does! (And it did make the news again)

Systrace was added to the base system 10 or 11 years ago (3.6, IIRC), but there was some hesitation among some key team members to use it widely (the argument being that privilege separation utilities themselves will almost always have security problems). That ship seems to have sailed, though, in more recent years.

Re: OpenBSD's new file(1) is now priv-separated

#24

Post by bandrami » Tue, Apr 28, 2015, 6:33 PM UTC

DasIch wrote: post #4

msl09 wrote: post #3

From my understanding file is a pretty simple program, why does it need to care about privilege separation?

file is indeed a pretty simple program. Why allow it to do more than it needs to?

http://en.wikipedia.org/wiki/Halting_problem

Welcome to the joys of parsing.

Re: OpenBSD's new file(1) is now priv-separated

#25

Post by Sanddancer » Tue, Apr 28, 2015, 7:01 PM UTC

msl09 wrote: post #3

From my understanding file is a pretty simple program, why does it need to care about privilege separation?

File parsing is a pretty hard problem. Let's take for example a Microsoft .exe file. They all start with the string MZ. However, saying something is an executable file is just the start of the rabbit hole. Is it purely a DOS executable, or is it a windows PE executable? Or is it an OS/2 LE executable, or is it a wrapper around a COFF file created by DJGPP? Okay, now, we know it's a PE file. Is this PE file actually a self extracting archive file created by PKZIP? Or maybe RAR? All of those are also things which have definite headers and offsets that you have to look to, and which the file utility needs to know how to look for, and where things can quickly get complicated.

Re: OpenBSD's new file(1) is now priv-separated

#26

Post by bandrami » Tue, Apr 28, 2015, 7:23 PM UTC

IvyMike wrote: post #19

raldi wrote: post #14

Earlier quoted context omitted.

http://en.wikipedia.org/wiki/Small_matter_of_programming

I think DasIch is saying "why allow file(1) to open sockets, write to arbitrary files, and run external programs"? Given the correct input, at least a month ago, it could do all of those things. (I am not sure that attempting to enforce this within the file(1) binary is optimal... after all, even though the attack surface is much reduced, file(1) could still have a bug somewhere prior to the sandboxing. If you could…

why allow file(1) to open sockets, write to arbitrary files, and run external programs

Well, there's not code in file(1) to do that, but there's code that reads data in and makes decisions based on that data. Which means, if your attacker is more careful than the programmer was, you have possibly given that attacker a Turing machine.

Re: OpenBSD's new file(1) is now priv-separated

#27

Post by bandrami » Tue, Apr 28, 2015, 7:24 PM UTC

IvyMike wrote: post #22

raldi wrote: post #21

Earlier quoted context omitted.

> why allow file() to open sockets If by "open sockets" you mean open existing sockets in read-only mode, it's so that it can identify them as sockets. If by "open sockets" you mean create new sockets, I don't think it does do that: https://github.com/threatstack/libmagic/search?utf8=%E2%9C%9... > write to arbitrary files It appears it only does this if running on OS/2 and investigating what's inside a compressed fil…

"It may be possible for such an attacker to execute arbitrary code with the privileges of the user running file(1)." This is what I am saying...given the right input, file(1) could do anything and everything. Yes, it's only due to a bug in file(1), but still that's kind of ridiculous. We have all sorts of things in place to protect against other bugs (for example, segmentation faults), and there's 27 years of evidenc…

Yes, it's only due to a bug in file(1), but still that's kind of ridiculous

I point again to:

http://en.wikipedia.org/wiki/Halting_problem

If you are reading in from a file, and you make decisions that are complex enough to be S- and K- combinators (or a concept of "if" and "jump", or some other minimal set), then you have given an attacker a Turing machine.

Re: OpenBSD's new file(1) is now priv-separated

#28

Post by IvyMike » Tue, Apr 28, 2015, 7:36 PM UTC

bandrami wrote: post #27

IvyMike wrote: post #22

Earlier quoted context omitted.

"It may be possible for such an attacker to execute arbitrary code with the privileges of the user running file(1)." This is what I am saying...given the right input, file(1) could do anything and everything. Yes, it's only due to a bug in file(1), but still that's kind of ridiculous. We have all sorts of things in place to protect against other bugs (for example, segmentation faults), and there's 27 years of evidenc…

Yes, it's only due to a bug in file(1), but still that's kind of ridiculous I point again to: http://en.wikipedia.org/wiki/Halting_problem If you are reading in from a file, and you make decisions that are complex enough to be S- and K- combinators (or a concept of "if" and "jump", or some other minimal set), then you have given an attacker a Turing machine.

I agree.

But what I'm saying is that the Turing machine should not be connected to a gun. And being hooked up to an idle gun should not be the default for every program.

Re: OpenBSD's new file(1) is now priv-separated

#29

Post by jquast » Tue, Apr 28, 2015, 8:06 PM UTC

bandrami wrote: post #23

viraptor wrote: post #10

Separation is done. 1/3 points done: https://news.ycombinator.com/item?id=9441262 I didn't realise openbsd had a seccomp equivalent, but I'm happy it does! (And it did make the news again)

Systrace was added to the base system 10 or 11 years ago (3.6, IIRC), but there was some hesitation among some key team members to use it widely (the argument being that privilege separation utilities themselves will almost always have security problems). That ship seems to have sailed, though, in more recent years.

I think the lack of implementation was that were vulnerabilities in design that I don't think were ever resolved, it simply can't work as the only line of defense. http://undeadly.org/cgi?action=article&sid=20070809201304

It's too bad, I think system calls are a very good place to apply security policies. I think the issue is that one can modify the memory structures pointed to by a system call after it has been "approved" by systrace policy, but before the kernel acts on it. While the ownership of such data structures are in userspace, its perfectly fine to modify such regions.

It's too bad, I think its possibly the most straight-forward approach compared to SELinux or MAC

Re: OpenBSD's new file(1) is now priv-separated

#30

Post by alnsn » Tue, Apr 28, 2015, 10:17 PM UTC

DominikD wrote: post #20

DasIch wrote: post #4

Earlier quoted context omitted.

file is indeed a pretty simple program. Why allow it to do more than it needs to?

It's a configurable parser. Parsers tend to be the hardest thing to get right, hence bugs detected by AFL in FreeBSD's file, in SQL parser in SQLite, etc. A lot of the vulnerabilities in apps dealing with image files come down to parser being buggy. It seems simple until you actually try and implement it.

It depends on how much effort you put in making sure your parser is robust. I ran AFL tests for several days trying to find bugs in Lua parser but AFL kept discovering a way to load a binary chunk. After that, it didn't take to crash on a malformed binary chunk. Priv separation is a good idea even if you trust your parser.