Actually, there is currently a patch from brian feldman that is being tested and will be added shortly to the -CURRENT tree for further testing.. it adds a new login.conf action to limit sbsize.. to give you an idea.. the sbsize in the mbuf crash is 2 mb.. which is huge.. you can limit to however many bytes you want.. if you limited to say.. 640000.. there's no way anyone could crash it with mbufs. of course, if you are running a public access system, you shuld ALWAYS have login.conf setup, if not for mbufs, to protect the maxproc and openfiles limits as that can be bad on the system too.. Once this login.conf addition is made this should all be over ;) On Thu, 2 Sep 1999, Jeff Wheat wrote: > On 01-Sep-99 Darren Reed wrote: > >> > >> This was first posted to the FreeBSD security list on the 9th of August, > >> subsequently discussed on freebsd-stable and freebsd-hackers... no one > >> seems to care, even though it is able to lock up 2.2.6, 2.2.8, and 3.2.x > >> machines consistantly. I have also been told that it affects NetBSD and > >> OpenBSD, though I haven't confirmed it. > >> > >> Someone with the know-how care to fix? > > > > Fixing this has been discussed internally, I imagine, by many of the > > affected OS's. The problem is a resource stavation issue - in this > > case mbuf's. Arguably, it shouldn't "lock up", just freeze up anything > > that does networking. > > > > I imagine you could lock up more than just the *BSD's with this program. > > > > Darren > > In all the tests that I have conducted on my FreeBSD systems, both > intel and alpha based, versions 2.2.2 through 4.0-19990809-CURRENT > result in the machines rebooting after running this DoS. The only > work-around for this is supposedly setting resource limits in the > /etc/login.conf file or to prevent public access to the machines. > > Regards, > Jeff >
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:02:21 PDT