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