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  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:	Mon, 02 Jul 2007 22:14:54 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	ilpo.jarvinen@...sinki.fi
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH] [TCP]: Fix logic breakage due to DSACK separation

From: "Ilpo_Järvinen" <ilpo.jarvinen@...sinki.fi>
Date: Sat, 16 Jun 2007 02:04:25 +0300 (EEST)

> There are still some things I must think carefully in sacktag processing 
> since it does not validate start_seq and end_seq at all which can be 
> abused currently at least in tcp-2.6. ...I would rather put end to the 
> whole russian roulette in tcp-2.6 sacktag rather than fix/think individual 
> cases and leave future modifications of it similarily hazardous. It's not 
> very clear to me how to handle all possible cases of invalid SACK blocks 
> though, perhaps TCP should just ignore such sack blocks without doing 
> any processing based on them, i.e., ignore them whenever start_seq-end_seq 
> does not fully fit to snd_una-snd_nxt (expect DSACK of course, which 
> should be processed if it's between undo_marker-snd_nxt). Do you have any 
> thoughts about this?

I agree.  This is a problem that basically every single TCP stack out
there right now is vulnerable to, lots of cpu processing for invalid
or maliciously created SACK blocks.  This is why I even considered the
RB-Tree stuff at all.

Therefore the earlier we toss out bad SACK blocks the better, and thus
I agree with a scheme that does validation at the earliest stage
possible as you seem to be suggesting.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists