[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: (OT kinda) Newly-discovered TCP flaw



	Hi.

On Fri, 12 Aug 2016 16:35:59 -0500
Hugo Vanwoerkom <hvw59601@care2.com> wrote:

> On 08/11/2016 11:46 AM, Curt wrote:
> > On 2016-08-11, Reco <recoverym4n@gmail.com> wrote:
> >> 	Hi.
> >>
> >> On Thu, Aug 11, 2016 at 03:55:56PM +0000, Curt wrote:
> >>>
> >>> http://www.pcworld.com/article/3106180/security/use-the-internet-this-linux-flaw-could-open-you-up-to-attack.html?google_editors_picks=true
> >>>
> >>> Calling all experts: cause for concern?
> >>
> >> Debian stable is affected.
> >>
> >> If you're relying on HTTP or FTP - you're screwed. If you prefer HTTPS
> >> and SSH - it does not concern you.
> >>
> >> To workaround the problem, use (/etc/sysctl.conf is preferred):
> >>
> >> sysctl -w net.ipv4.tcp_challenge_ack_limit=999999999
> >
> > Thank you very much for this.
> >
> >> To solve the problem you should wait until Debian-provided kernels gain
> >> a backport for CVE-2016-5696.
> >>
> 
> And how will one know when to remove this patch? 

It's not a patch per se. It's a modification of kernel tunable.
And of course it won't be needed once Debian gives us a proper Linux
kernel update. To distinguish a right kernel update from the wrong
one it's needed to look for the changelog.Debian.gz, and search
CVE-2016-5696 inside it.

Of course it's also possible to track such update via (but it's way too
much hassle for me):
https://anonscm.debian.org/cgit/kernel/linux.git

And there's always (again, search for CVE-2016-5606):
https://security-tracker.debian.org/tracker/source-package/linux


> Or rather what effect will it have if it never is removed?

According to the kernel documentation,

tcp_challenge_ack_limit - INTEGER
    Limits number of Challenge ACK sent per second, as recommended
    in RFC 5961 (Improving TCP's Robustness to Blind In-Window Attacks)
    Default: 100

So regardless of existence of fix for CVE-2016-5696 such setting will
allow TCP injection attacks (first described at
http://cansecwest.com/csw04archive.html ).

Personally I don't the this issue as a big deal, as the only thing that
can be broken by TCP injection are L7 protocols that aren't using
encryption, and if one is relying on those - that one is screwed anyway.

Reco


Reply to: