From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7333 Path: news.gmane.org!not-for-mail From: =?UTF-8?B?0KDRi9GB0Yw=?= Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: Busybox on musl is affected by CVE-2015-1817 Date: Fri, 3 Apr 2015 11:51:58 +0700 Message-ID: <20150403115158.66654b1e@r2lynx> References: <20150330053150.GA484@brightrain.aerifal.cx> <20150331234810.GN6817@brightrain.aerifal.cx> <20150401074116.GN23636@example.net> <551BA847.3040609@gmx.de> <20150401084940.GO23636@example.net> <551D4A74.7070102@gmx.de> <20150403002656.11f75341@r2lynx> <20150402183627.GE4456@example.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1428036788 3903 80.91.229.3 (3 Apr 2015 04:53:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 3 Apr 2015 04:53:08 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7346-gllmg-musl=m.gmane.org@lists.openwall.com Fri Apr 03 06:53:08 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1YdtbO-0001te-Uv for gllmg-musl@m.gmane.org; Fri, 03 Apr 2015 06:53:07 +0200 Original-Received: (qmail 24479 invoked by uid 550); 3 Apr 2015 04:53:05 -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 24458 invoked from network); 3 Apr 2015 04:53:04 -0000 X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,NO_RECEIVED, NO_RELAYS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 In-Reply-To: <20150402183627.GE4456@example.net> X-Mailer: claws_mail Xref: news.gmane.org gmane.linux.lib.musl.general:7333 Archived-At: On Thu, 2 Apr 2015 20:36:27 +0200 u-wsnj@aetey.se wrote: > On Fri, Apr 03, 2015 at 12:26:56AM +0700, =D0=A0=D1=8B=D1=81=D1=8C wrote: > > Audit your filesystem and remove all > > setuid bits from all programs, move/rename them as prog.real and > > place a shell script in place which will call setuid wrapper which > > then will setreuid(uid, 0) then execve(). >=20 > This way you are still exposed to setuid and also still depend on how > the prog.real is going to use the supplied credentials. You more or > less have to reimplement in your wrapper the checks expected "to be > already present" in the program, without any control over its > internals. If talking about ping issue then yes, ping and other such programs must not even start to process user input when not sure. You've got setuid -- quickly drop it when needed privileged resource is obtained. Tools just need to be fixed, without surrounding scream and initiating another security dances which usually only hurt. Instead of wrapper there maybe limiting group which members can run program, but Unix credentials were always somewhat limited and at some point you understand that without certain things like ACLs or sudo you can't effectively partition privileges. >=20 > This can certainly improve the situation if you are (which presumably > is the case) more security-oriented and thoughtful than the upstream > developer, but you are in an uphill battle. >=20 > For me this does not look like a solution, rather like a patchwork > which may or may not be effective. >=20 > Rune >=20