tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Privilege dropping for rtadvd



Hi,

I'm not sure if people might agree with this, but I'm interested
in having a dedicated user for rtadvd after it's done acquiring
the socket.

OpenBSD already does that:
http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/rtadvd/rtadvd.c.diff?r1=1.35;r2=1.36

Linux's radvd goes further and implements privilege separation:

Changes since 1.0:
     *  Implement privilege separation on Linux: a master root process 
(which is able to reconfigure interfaces) and the main process. There 
is '-s' toggle to keep old behaviour.

(http://lists.litech.org/pipermail/radvd-devel-l/2008-February/000307.html)

This helped in migitation at least one security issue in the case of radvd.

From: http://www.openwall.com/lists/oss-security/2011/10/06/3:

1) A privilege escalation flaw was found in radvd, due to a buffer overflow
in the process_ra() function.  ND_OPT_DNSSL_INFORMATION option parsing
"label_len" was not checked for negative values, leading to a "suffix"
buffer overflow which can lead to privilege escalation, at least if
radvd is compiled without GCC's stack protection. If radvd is invoked
without privilege separation (the -u option), this can lead to an
escalation to root privileges.  Note: Red Hat Enterprise Linux starts
radvd by default with the unprivileged user. (CVE-2011-3601)

I'm not saying that netbsd's rtadvd has a security issue, but I think it would
help mitigate one if we drop privileges.

What do you guys think about this ?


Home | Main Index | Thread Index | Old Index