full-disclosure - Possible security issue with FreeBSD 5.4 jailing and BPF

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue Jul 12 13:38:57 2005
From: simon at FreeBSD.org (Simon L. Nielsen)
Subject: Possible security issue with FreeBSD 5.4
	jailing and BPF

On 2005.07.12 13:20:06 +0200, ronvdaal wrote:

> >>While playing around with FreeBSD 5.4 and jailing I discovered that it was
> >>possible to put an ethernet interface into promiscious mode from within 
> >>the
> >>jailed environment, allowing a packetsniffer to gather data not meant for
> >>the jailed box. This also affects FreeBSD 5.3 (tested) but not FreeBSD 4.x
> >>This can be reproduced on boxes where BPF support is enabled in the kernel
> >>and a BPF device is available in the jail (badly configured devfs/no 
> >>rules)
> >[...]
> >>Usage of devfs rulesets is highly recommended as stated in the manpages.
> >>Though a misconfiguration at this point would expose a big security issue.
> >>The question is: should bpfopen() in bpf.c check for a jailed proc or not?
> >
> >This is not really a security bug since, as stated in the jail(8)
> >manual, you should use devfs rulesets if you are using jails as a
> >security measure.  Exposing a complete /dev file-system inside a jail
> >is a bad idea security wise, not just with regards to BPF.
> 
> I'm figuring out the reason why the jailing check has been removed from the
> BPF code in the kernel source tree (if on purpose). Does this have a reason?
> Because it was right there in the 4.x series kernels. And it's also present 
> in other parts of the 5.x kernel source. Therefore it seems to be forgotten.
> 
> While saying that this isn't a security bug, you're actually stating this
> has turned into a "feature", allowing the privileged user on the host box to
> decide which jailed root user can put ethernet devices into promiscious 
> mode.

Yes, it could be considered a feature since you might want to use
jails to partially restrict a program that needs BPF access (and of
cause you would be aware of the different tradeoff's while doing
that).

The commit that removed the explicit jail check:

http://cvsweb.FreeBSD.org/src/sys/net/bpf.c#rev1.77 :

	Remove unnecessary jail() check in bpfopen() -- we limit
	device access in jail using /dev namespace limits and mknod()
	limits, not by explicit checks in the device open code.

> (...) However, if it's a feature not a bug - then where is it documented?

I don't think this change is documented anywhere, but I can't really
see where it should be documented since it's just a change in behavior
between two FreeBSD major versions.

Anyway, if you want to discuss this further I would suggest you mail
one of the appropriate FreeBSD mailing lists.

-- 
Simon L. Nielsen
FreeBSD Security Team
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050712/905b377c/attachment.bin