Hi. On Fri, 12 Aug 2016 16:35:59 -0500 Hugo Vanwoerkom <hvw59...@care2.com> wrote:
> On 08/11/2016 11:46 AM, Curt wrote: > > On 2016-08-11, Reco <recovery...@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
