TCP weakness identified

[TWPonKubuntu]

The article specifically mentions Linux as a vulnerable OS, plus Android.
Reference:

https://ucrtoday.ucr.edu/39030

...
"Such a weakness could be used to launch targeted attacks that track users’ online activity, forcibly terminate a communication, hijack a conversation between hosts or degrade the privacy guarantee by anonymity networks such as Tor."
...

A possible local fix is given near the end of the article. Patches are referenced to the latest Linux code, but not to existing installations "in the wild".

[TWPonKubuntu]

Update: more information

Update from alternate source:

https://www.onthewire.io/widespread-...g-termination/

[GreyGeek]

Not really news. Here is a paper from last year identifying the "side channels":
https://www.cs.unm.edu/~crandall/infocom2015rtt.pdf

A "side channel" is created when the third part of the three part handshake between a server and a client is not executed. When an off-path machine sends an unsolicited SYN-ACK packet it creates an entry (side channel) in the handshake buffer. There are two kinds of SYN-ACK entries in the kernel space handshake buffer, young and mature, based on their age. The trick is to flood the client with SYN-ACKs till the client attempts to clear the mature "channels" out of the buffer. This attack requires an open port. Kubuntu's TCP makes all ports closed during installation, even if the ufw is not activated. You can check your ports here. If you are all green you are good to go. Red or blue is bad.

The temporary fix to this attack is supposed to be:

    Open /etc/sysctl.conf, append a command “/net.ipv4/tcp_challenge_ack_limit = 999999999”.
    Use “sysctl -p” to update the configuration.

doesn't work because that TCP parameter is not compiled into the Linux kernel space. You'll get a "file or directory not found" error. Creating that as a file won't work if the kernel isn't reading it.

[TWPonKubuntu]

Not really news.
...

Dang, must be a slow news day for the authors

[kubicle]

Not really news. Here is a paper from last year identifying the "side channels":
The temporary fix to this attack is supposed to be:

    Open /etc/sysctl.conf, append a command “/net.ipv4/tcp_challenge_ack_limit = 999999999”.
    Use “sysctl -p” to update the configuration.

doesn't work because that TCP parameter is not compiled into the Linux kernel space. You'll get a "file or directory not found" error. Creating that as a file won't work if the kernel isn't reading it.

It should work fine.

Are you sure you're appending in the correct syntax:
net.ipv4.tcp_challenge_ack_limit = 999999999
(not /net.ipv4/tcp_challenge_ack_limit = 999999999)

The default ack_limit is 100 for *buntus
EDIT: you can check the current parameter value with:

sysctl net.ipv4.tcp_challenge_ack_limit

[MoonRise]

Cool! Thanks!

[GreyGeek]

It should work fine.

Are you sure you're appending in the correct syntax:
net.ipv4.tcp_challenge_ack_limit = 999999999
(not /net.ipv4/tcp_challenge_ack_limit = 999999999)

The default ack_limit is 100 for *buntus
EDIT: you can check the current parameter value with:

sysctl net.ipv4.tcp_challenge_ack_limit

If the "/" is included one will be warned of the error when re-initializing sysctl.
My installation fails the "fix" as an unrecognized parameter. (I'm running Neon)

[wizard10000]

Dang, must be a slow news day for the authors

Yup. Five years ago I was working end user support for a rather large web hosting company and we were well aware of SYN attacks back then. This may not be exactly the same vulnerability but it used to be that a SYN flood would bring a webserver to its knees. My anecdotal experience is old, though

[GreyGeek]

This kind of attack is more than just a brute force DoS attack. It's an execution.

[kubicle]

If the "/" is included one will be warned of the error when re-initializing sysctl.
My installation fails the "fix" as an unrecognized parameter. (I'm running Neon)

That's a bit odd. I'm running Neon as well, and I just tested it and it works well here.
What's your cli output if you run:

sysctl net.ipv4.tcp_challenge_ack_limit

[MoonRise]

Kubicle, it worked on this end. I received the below.

moonrise@Panther:~$ sysctl net.ipv4.tcp_challenge_ack_limit
net.ipv4.tcp_challenge_ack_limit = 100
moonrise@Panther:~$

[kubicle]

Kubicle, it worked on this end. I received the below.

moonrise@Panther:~$ sysctl net.ipv4.tcp_challenge_ack_limit
net.ipv4.tcp_challenge_ack_limit = 100
moonrise@Panther:~$

That sort of shows you haven't actually changed the kernel default (100). After editing sysctl.conf you need to run "sudo sysctl -p" to reload the configuration (a reboot will also work, of course)

[GreyGeek]

It should work fine.

Are you sure you're appending in the correct syntax:
net.ipv4.tcp_challenge_ack_limit = 999999999
(not /net.ipv4/tcp_challenge_ack_limit = 999999999)

The default ack_limit is 100 for *buntus
EDIT: you can check the current parameter value with:

sysctl net.ipv4.tcp_challenge_ack_limit

Ah, it was the second "/" that got to me. Changing it to a "." allowed the command to work.

[MoonRise]

That sort of shows you haven't actually changed the kernel default (100). After editing sysctl.conf you need to run "sudo sysctl -p" to reload the configuration (a reboot will also work, of course)

Is there any reason to change the default? I think at a 100 seems safe?

[kubicle]

Is there any reason to change the default? I think at a 100 seems safe?

I think the proof-of-concept attack was demonstrated against the limit of 100 (per second). How effective the attack is in real world situations is another thing, but 100 is low enough to make the attack at least theoretically possible.

The kernel patch to fix the issue seems to increase the limit to 1000, but more importantly it adds randomization to the number so the limit is not predictable (which should break the timing which is apparently important for the attack to work). As long as the limit is fixed (with a non-patched kernel), I'd recommend using a limit much larger than 1000 (just to err on the safe side).