Busybox on musl is affected by CVE-2015-1817

Busybox on musl is affected by CVE-2015-1817

[Rich Felker]

For details on CVE-2015-1817, see:
http://www.openwall.com/lists/musl/2015/03/30/1

With musl-linked Busybox installed setuid and ping enabled, exploiting
this issue is trivial.

While CVE-2015-1817 is certainly musl's fault, there are two changes
to Busybox I'd like to propose that would have prevented it from being
exploitable:

1. Having setuid utilities like ping obtain the resource they need (in
   the case of ping, SOCK_RAW) without processing user input at all,
   then fully dropping root (setuid(getuid())) before doing anything.
   This has been standard practice for setuid programs since the 90s
   and it feels bad that busybox is not doing it.

2. Reconsider the rejection of the patch to add SOCK_DGRAM support for
   ping, which allows it to run without root.

Do either or both of these sound acceptable?

Rich

Re: Busybox on musl is affected by CVE-2015-1817

[Denys Vlasenko]

On Mon, Mar 30, 2015 at 7:31 AM, Rich Felker <dalias@libc.org> wrote:
> For details on CVE-2015-1817, see:
> http://www.openwall.com/lists/musl/2015/03/30/1
>
> With musl-linked Busybox installed setuid and ping enabled, exploiting
> this issue is trivial.
>
> While CVE-2015-1817 is certainly musl's fault, there are two changes
> to Busybox I'd like to propose that would have prevented it from being
> exploitable:
>
> 1. Having setuid utilities like ping obtain the resource they need (in
>    the case of ping, SOCK_RAW) without processing user input at all,
>    then fully dropping root (setuid(getuid())) before doing anything.
>    This has been standard practice for setuid programs since the 90s
>    and it feels bad that busybox is not doing it.

In general this is acceptable, but with this particular case
and CVE, it wouldn't help.

create_icmp_socket(lsa) needs to know of which address family
the socket should be:

        if (lsa->u.sa.sa_family == AF_INET6)
                sock = socket(AF_INET6, SOCK_RAW, IPPROTO_ICMPV6);
        else
                sock = socket(AF_INET, SOCK_RAW, 1); /* 1 == ICMP */

This is only known after HOST is parsed.
And CVE is in DNS resolving code :(


> 2. Reconsider the rejection of the patch to add SOCK_DGRAM support for
>    ping, which allows it to run without root.

This seems to lead to a significantly larger code.

Re: Re: Busybox on musl is affected by CVE-2015-1817

[Justin Cormack]

On 31 March 2015 at 20:07, Denys Vlasenko <vda.linux@googlemail.com> wrote:
> On Mon, Mar 30, 2015 at 7:31 AM, Rich Felker <dalias@libc.org> wrote:
>> For details on CVE-2015-1817, see:
>> http://www.openwall.com/lists/musl/2015/03/30/1
>>
>> With musl-linked Busybox installed setuid and ping enabled, exploiting
>> this issue is trivial.
>>
>> While CVE-2015-1817 is certainly musl's fault, there are two changes
>> to Busybox I'd like to propose that would have prevented it from being
>> exploitable:
>>
>> 1. Having setuid utilities like ping obtain the resource they need (in
>>    the case of ping, SOCK_RAW) without processing user input at all,
>>    then fully dropping root (setuid(getuid())) before doing anything.
>>    This has been standard practice for setuid programs since the 90s
>>    and it feels bad that busybox is not doing it.
>
> In general this is acceptable, but with this particular case
> and CVE, it wouldn't help.
>
> create_icmp_socket(lsa) needs to know of which address family
> the socket should be:
>
>         if (lsa->u.sa.sa_family == AF_INET6)
>                 sock = socket(AF_INET6, SOCK_RAW, IPPROTO_ICMPV6);
>         else
>                 sock = socket(AF_INET, SOCK_RAW, 1); /* 1 == ICMP */
>
> This is only known after HOST is parsed.
> And CVE is in DNS resolving code :(

One advantage if the traditional separation of ping and ping6.

>
>> 2. Reconsider the rejection of the patch to add SOCK_DGRAM support for
>>    ping, which allows it to run without root.
>
> This seems to lead to a significantly larger code.

Slightly larger code or security holes. Is it really that much bigger?

Justin

Re: Re: Busybox on musl is affected by CVE-2015-1817

[Rich Felker]

On Wed, Apr 01, 2015 at 12:11:18AM +0100, Justin Cormack wrote:
> On 31 March 2015 at 20:07, Denys Vlasenko <vda.linux@googlemail.com> wrote:
> > On Mon, Mar 30, 2015 at 7:31 AM, Rich Felker <dalias@libc.org> wrote:
> >> For details on CVE-2015-1817, see:
> >> http://www.openwall.com/lists/musl/2015/03/30/1
> >>
> >> With musl-linked Busybox installed setuid and ping enabled, exploiting
> >> this issue is trivial.
> >>
> >> While CVE-2015-1817 is certainly musl's fault, there are two changes
> >> to Busybox I'd like to propose that would have prevented it from being
> >> exploitable:
> >>
> >> 1. Having setuid utilities like ping obtain the resource they need (in
> >>    the case of ping, SOCK_RAW) without processing user input at all,
> >>    then fully dropping root (setuid(getuid())) before doing anything.
> >>    This has been standard practice for setuid programs since the 90s
> >>    and it feels bad that busybox is not doing it.
> >
> > In general this is acceptable, but with this particular case
> > and CVE, it wouldn't help.
> >
> > create_icmp_socket(lsa) needs to know of which address family
> > the socket should be:
> >
> >         if (lsa->u.sa.sa_family == AF_INET6)
> >                 sock = socket(AF_INET6, SOCK_RAW, IPPROTO_ICMPV6);
> >         else
> >                 sock = socket(AF_INET, SOCK_RAW, 1); /* 1 == ICMP */
> >
> > This is only known after HOST is parsed.
> > And CVE is in DNS resolving code :(
> 
> One advantage if the traditional separation of ping and ping6.

I'm against this separation. It relegates IPv6 addresses to
second-class status and this kind of treatment is part of the reason
why IPv6 support remains spotty. And you don't automatically know in
advance if a name is going to resolve to IPv4 or IPv6.

> >> 2. Reconsider the rejection of the patch to add SOCK_DGRAM support for
> >>    ping, which allows it to run without root.
> >
> > This seems to lead to a significantly larger code.
> 
> Slightly larger code or security holes.

Note that in this case it was at the libc level, but this could
equally have happened at the busybox level. Also the issue is not
exclusive to musl even at the libc level. I seem to recall there being
a few vulns in glibc's getaddrinfo over the past couple years which
may also have been affected.

> Is it really that much bigger?

I don't think so.

Rich

Re: Busybox on musl is affected by CVE-2015-1817

[Rich Felker]

On Tue, Mar 31, 2015 at 09:07:19PM +0200, Denys Vlasenko wrote:
> On Mon, Mar 30, 2015 at 7:31 AM, Rich Felker <dalias@libc.org> wrote:
> > For details on CVE-2015-1817, see:
> > http://www.openwall.com/lists/musl/2015/03/30/1
> >
> > With musl-linked Busybox installed setuid and ping enabled, exploiting
> > this issue is trivial.
> >
> > While CVE-2015-1817 is certainly musl's fault, there are two changes
> > to Busybox I'd like to propose that would have prevented it from being
> > exploitable:
> >
> > 1. Having setuid utilities like ping obtain the resource they need (in
> >    the case of ping, SOCK_RAW) without processing user input at all,
> >    then fully dropping root (setuid(getuid())) before doing anything.
> >    This has been standard practice for setuid programs since the 90s
> >    and it feels bad that busybox is not doing it.
> 
> In general this is acceptable, but with this particular case
> and CVE, it wouldn't help.

Sure it does.

> create_icmp_socket(lsa) needs to know of which address family
> the socket should be:
> 
>         if (lsa->u.sa.sa_family == AF_INET6)
>                 sock = socket(AF_INET6, SOCK_RAW, IPPROTO_ICMPV6);
>         else
>                 sock = socket(AF_INET, SOCK_RAW, 1); /* 1 == ICMP */
> 
> This is only known after HOST is parsed.
> And CVE is in DNS resolving code :(

The solution is simple: create both raw sockets and close the one you
don't need later. There's probably also a way to use the AF_INET6 raw
socket or IPv4 ping, but I don't know right off.

> > 2. Reconsider the rejection of the patch to add SOCK_DGRAM support for
> >    ping, which allows it to run without root.
> 
> This seems to lead to a significantly larger code.

I don't recall the exact amount, but given that busybox's suid
framework is not taking any precautions to mitigate the risks of suid
(not to mention that eliminating all suids is a goal of some
security-conscious systems integrators) I think it would be worth it
even if it doubled the size of the ping utility (which it does not).

Rich

Re: Re: Busybox on musl is affected by CVE-2015-1817

[u-wsnj]

On Tue, Mar 31, 2015 at 07:48:10PM -0400, Rich Felker wrote:
> > > 2. Reconsider the rejection of the patch to add SOCK_DGRAM support for
> > >    ping, which allows it to run without root.
> > 
> > This seems to lead to a significantly larger code.
> 
> I don't recall the exact amount, but given that busybox's suid
> framework is not taking any precautions to mitigate the risks of suid
> (not to mention that eliminating all suids is a goal of some
> security-conscious systems integrators)

Yes it is here (the goal).

Suid is a very old and nowadays quite redundant tool, mostly holding
ground due to its "simplicity" (say, compared to talking to a daemon)
and to the tradition. Seen from a different perspective, it is from the
pre-network epoch ("the computer is the universe") and enforces among
others hardcoded paths - which is a PITA for reusable and globally
placed software.

> I think it would be worth it
> even if it doubled the size of the ping utility (which it does not).

+1

Rune

Re: Re: Busybox on musl is affected by CVE-2015-1817

[Raphael Cohn]

[-- Attachment #1: Type: text/plain, Size: 1591 bytes --]

Rich, Justin, Rune: Seconded. The need for a discussion here is deeply
worrying. It's not smaller code if it's insecure code. And given two very
viable techniques, it seems moot.

Personally, I'd be in favour of the SOCK_DGRAM approach, as it eliminates
the need for setuid. How difficult would it be for someone to maintain this
patch in a forked BusyBox, or as a compile option (turned on by default)?
(I'd be happy to help with this). Is this something Alpine Linux might
consider?

On 1 April 2015 at 08:41, <u-wsnj@aetey.se> wrote:

> On Tue, Mar 31, 2015 at 07:48:10PM -0400, Rich Felker wrote:
> > > > 2. Reconsider the rejection of the patch to add SOCK_DGRAM support
> for
> > > >    ping, which allows it to run without root.
> > >
> > > This seems to lead to a significantly larger code.
> >
> > I don't recall the exact amount, but given that busybox's suid
> > framework is not taking any precautions to mitigate the risks of suid
> > (not to mention that eliminating all suids is a goal of some
> > security-conscious systems integrators)
>
> Yes it is here (the goal).
>
> Suid is a very old and nowadays quite redundant tool, mostly holding
> ground due to its "simplicity" (say, compared to talking to a daemon)
> and to the tradition. Seen from a different perspective, it is from the
> pre-network epoch ("the computer is the universe") and enforces among
> others hardcoded paths - which is a PITA for reusable and globally
> placed software.
>
> > I think it would be worth it
> > even if it doubled the size of the ping utility (which it does not).
>
> +1
>
> Rune
>
>

[-- Attachment #2: Type: text/html, Size: 2116 bytes --]

Re: Re: Busybox on musl is affected by CVE-2015-1817

[Harald Becker]

Hi !

On 01.04.2015 09:41, u-wsnj@aetey.se wrote:
> Suid is a very old and nowadays quite redundant tool, mostly holding
> ground due to its "simplicity" (say, compared to talking to a daemon)
> and to the tradition. Seen from a different perspective, it is from the
> pre-network epoch ("the computer is the universe") and enforces among
> others hardcoded paths - which is a PITA for reusable and globally
> placed software.

IMO suid and sgid has there advantage over complex communication with 
separate running daemons, but there is one topic, which is missed by so 
many discussions about this: There is a big difference if you talk about 
suid *root* programs or other suid usage.

The former is definitely very dangerous and should be used with extreme 
care (I think this is the case we are talking about), the later use may 
even be used to drop privileges (not to raise), or to temporarily hop to 
the privileges of a different user (may be allowing access to some files 
only by using specific commands).

When used with care and as intended, suid and sgid is a nice feature, 
but nowadays there are too many Unix novices, who misunderstand or 
misuse this, punching big holes in every security concern.


>> I think it would be worth it
>> even if it doubled the size of the ping utility (which it does not).
> +1

ACK +1

--
Harald

Re: Re: Busybox on musl is affected by CVE-2015-1817

[u-wsnj]

Hi Harald,

On Wed, Apr 01, 2015 at 10:11:51AM +0200, Harald Becker wrote:
> There is a big difference if you talk about suid
> *root* programs or other suid usage.
> 
> The former is definitely very dangerous and should be used with extreme care
> (I think this is the case we are talking about), the later use may even be
> used to drop privileges (not to raise), or to temporarily hop to the

You are right about a remarkable difference between suid root and suid
somethingelse, just because root has the very special role in Unix.
Besides root vs non-root I doubt there is any clear line between "raising"
and "dropping" privileges, you replace one set of allowed operations by
a different one, that's it. Note that root does not need suid to drop
its privileges.

> privileges of a different user (may be allowing access to some files only by
> using specific commands).

As soon as a program is setuid it has to be written for the purpose
of very reliably checking and limiting what it does on behalf of who,
independently of how it can potentially be invoked "out of context".
This is known to be hard, I believe it is harder to do reliably than
e.g. issue a request to a daemon - talking about the complexity level.

Thus the setuid program is to be designed to be as small as possible,
presumably leaving all non-checking functions to (a) different
executable(s). Then the result becomes about as intricate as talking to
a daemon, which can be run without any setuid.

> When used with care and as intended, suid and sgid is a nice feature, but

Unfortunately I can not really appreciate its beauty which appears to hide
the complexity and/or move it to other parties (like the dynamic linker
or the software maintenance infrastructure). Yes it "looks simple and
efficient" but is it, really?

> nowadays there are too many Unix novices, who misunderstand or misuse this,
> punching big holes in every security concern.

Unfortunately even seasoned gurus easily create / fail to notice holes!
:(

Rune

Re: Re: Busybox on musl is affected by CVE-2015-1817

[Harald Becker]

Hi !

On 01.04.2015 10:49, u-wsnj@aetey.se wrote:
> Note that root does not need suid to drop its privileges.

Yes, but may benefit from the simplicity to do the drop:

Consider a suid program to a low privileged user, whenever that program
is called from any root process, the called program automatically drops
it's privileges. So you do not need to drop privileges in every possible
caller.


>> privileges of a different user (may be allowing access to some
>> files only by using specific commands).
>
> As soon as a program is setuid it has to be written for the purpose
> of very reliably checking and limiting what it does on behalf of
> who, independently of how it can potentially be invoked "out of
> context".

ACK. Any program going to be used with suid, or sgid has to be designed
for this.

> This is known to be hard, I believe it is harder to do reliably than
> e.g. issue a request to a daemon - talking about the complexity
> level.

Hard? A single getuid() call gives the user id of the calling user (real 
user id), where the program runns with the priviledges of the effective 
user (geteuid). So you can pick the real user id and check this against 
a list of allowed users; same to getgid().

In addition: suid programs should set the owning group and permisions
carefully, e.g. fileuser:accessgroup owner=suid+x, group=x, other=none;
where the directories and files are owned by fileuser, with permissions
only to that user and nobody else.

A simple mechanism giving you a shield protecting your data from being 
tampered by any other users programs (except root), but still all users 
which are a member of group accessgroup can use your program, and access 
the data in the intended manner.


> Thus the setuid program is to be designed to be as small as
> possible, presumably leaving all non-checking functions to (a)
> different executable(s).

True, for suid *root* programs, but otherwise I doubt. I see no such
need in e.g. the example above.


> Then the result becomes about as intricate as talking to a daemon,
> which can be run without any setuid.

I never told talking to a daemon is of no use, but many suid usages are 
possible without the daemon overhead, and still not risking security 
violations.

The big flaws are:

a) setting suid for a program never designed for that use

b) suid *root* (flaw by design)

IMO the case b should be blocked by the kernel and replaced with a more 
reliable reaction:

Whenever the kernel detects a suid *root* program, it does not start 
that program, but picks a configured path, for a statically linked 
binary, with owner root, only executable by root, and no permissions to 
others. That program shall be started by the kernel, giving the path to 
the called program as first argument, then the remaining arguments.

This single *real suid root* program get than control (single point of 
failure), and has to do the security relevant part (as you mentioned 
above). Only when there is no doubt of usage, this single program drops 
the privileges to the determined / required user, and then exec to the 
intended program.

In other words, any program marked suid root is automatically invoked 
through a program like sudo, which does the security checking, before 
invoking any other code ... but without need of manually reentering that 
sudo command on every program invocation.

This would be a very simple change in the kernel, giving a big step to 
more security ... but still such things are missing :(


>> When used with care and as intended, suid and sgid is a nice
>> feature, but
>
> Unfortunately I can not really appreciate its beauty which appears to
> hide the complexity and/or move it to other parties (like the dynamic
> linker or the software maintenance infrastructure). Yes it "looks
> simple and efficient" but is it, really?

Not talking about suid *root*, which difficulties do you see? It's 
beauty lies in it's simplicity and efficiency, but it's danger in the 
widely misunderstanding and unintended usage.


>> nowadays there are too many Unix novices, who misunderstand or
>> misuse this, punching big holes in every security concern.
>
> Unfortunately even seasoned gurus easily create / fail to notice
> holes! :(

We are all humans and make mistakes, but a lot of those gurus forget 
about this ... ok, they are gurus and no more humans ;)

See above: suid to *not root* is ok, suid *root* is flaw by design :(

Harald

Re: Re: Busybox on musl is affected by CVE-2015-1817

[Рысь]

On Thu, 02 Apr 2015 15:56:04 +0200
Harald Becker <ralda@gmx.de> wrote:

> Hi !
> 
> On 01.04.2015 10:49, u-wsnj@aetey.se wrote:
> > Note that root does not need suid to drop its privileges.
> 
> Yes, but may benefit from the simplicity to do the drop:
> 
> Consider a suid program to a low privileged user, whenever that
> program is called from any root process, the called program
> automatically drops it's privileges. So you do not need to drop
> privileges in every possible caller.
> 
> 
> >> privileges of a different user (may be allowing access to some
> >> files only by using specific commands).
> >
> > As soon as a program is setuid it has to be written for the purpose
> > of very reliably checking and limiting what it does on behalf of
> > who, independently of how it can potentially be invoked "out of
> > context".
> 
> ACK. Any program going to be used with suid, or sgid has to be
> designed for this.
> 
> > This is known to be hard, I believe it is harder to do reliably than
> > e.g. issue a request to a daemon - talking about the complexity
> > level.
> 
> Hard? A single getuid() call gives the user id of the calling user
> (real user id), where the program runns with the priviledges of the
> effective user (geteuid). So you can pick the real user id and check
> this against a list of allowed users; same to getgid().
> 
> In addition: suid programs should set the owning group and permisions
> carefully, e.g. fileuser:accessgroup owner=suid+x, group=x,
> other=none; where the directories and files are owned by fileuser,
> with permissions only to that user and nobody else.
> 
> A simple mechanism giving you a shield protecting your data from
> being tampered by any other users programs (except root), but still
> all users which are a member of group accessgroup can use your
> program, and access the data in the intended manner.
> 
> 
> > Thus the setuid program is to be designed to be as small as
> > possible, presumably leaving all non-checking functions to (a)
> > different executable(s).
> 
> True, for suid *root* programs, but otherwise I doubt. I see no such
> need in e.g. the example above.
> 
> 
> > Then the result becomes about as intricate as talking to a daemon,
> > which can be run without any setuid.
> 
> I never told talking to a daemon is of no use, but many suid usages
> are possible without the daemon overhead, and still not risking
> security violations.
> 
> The big flaws are:
> 
> a) setting suid for a program never designed for that use
> 
> b) suid *root* (flaw by design)
> 
> IMO the case b should be blocked by the kernel and replaced with a
> more reliable reaction:
> 
> Whenever the kernel detects a suid *root* program, it does not start 
> that program, but picks a configured path, for a statically linked 
> binary, with owner root, only executable by root, and no permissions
> to others. That program shall be started by the kernel, giving the
> path to the called program as first argument, then the remaining
> arguments.
> 
> This single *real suid root* program get than control (single point
> of failure), and has to do the security relevant part (as you
> mentioned above). Only when there is no doubt of usage, this single
> program drops the privileges to the determined / required user, and
> then exec to the intended program.
> 
> In other words, any program marked suid root is automatically invoked 
> through a program like sudo, which does the security checking, before 
> invoking any other code ... but without need of manually reentering
> that sudo command on every program invocation.
> 
> This would be a very simple change in the kernel, giving a big step
> to more security ... but still such things are missing :(

Please *do not* touch setuid when it may save time and you from
headcrash course when you appeared to lock yourself and your (embedded)
device, for example. This already failed with selinux phones.

Nobody is vulnerable when you don't have setuid executables or mounted
nosuid. No need to change the kernel.

Because someone does not care about your security does not mean that
you should accept and inherit that. 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().

FYI I already implemented such a scheme and program and quite happy with
it and I always know which executable is setuid on my system. It even
has a rules which control various objects of access. The *only* problem
is that writing such a program is a big pain because your code will be
searched often for security bugs. So I'm in doubts.

> 
> 
> >> When used with care and as intended, suid and sgid is a nice
> >> feature, but
> >
> > Unfortunately I can not really appreciate its beauty which appears
> > to hide the complexity and/or move it to other parties (like the
> > dynamic linker or the software maintenance infrastructure). Yes it
> > "looks simple and efficient" but is it, really?
> 
> Not talking about suid *root*, which difficulties do you see? It's 
> beauty lies in it's simplicity and efficiency, but it's danger in the 
> widely misunderstanding and unintended usage.
> 
> 
> >> nowadays there are too many Unix novices, who misunderstand or
> >> misuse this, punching big holes in every security concern.
> >
> > Unfortunately even seasoned gurus easily create / fail to notice
> > holes! :(
> 
> We are all humans and make mistakes, but a lot of those gurus forget 
> about this ... ok, they are gurus and no more humans ;)
> 
> See above: suid to *not root* is ok, suid *root* is flaw by design :(
> 
> Harald

Re: Re: Busybox on musl is affected by CVE-2015-1817

[Harald Becker]

On 02.04.2015 19:26, Рысь wrote:
> Please *do not* touch setuid when it may save time and you from
> headcrash course when you appeared to lock yourself and your (embedded)
> device, for example. This already failed with selinux phones.

This was just a few theoretical words about that suid *root* problem:

Even if anybody would add this to the Linux kernel, it would only affect 
suid *root* programs, and run them through a wrapper program, something 
like sudo. Any other suid, and sgid would not be affected


> Nobody is vulnerable when you don't have setuid executables or mounted
> nosuid. No need to change the kernel.

Nobody talked about loosing the possibility to mount, etc. ... my 
suggestion would just work, as you start any such command with a sudo 
prefix and than let sudo decide if you are allowed to do the operation.

Think of not enabling suid *root* mount for all user, but let a wrapper 
check if the user is allowed to do the operation, and if so, proceed to 
this as expected, let some others require to enter a password, and deny 
the rest (depending on what is configured for your system).


> Because someone does not care about your security does not mean that
> you should accept and inherit that. 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().

This is what I'm currently doing, on my systems: A small wrapper checks 
some things, and proceed to the called program afterwards. So I do have 
only one suid *root* program, except some system related stuff from a 
distro.

Except that my suggestion would just run such a wrapper automatically 
for suid *root* programs, it can easily be disabled in the kernel (via a 
sysctl setting). So this would be an optional security approach, for 
those who like this wrapper idea.

... but:

The discussion was, about the sense of suid, and I wanted to note, the 
difference between suid *root* and suid *any other user*.


> FYI I already implemented such a scheme and program and quite happy with
> it and I always know which executable is setuid on my system. It even
> has a rules which control various objects of access. The *only* problem
> is that writing such a program is a big pain because your code will be
> searched often for security bugs. So I'm in doubts.

And this is one of the reasons for my suggestion, all that would benefit 
from a central wrapper, which is able to do sanity checks and reject the 
most common caveats, e.g. letting suid *root* programs be writable by 
anybody else than root. This central wrapper would be more easy to 
inspect for security violations than every other program (more eyes on a 
single part = higher security).

... but this was all theoretical: How I would try to solve some of the 
known suid *root* problems.

Harald

Re: Re: Busybox on musl is affected by CVE-2015-1817

[Рысь]

On Thu, 02 Apr 2015 20:16:22 +0200
Harald Becker <ralda@gmx.de> wrote:

> On 02.04.2015 19:26, Рысь wrote:
> > Please *do not* touch setuid when it may save time and you from
> > headcrash course when you appeared to lock yourself and your
> > (embedded) device, for example. This already failed with selinux
> > phones.
> 
> This was just a few theoretical words about that suid *root* problem:
> 
> Even if anybody would add this to the Linux kernel, it would only
> affect suid *root* programs, and run them through a wrapper program,
> something like sudo. Any other suid, and sgid would not be affected
> 

Well and losing a maybe crufty, cheaty but *always* working mechanism
which is expected to work on every Unix system. I think there is no
such a problem as setuid problem, root or user, when it is properly
handled.

(Sorry if it's too ranty, but I already eaten by all this security dance
on recent android phones)

> 
> > Nobody is vulnerable when you don't have setuid executables or
> > mounted nosuid. No need to change the kernel.
> 
> Nobody talked about loosing the possibility to mount, etc. ... my 
> suggestion would just work, as you start any such command with a sudo 
> prefix and than let sudo decide if you are allowed to do the
> operation.
> 
> Think of not enabling suid *root* mount for all user, but let a
> wrapper check if the user is allowed to do the operation, and if so,
> proceed to this as expected, let some others require to enter a
> password, and deny the rest (depending on what is configured for your
> system).
> 

I don't follow. I talked previous about disabling all setuids just by:

	mount -o remount,nosuid /some/mount

in your rc.local, or adding (on sane systems) "nosuid" flag to fstab.

Or just 

	find / -xdev -perm -4000 -exec ls -l '{}' ';'

and select which you want to disable. (and same with -2000 for setgids)

And yes, for other part about wrapper, this already works, but without
any requirement to patch the kernel or making this patch mandatory. The
wrapper even setups sane environment, overwrites argv0 when needed and
programs not tied to /proc/self/exe checks or similar just work as
expected.

> 
> > Because someone does not care about your security does not mean that
> > you should accept and inherit that. 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().
> 
> This is what I'm currently doing, on my systems: A small wrapper
> checks some things, and proceed to the called program afterwards. So
> I do have only one suid *root* program, except some system related
> stuff from a distro.
> 
> Except that my suggestion would just run such a wrapper automatically 
> for suid *root* programs, it can easily be disabled in the kernel
> (via a sysctl setting). So this would be an optional security
> approach, for those who like this wrapper idea.

How about porting to other systems? There are ones with hardwired
assumptions about setuid all over their userspace source code. Of
course they maybe changed, but it will take *much* longer time than
just disable all setuids on average Linux system and forward them
through wrapper.

> 
> ... but:
> 
> The discussion was, about the sense of suid, and I wanted to note,
> the difference between suid *root* and suid *any other user*.
> 

setuid other user can be as same evil as setuid root.

> 
> > FYI I already implemented such a scheme and program and quite happy
> > with it and I always know which executable is setuid on my system.
> > It even has a rules which control various objects of access. The
> > *only* problem is that writing such a program is a big pain because
> > your code will be searched often for security bugs. So I'm in
> > doubts.
> 
> And this is one of the reasons for my suggestion, all that would
> benefit from a central wrapper, which is able to do sanity checks and
> reject the most common caveats, e.g. letting suid *root* programs be
> writable by anybody else than root. This central wrapper would be
> more easy to inspect for security violations than every other program
> (more eyes on a single part = higher security).

Maybe. I still not sure about it.

> 
> ... but this was all theoretical: How I would try to solve some of
> the known suid *root* problems.
> 
> Harald
> 

Well apart of modifying kernel for no reason this are good ideas if a
wrapper is simple enough to review. But more things evolve you need to
care about for programs then more you need code to add and more
potential bugs. But maybe it's just my impression because I did spent a
year developing one alone.

Re: Re: Busybox on musl is affected by CVE-2015-1817

[Harald Becker]

Hi,
I don't want to follow this discussion into deep. It was a pure 
theoretical suggestion, and I don't think anybody is going to change 
something on this.

... but please read complete, you did something misunderstand:

On 03.04.2015 06:40, Рысь wrote:
>> Even if anybody would add this to the Linux kernel, it would only
>> affect suid *root* programs, and run them through a wrapper program,
>> something like sudo. Any other suid, and sgid would not be affected
>
> Well and losing a maybe crufty, cheaty but *always* working mechanism
> which is expected to work on every Unix system. I think there is no
> such a problem as setuid problem, root or user, when it is properly
> handled.

And what about, the kernel does this only, when a wrapper is configured 
(e.g by a sysctl like hotplug handler)? If you do not write anything to 
the sysctl variable you get the plain old suid *root* operation, but 
when the name of a wrapper program has been written to the sysctl 
variable *and* this program is not writable by any other than root, it 
does run through the wrapper ... *and* (in addition) when you write a 
"locked" to the sysctl variable, this feature can get locked in it's 
current state and no one may do further changes to this setting until 
kernel restart (for those who fear).

... let you get all you like, without hitting anyone staying on current 
behavior.


> (Sorry if it's too ranty, but I already eaten by all this security dance
> on recent android phones)

I hate overdone security too. Beside being theoretical, my intention was 
an "optional" feature for those who like.


> I don't follow. I talked previous about disabling all setuids just by:
> 	mount -o remount,nosuid /some/mount

This is something completely different, in no way affected by my 
intention ... but disables all suid usage, also suid to *none root*.


> And yes, for other part about wrapper, this already works, but without
> any requirement to patch the kernel or making this patch mandatory.

... but then you need to call the wrapper explicitly for each command, 
or replacing the command with a script calling the wrapper, loosing the 
possibility to block unintended suid *root* usage.


> How about porting to other systems? There are ones with hardwired
> assumptions about setuid all over their userspace source code. Of
> course they maybe changed, but it will take *much* longer time than
> just disable all setuids on average Linux system and forward them
> through wrapper.

a) differentiate between suid *root* and *suid none root*
    (the later won't get effected ever)

b) my intention was an optional feature, for those who like,
    but it will only work with some slight help of the kernel,
    not affecting anybody who does not activate this


> setuid other user can be as same evil as setuid root.

When misdone, yes! Don't use it if you don't like it.


> Well apart of modifying kernel for no reason this are good ideas if a
> wrapper is simple enough to review. But more things evolve you need to
> care about for programs then more you need code to add and more
> potential bugs. But maybe it's just my impression because I did spent a
> year developing one alone.

When we talk here about a wrapper, please think of something like sudo, 
which is configurable, so any new program mean adding this program to 
the configuration, not more code to write.

... and the intended wrapper feature will only work with a little help 
of the kernel (else there is no increased security):

Currently it does (rough):

if program to exec is not suid
   exec the program with args
else
   save real user id
   switch effective user id to the owner of the program
   exec the program with args

My intention would be:

if program to exec is not suid
   exec the program with args
else
   save real user id
   switch effective user id to the owner of the program
   if program owner is root and wrapper program configured
     exec wrapper with name of program plus args
   else
     exec the program with args

Where the wrapper does the security checking then exec to program with 
args, but may reject invocation before any code of the given program is 
executed.

This was my suggestion. How would that hit anybody in any way, who does 
not write a wrapper name to the sysctl variable?

Harald

Re: Re: Busybox on musl is affected by CVE-2015-1817

[u-wsnj]

On Fri, Apr 03, 2015 at 12:26:56AM +0700, Рысь wrote:
[Harald Becker wrote]
> > This would be a very simple change in the kernel, giving a big step
> > to more security ... but still such things are missing :(

[answering to Harald Becker]
Credentials handling in the kernel is a result of a very long evolution
and efforts for making the behaviour both relatively consistent and
conforming to its documented standard definition.

If you believe that such a change can be simple and easily contained in
scope, you fall for wishful thinking.
Unix is monolithic by design, it is extremely hard to improve without
throwing out its design or otherwise hitting lots of issues in very
different places where you inadvertently would break someone else's
assumptions. Linux did not throw out the design and thus had to preserve
lots of problems and limitations, for a reason.

On Fri, Apr 03, 2015 at 12:26:56AM +0700, Рысь 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().

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.

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.

For me this does not look like a solution, rather like a patchwork
which may or may not be effective.

Rune

Re: Re: Busybox on musl is affected by CVE-2015-1817

[Рысь]

On Thu, 2 Apr 2015 20:36:27 +0200
u-wsnj@aetey.se wrote:

> On Fri, Apr 03, 2015 at 12:26:56AM +0700, Рысь 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().
> 
> 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.

> 
> 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.
> 
> For me this does not look like a solution, rather like a patchwork
> which may or may not be effective.
> 
> Rune
> 

[OT] setuid (Re: Busybox on musl is affected by CVE-2015-1817)

[u-wsnj]

On Fri, Apr 03, 2015 at 11:51:58AM +0700, Рысь wrote:
> Unix credentials were always somewhat limited

Exactly.

Set*id was created to complement the poor authorization means in the
kernel (acls limited to three permissions and crippled to exactly
three group-like entries with restricted semantics, for implementation
efficiency reasons).

It (set*id) is a very powerful, general and wide reaching tool intended in
contrast for special and varying situations which need specific treatment,
that's why it needs extreme skills and care at every use.

This does not scale.

Rune

Re: Re: Busybox on musl is affected by CVE-2015-1817

[Rich Felker]

On Wed, Apr 01, 2015 at 10:49:40AM +0200, u-wsnj@aetey.se wrote:
> Hi Harald,
> 
> On Wed, Apr 01, 2015 at 10:11:51AM +0200, Harald Becker wrote:
> > There is a big difference if you talk about suid
> > *root* programs or other suid usage.
> > 
> > The former is definitely very dangerous and should be used with extreme care
> > (I think this is the case we are talking about), the later use may even be
> > used to drop privileges (not to raise), or to temporarily hop to the
> 
> You are right about a remarkable difference between suid root and suid
> somethingelse, just because root has the very special role in Unix.

The difference is there but it's not as remarkable as you think. As
soon as you can get control of uid==suid_target_uid, you can do nasty
things as that user like modifying the binary that's suid to that
user, so that the next user who invokes it invokes malicious code.
suid is pretty much across-the-board evil.

> Besides root vs non-root I doubt there is any clear line between "raising"
> and "dropping" privileges, you replace one set of allowed operations by
> a different one, that's it. Note that root does not need suid to drop
> its privileges.

"Dropping" privileges in the sense of suid just means setting the
effective and saved uids for the process to the real (invoking,
returned by getuid()) uid.

> > privileges of a different user (may be allowing access to some files only by
> > using specific commands).
> 
> As soon as a program is setuid it has to be written for the purpose
> of very reliably checking and limiting what it does on behalf of who,
> independently of how it can potentially be invoked "out of context".
> This is known to be hard, I believe it is harder to do reliably than
> e.g. issue a request to a daemon - talking about the complexity level.

Yes. Said differently, the difference is a huge and perpetually
expanding attack surface (all process state inheritable across exec)
versus a tiny attack surface (one unix socket).

Please don't misinterpret this -- I'm not saying that busybox should
be implementing a "ping daemon". Rather we should be using the
functionality the kernel gave us for avoiding suid (SOCK_DGRAM ICMP)
when it's available and making it possible for users to get a fully
functional busybox without the need for suid.

> > When used with care and as intended, suid and sgid is a nice feature, but
> 
> Unfortunately I can not really appreciate its beauty which appears to hide
> the complexity and/or move it to other parties (like the dynamic linker
> or the software maintenance infrastructure). Yes it "looks simple and
> efficient" but is it, really?

It's not.

> > nowadays there are too many Unix novices, who misunderstand or misuse this,
> > punching big holes in every security concern.
> 
> Unfortunately even seasoned gurus easily create / fail to notice holes!
> :(

I'd much rather eliminate the opportunity for the hole from the start.

Rich

Re: Re: Busybox on musl is affected by CVE-2015-1817

[u-wsnj]

On Thu, Apr 02, 2015 at 11:38:25AM -0400, Rich Felker wrote:
> > Unfortunately I can not really appreciate its beauty which appears to hide
> > the complexity and/or move it to other parties (like the dynamic linker
> > or the software maintenance infrastructure). Yes it "looks simple and
> > efficient" but is it, really?
> 
> It's not.

This was intended to be a rhetorical question
but a clear statement surely does not hurt.

> > Unfortunately even seasoned gurus easily create / fail to notice holes!
> > :(
> 
> I'd much rather eliminate the opportunity for the hole from the start.

Exactly. Honestly this is what I meant.

Rune