In http://docs.freebsd.org/cgi/mid.cgi?200402260743.IAA18903 it seems RELENG_4 is vulnerable. Is there any work around to a system that has to have ports open ? Version: 1 2/18/2004@03:47:29 GMT >Initial report > <<https://ialert.idefense.com/KODetails.jhtml?irId=207650>https://ialert.idefense.com/KODetails.jhtml?irId=207650; >ID#207650: >FreeBSD Memory Buffer Exhaustion Denial of Service Vulnerability >(iDEFENSE Exclusive): Remote exploitation of a denial of service (DoS) >vulnerability in FreeBSD's memory buffers (mbufs) could allow attackers >to launch a DoS attack. > >By sending many out-of-sequence packets, a low bandwidth denial of >service attack is possible against FreeBSD. When the targeted system >runs out of memory buffers (mbufs), it is no longer able to accept or >create new connections. -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike
On Sun, 29 Feb 2004, Mike Tancsa wrote:> In > http://docs.freebsd.org/cgi/mid.cgi?200402260743.IAA18903 > > it seems RELENG_4 is vulnerable. Is there any work around to a system that > has to have ports open ?There is no way to fix this issue without kernel modifications. A fix has been committed to -current, someone on the security team can probably provide information on when the MFC will be appearing. On the plus side, you have to establish a TCP connection to make the DoS happen, so people abusing it can be easily traced. Mike "Silby" Silbersack
On (2004/02/29 19:03), Mike Silbersack wrote:> > http://docs.freebsd.org/cgi/mid.cgi?200402260743.IAA18903 > > > > it seems RELENG_4 is vulnerable. Is there any work around to a system that > > has to have ports open ? > > There is no way to fix this issue without kernel modifications. A fix has > been committed to -current, someone on the security team can probably > provide information on when the MFC will be appearing.Owch. The advisory says the DoS works by sending many out-of-sequence packets. Do you know how out-of-sequence do the packets have to be? I ask because if they have to be significantly staggered, then my IPFilter firewall might offer me some protection and I can start breathing again. Ciao, Sheldon.
On Sun, Feb 29, 2004 at 07:38:11PM -0500, Mike Tancsa wrote:> In > http://docs.freebsd.org/cgi/mid.cgi?200402260743.IAA18903 > > it seems RELENG_4 is vulnerable. Is there any work around to a system that > has to have ports open ?There will be advisories and patches available tomorrow. Cheers, -- Jacques Vidrine / nectar@celabo.org / jvidrine@verio.net / nectar@freebsd.org
In some mail from Jacques A. Vidrine, sie said:> > On Wed, Mar 03, 2004 at 05:08:07AM +1100, Darren Reed wrote: > > My comment was to say that with ipf4, you can address this problem. > > Do you plan to bring ipf4 into FreeBSD anytime soon? I think it would > be best to have a major upgrade before FreeBSD 5.3.Yes - version 4.1.1. Darren
In some mail from Mike Silbersack, sie said:> On Wed, 3 Mar 2004, Darren Reed wrote: > > > > "strict" requires that the sequence number in packet n should match > > > > what that sequence number of the last byte in packet n-1 - i.e. no > > > > out of order delivery is permitted. > > > > > > > > Darren > > Right, so your comment about it "not working" applies to 3.x (which > > is what comes with freebsd, currently), which is what i was hoping :) > > > > My comment was to say that with ipf4, you can address this problem. > > > > darren > > Ok, that sounds correct. However, it would have an adverse performance > impact in the normal case. Have you considered having an "almost strict" > option that would allow maybe 3 or 4 out of order segments through? That > would be a great feature. :)Indeed, there is the potential for adverse impact on TCP and hence so it is an option. But if I adopted your suggestion, it would be like saying it was "almost secure". It is primarily intended for things like, as an example, FTP command channels or telnet or (maybe) SMTP. Darren