Re: FreeBSD Security Advisory FreeBSD-SA-06:22.openssh
On Mon, Oct 02, 2006 at 02:25:05PM -0700, Colin Percival wrote: Theo de Raadt wrote: The OpenSSH project believe that the race condition can lead to a Denial of Service or potentially remote code execution ^ Bullshit. Where did anyone say this? The OpenSSH 4.4 release announcement says that, actually: * Fix an unsafe signal hander reported by Mark Dowd. The signal handler was vulnerable to a race condition that could be exploited to perform a pre-authentication denial of service. On portable OpenSSH, this vulnerability could theoretically lead to ^^ pre-authentication remote code execution if GSSAPI authentication is enabled, but the likelihood of successful exploitation appears remote. Theo: Maybe you should put people in charge who can read their own release announcements before flaming a mailing list. ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Security Survey
On Wed, May 24, 2006 at 11:20:08AM +0100, Craig Edwards wrote: I agree, however, i do not like the gentoo dependency upon python for its package management system. It has not broken on me yet, however i can imagine if it does it would be a nightmare to fix, as python is not a trivial program. If FreeBSD ever were to attempt an emerge-like system, it would be convenient imho (although probably less maintainable?) to have it done in something smaller and easier to manage (and easier repair when broken?) such as perl or shellscript. Python is incredibly trivial. It's much more trivial than perl, that's for sure. I don't want to get into a holy war about languages on-list (anyone interested can email me off list). Having used perl for 5+ years, and starting to use Python in the last year, I can tell you that Python has a very similar learning curve, but is better for new (and old) programmers for several reasons: Much more consistant syntax - From this you get code that is easier to read, more portable between developers, etc Designed to be object oriented rather than OO being an after thought These two things alone (IMO) make a HUGE difference to writing apps of any size. Plus Python's traceback feature is really awesome (perl may have one, I haven't seen it, but with python it's just there, always). ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to [EMAIL PROTECTED]
[ronvdaal@zarathustra.linux666.com: Possible security issue with FreeBSD 5.4 jailing and BPF]
This message was sent to bugtraq today: 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 [EMAIL PROTECTED]:/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=8843UP,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=8943UP,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: [EMAIL PROTECTED] 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 ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to [EMAIL PROTECTED]
