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 for Android: free password hash cracker in your pocket
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20050711235356.V17633@zarathustra.linux666.com>
Date: Tue Jul 12 01:27:37 2005
From: ronvdaal at zarathustra.linux666.com (ronvdaal)
Subject: Possible security issue with FreeBSD 5.4 jailing
	and BPF

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


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)

The problem lies within the FreeBSD 5.x BPF kernel code:

"The Berkeley Packet Filter provides a raw interface to data link layers
in a protocol independent fashion. The function bpfopen() opens an
Ethernet device. There is a conditional which disallows any jailed
processes from accessing this function."

This conditional was present in the 4.x series kernels but is missing
in 5.x and thus allowing free access to bpfopen() from within a jailed
environment. I think this is related to the changed jailing code between
these kernels. I don't believe this has been left out on purpose in favor
of devfs rulesets (...) If not, I'd like to have some comments on this.


Example:

jail# uname -a
FreeBSD jail 5.4-RELEASE FreeBSD 5.4-RELEASE #0: Sun May  8 10:21:06 UTC
2005     root@...low.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386

The ethernet interface of the host (parent) is not in promiscious mode.
The interface of the jailed environment isn't in promiscious mode either:

jail# ifconfig | grep fxp0
fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500


Now starting tcpdump in the jail:

jail# tcpdump -i fxp0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on fxp0, link-type EN10MB (Ethernet), capture size 96 bytes


Checking the interface again within the jail:

jail# ifconfig | grep fxp0
fxp0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500

The interface is running in promiscious mode.


The host environment shows that the tcpdump process runs in a jail:

root@...tzsche# ps aux|grep tcpdump
root     50551  0.0  0.9  3784  2248  p4  S+J   8:37PM   0:00.04 tcpdump
- -i fxp0

The P_JAILED flag is set.


Conclusion:

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?


Grt,

Ron van Daal
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (FreeBSD)

iD8DBQFC0uqKPnak7KhYV34RAjt2AKC29hdalgifPJ9VLuc2wYKisH2JZQCfeiRA
xSkUtJ1vWa3mDKt4dwk485Q=
=fUfG
-----END PGP SIGNATURE-----

Powered by blists - more mailing lists