[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110811140533.GB1641@linux-mips.org>
Date: Thu, 11 Aug 2011 15:05:33 +0100
From: Ralf Baechle <ralf@...ux-mips.org>
To: Thomas Osterried <thomas@...erried.de>
Cc: Eren Türkay <eren@...dus.org.tr>,
oss-security@...ts.openwall.com,
Thomas Osterried <ax25@...erg.in-berlin.de>
Subject: Re: CVE request (and disclosure): ax25d missing
setuid return code check
On Thu, Aug 11, 2011 at 02:13:23PM +0200, Thomas Osterried wrote:
> Am Donnerstag, den 11. August 2011 um 07:20:41 Uhr, schrieb Eren Türkay <eren@...dus.org.tr> in <20110811052041.GB2043@...t-is@...some>:
> > On Tue, Aug 09, 2011 at 11:33:04PM -0400, Dan Rosenberg wrote:
> > > The AX.25 daemon (ax25d), typically provided in the ax25-tools
> > > package, allows administrators to associate incoming AX.25, NET/ROM,
> > > and ROSE traffic with the execution of an endpoint program (most
> > > commonly "node"), which is run under a specified user account.
> > > Because ax25d is missing a check on the return code for a setuid call
> > > responsible for dropping privileges to the specified user, it may be
> > > possible to cause setuid to fail, after which the chosen program will
> > > be executed with root privileges. In other words, if you're in the
> > > business of handing out unprivileged shells over amateur radio (don't
> > > we all? :p ), this would allow for remote compromise.
> >
> > Hello,
> >
> > Thank you for your investigation on the topic. Although this issue seems
> > to be low-priority, it's good to let the maintainers know.
> >
> > I'm CCing Ralf Baechle, and Thomas Osterried who, accordingly to
> > linux-ac25 site, are the maintainers of ax25 utilities.
>
> thank you for your information.
>
> I know that code fragment, but I never imagined that if root calls
> setuid/setgid that this could fail, because root has by definition enough
> rights.
Welcome to the new world where things are more complicated ...
These days setuid and similar syscalls need to allocate memory for the
credentials of a process and memory allocations may fail. A system could
even be put under massive memory pressure with the intend to make this
allocation fail.
Also setuid requires the capability CAP_SETUID which a process - running
as root or not may not have.
Finally a the Linux security subsystem has its say and while it's odd to
configure an LSM to reject the attempt to drop privileges it's entirely
possible.
Ralf
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
