Re: CVE request (and disclosure): ax25d missing setuid return code check

[Thomas Osterried <thomas () osterried de>]

Thank you for your information.

The issue is now fixed in the upstream version.

vy 73,
        - Thomas  dl9sau

Am Donnerstag, den 11. August 2011 um 16:21:11 Uhr, schrieb Jon Oberheide <jon () oberheide org> in 
<1313072471.19030.0.camel@localhost.localdomain>:
> On Thu, 2011-08-11 at 15:05 +0100, Ralf Baechle wrote:
> > 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 () pardus org tr> in 
> > > <20110811052041.GB2043@mutt-is@awesome>:
> > > > 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.
>
> The important vector is RLIMIT_NPROC.
>
> Regards,
> Jon Oberheide