On 2008-11-06, Stuart Henderson wrote:
On 2008-11-05, Limaunion <[EMAIL PROTECTED]> wrote:
Hi, for some reason my OpenBSD 4.4 firewall is been able to negotiate dhcp request although there are no rules that allow this operation.

dhcp uses BPF (like tcpdump does), this is below PF and is not
restricted by PF.

Fortunately, the OpenBSD dhclient goes into a lot of pains to reduce the impact of a security vulnerability in itself.

It employs privilege separation, using two processes one privileged and one running with no privileges, chrooted to an empty directory.

The privileged process does configuration of IP addresses, routes, DNS configuration etc, by communicating with the unprivileged process.

The unprivileged process has a connection (file descriptor) to the BPF interface. Before dropping privileges, it first sets up filters that restrict the kind of packets it can receive *and send* through the BPF interface, and locks in these filter settings so that they can not be changed.

If the unprivileged process gets compromised while doing its dirty work of parsing network packets it can only send and receive DHCP packets on a specific interface, as restricted by the filter (it can not even spoof its MAC address). This is much better than full network sniffing and arbitrary packet injection on *any* interface, that an unfiltered/unlocked BPF descriptor allows. A compromised process can also modify interface settings, routes or DNS configuration through the privileged process, but by using DHCP you already give this power over to some unauthenticated entity on your local network anyway.


Enjoy

Can

PS: We tried to restrict (and audit) every BPF using program in the base system using the mechanisms described above. Even tcpdump requires root to run so that it can properly drop privileges. Parsing raw network data, even from a file, provides an opportunity to inject incredible amounts of malicious input to the parser. That is also one reason we do not have ethereal/wireshark in ports. The last time I looked, they had a lot of parsers and an incredible amount of complex code tied to that stream of malicious input.

Reply via email to