From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5259 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Binaries compiled with musl (1.1.2) are vulnerable to an ancient ldd exploit Date: Sat, 14 Jun 2014 12:30:26 -0400 Message-ID: <20140614163026.GJ179@brightrain.aerifal.cx> References: <20140614160243.GG179@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1402763451 7205 80.91.229.3 (14 Jun 2014 16:30:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 14 Jun 2014 16:30:51 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5264-gllmg-musl=m.gmane.org@lists.openwall.com Sat Jun 14 18:30:40 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Wvqqm-0003ad-3a for gllmg-musl@plane.gmane.org; Sat, 14 Jun 2014 18:30:40 +0200 Original-Received: (qmail 7947 invoked by uid 550); 14 Jun 2014 16:30:39 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 7937 invoked from network); 14 Jun 2014 16:30:39 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:5259 Archived-At: On Sat, Jun 14, 2014 at 05:10:40PM +0100, Steven Honeyman wrote: > I'm not suggesting it is the "fault" of musl - but as in your own > words, it provides a social engineering exploit. > > ldd (GNU libc) 2.19 > Copyright (C) 2014 > > ^ still works with that version. As for "additional danger" - sure it > can: if (getenv("LD_TRACE_LOADED_OBJECTS")) eraseHomeDir(); > > I was suggesting/posting this thinking it be a good idea to check for > LD_TRACE_LOADED_OBJECTS and output something e.g. "Please use ldd from > musl" then exit? > Even without root permissions, a careless user could still have their > files wiped out (etc). It's inherently unsafe to run glibc ldd on binaries you don't trust: it's equivalent to running the binary and giving it full access to the invoker's privileges. For musl to suppress this as you suggested does not protect anyone. An attacker making a malicious binary can just modify musl (or just make a static-linked binary) for use in the attack. All that processing LD_TRACE_LOADED_OBJECTS would do is prevent non-malicious binaries from running when it's set, which itself could be a source of exploits (e.g. arranging for a script not to execute a command it should by having LD_TRACE_LOADED_OBJECTS in the environment when the command is run; this could work especially well on systems with a mix of static and dynamic binaries where only the dynamic binaries would be suppressed). Rich