Denys Vlasenko wrote:
On Mon, Jan 6, 2014 at 5:03 PM, John Spencer
<[email protected]> wrote:
i've been able to get the SOCK_DGRAM stuff to work with a little help of
Vasily, author of the kernel patch.
see attached proof-of-concept patch.
i'm aware that it doesnt use xbind() and other busybox replacement funcs.
getting it into a more busybox-ish shape is something i leave as a task for
someone more familiar with the busybox internals.
note that i didn't test if the added getsockopt calls are strictly needed, i
added them because they were in the original iputils patch.
in general the following differences exist between SOCK_RAW and SOCK_DGRAM
handling:
1) the received packet is a raw icmp packet, not an IP one, so it lacks the
header and is shorter.
2) the ident (myid) of the packet is sin(6)_port of the sockaddr struct
after doing a bind() and getsockname() on the dgram socket.
the patch works for both "fancy" ping(6), and "non-fancy" ping(6) (the
latter just sends one packet and displays whether it was successful or not,
without further info).
This seems to lead to a significantly larger code.
Making ping suid wasn't such a big problem before, so
why should we have all these complications now?
making ping suid in the context of busybox basically means "make the
entire busybox binary suid" and that is definitely a bad idea (an
example that comes to mind is the wall vulnerability discovered
recently). you can only build ping as a separate applet when you use
dynamic linking, which leads to dozens new attack vectors and gives the
attacker access to the entire libc. in my distribution, there is only a
single (static) suid binary, and that is a selfwritten su implementation
that's selfcontained in a single TU with ~150 LOC. so it is very simple
to audit for security bugs. one could even get rid of that and make a su
script that just calls "ssh localhost" with appropriate parameters. the
openwall distribution owl, from which the kernel patch originated, has
zero suid binaries.
i think if a busybox specialist reshapes the POC code slightly (for
example by putting the bind code to get "myid" from the port into a
common function used by v4/v6 code), the size increase could be brought
down to less than 200 bytes. maybe using an optional config feature for
CONFIG_PING_DGRAM.
--JS
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
