Date: Thu, 24 May 2007 03:17:32 -0400 From: Kris Kennaway <kris@obsecurity.org> To: Colin Percival <cperciva@freebsd.org> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>, Kris Kennaway <kris@obsecurity.org> Subject: Re: RFC: Removing file(1)+libmagic(3) from the base system Message-ID: <20070524071732.GA80416@xor.obsecurity.org> In-Reply-To: <4655386E.2000605@freebsd.org> References: <46546E16.9070707@freebsd.org> <20070523192103.GA61937@xor.obsecurity.org> <4655386E.2000605@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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"? >=20 > 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. >=20 > 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 >=20 > 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 --/04w6evG8XlLl3ft Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGVTwMWry0BWjoQKURAkg/AKDKZj723zUXqKkjiyVOTWiZ5mI8JgCgr74c Bj+SVSev27qIJecp8TLgACU= =DhJR -----END PGP SIGNATURE----- --/04w6evG8XlLl3ft--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070524071732.GA80416>