Re: RFC: Removing file(1)+libmagic(3) from the base system

On Thu, May 24, 2007 at 12:02:06AM -0700, Colin Percival wrote:
Kris Kennaway wrote:
What is the threat you are defending against here: "Admin runs file(1)
on untrusted binary"?

Yes, or "user runs script(s) which run file(1) on untrusted binaries".

OK.

If so, how does it differ from e.g. running cat(1) on an untrusted
binary, which can reprogram your terminal emulation and in some cases
take over your terminal; or from various other unprivileged user
binaries that also crash when operating on corrupted data, possibly in
an exploitable way? Last time I checked lots of our /usr/bin tools
coredumped when you passed them unexpected input.

What do you mean by "unexpected input"? Do you mean unexpected data on
stdin to tools like b64decode, comm, cut, diff, and fold, which might
reasonably be run on untrusted data, or do you mean wacky command lines
to utilities like awk or c99 (where control over said command line would
innately give an attacker the ability to run code of his choosing)?

It was both (sed was another utility that liked to crash when fed
"badly-formed" input via stdin). It's in the same problem class as
your attack model, so any solution you come up with needs to also
include other similar utilities.

I think it's pretty clear that "remove them" is a non-starter, so you
should try to focus on ways to contain or mitigate the effects of the
class of threat you are concerned about. There is probably a lot of
scope for using the trustedbsd security features for hardening systems
that are at risk for this threat model.

Also, did coverity find the buffer overflow

No. The overflow resulted from failing to correctly keep track of how
much space was left in a buffer, so it wasn't something which Coverity
(or any other similar tool) really had any chance to find.

OK.

Kris

Attachment: pgpcCzYJmbWeV.pgp
Description: PGP signature