[SOLVED] Flaw in TCP (qv links) Temp fix until kernel repair

boombaby · posted: 2016-08-13 09:44

Hello, All...

Am I right, that the"fix" shown within the discussion (at the following link) about the substantial flaw inherent in Linux TCP is a systemd fix?

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://www.zdnet.com/article/linux-tcp-flaw-lets-anyone-hijack-internet-traffic/"
linktext was:"http://www.zdnet.com/article/linux-tcp- ... t-traffic/"
====================================

If that be the case, then can someone please explain, precisely, how I can do this right in Antix (ie non-systemd)?

Regards,
aka boombaby

rokytnji · posted: 2016-08-13 15:55

Go to /etc/apt/preferences.d

comment out oosystemd lines
to look like mine

Code: Select all

#Package: *systemd*
#Pin: origin""
#Pin-Priority: -1

save it. Then in terminal

Code: Select all

sudo apt-get update

Then do the zdnet dance if you wish. I won't touch it with a 10 foot pole because I own a Iphone so it does not relate to me.

it can be used to break or even hijack internet connections between Linux and Android systems.

If your system breaks. Not my fault

Don't forget to change back your changes to stock and do a sudo apt-get update again to bring your install back to stock.

Good luck with it.

But if you are patient.

First, Linux itself is being patched to stop the attack vector in its track

The article is dated

August 11, 2016

Personally. I'd wait for a Debian fix myself. Because my experiments with systmctl installed broke everything I had in /usr/local/bin

rokytnji · posted: 2016-08-13 16:38

Have you read this yet?

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://forum.mepiscommunity.org/viewtopic.php?f=94&t=40336"
linktext was:"http://forum.mepiscommunity.org/viewtop ... 94&t=40336"
====================================

kmathern · posted: 2016-08-13 16:51

rokytnji wrote:...Personally. I'd wait for a Debian fix myself. Because my experiments with systmctl installed broke everything I had in /usr/local/bin

The various fixes I've seen use the 'sysctl' utility, which I think you might be confusing with the systemd 'systemctl' utility (though you typed it systmctl).

Code: Select all

$ man sysctl | head
SYSCTL(8)                                                         System Administration                                                         SYSCTL(8)
NAME
       sysctl - configure kernel parameters at runtime

SYNOPSIS
       sysctl [options] [variable[=value]] [...]
       sysctl -p [file or regexp] [...]

Code: Select all

$ man systemctl | head
SYSTEMCTL(1)                                                            systemctl                                                            SYSTEMCTL(1)
NAME
       systemctl - Control the systemd system and service manager

SYNOPSIS
       systemctl [OPTIONS...] COMMAND [NAME...]

rokytnji · posted: 2016-08-13 19:23

Thanks for clearing up my snafu kmathern. I am a bit rusty with all the meds pumped into my body.

wildstar84 · posted: 2016-08-14 04:15

I added this to (slash) etc (slash) sysctl.conf and did: sudo sysctl -p:

#TEMP. FIX FOR TCP VULNORABILITY: (
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://blogs.akamai.com/2016/08/vulnerability-in-the-linux-kernels-tcp-stack-implementation.html"
linktext was:"https://blogs.akamai.com/2016/08/vulner ... ation.html"
====================================
)
#AND
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://www.zdnet.com/article/linux-tcp-flaw-lets-anyone-hijack-internet-traffic/"
linktext was:"http://www.zdnet.com/article/linux-tcp- ... t-traffic/"
====================================
:
net.ipv4.tcp_challenge_ack_limit= 1073741823

boombaby · posted: 2016-08-14 07:37

Hello, Each Respondent...

I tried:

sudo...blah...blah...blah

but it appears sudo doesn't appear to be installed on Antix.

So I tried:

su...blah...blah...blah...blah

but it didn't work. (Permission denied)

.
So to stop my f'n around I:

opened a Root-Terminal (which, strangely, only asked for the admin password, not root's)

and typed:

EDIT / etc/sysctl.conf

< where:"EDIT" represents my/your favourite Editor >
< where: in this forum, in that command, the space between .../ etc... should be removed first, else it won't work >

which took me to the sysctl.conf file.

At the bottom of the sysctl.conf file I appended the line:

net.ipv4.tcp_challenge_ack_limit=a_10_digit_number

< where:"a_10_digit_number" represents: a random 10-digit number (which was concocted, but has no leading zeros) >
< where: a random 10 digit number might actually be a random 9 digit number (any later post might clarify it >

Then saved it, and re-booted my system.

After reboot I opened a plain terminal and typed:

cat /proc/sys/net/ipv4/tcp_challenge_ack_limit

which produced an output of the very high number previously entered, which is the desired result.

NOTE
I said"10-digit number", but posts (across all links) have used numbers with 8, 9 and 10 digits - so that will need more, final clarity.

.
.
NOTE WELL

1. Of course I did not come up with those commands myself, nor could I have done that by myself in the next 50 to a_random_10_digit_number years (no leading zeros).

I could only have done it after reading all info and posts - especially with consideration to kmathern's fantastic input in this thread and in other links mentioned.

In particular, kmathern, I liked the distinction and clarity you produced about the two separate commands: sysctl and systemctl . (I did not know about sysctl before.)

2. I was unsure about meaning in wildstar84's details (ie between cmds and info) - or why the links were also included. I suspected he was indicating cmds to be used (ie the main part, which I emulated above), and THAT was my lead to give it a go.

3. So, essentitally, in this post I have just"re-said" all the main stuff (TOGETHER) to try to"roundup" the finer details in a sequence, so that other newbs and pnewbs could get their head directly on THE WHOLE FIX/TEST. (The"problem" defined within/across all the links was discussed pretty well.)

4. Also, rokytnji, thanks for the link to mepis community stuff. Not sure - exactly - why we (at Antix) keep referring back to mepis but that was a good lead.

P.S. Here in Australia we have might have a different meaning to what you refer to as"meds". Why on Earth you would want to "pump yourself full of meds" sounds very painful, and remains a complete mystery to me! (But that's Linux Users, I guess.)

5. Thanks also to Steven J. Vaughan-Nichols at the zdnet link, who WAS also pretty-well on the mark, I just combined stuff including the test/check.

6. So, big THANKS to Each (sorry for the capitals there). I'll leave the thread open for now, for any last wise-man details (but I think you've all managed that part already).

Regards,

fatmac · posted: 2016-08-14 10:04

meds = medicines = prescribed drugs __{{emoticon}}__

Jerry · posted: 2016-08-14 10:39

Not sure - exactly - why we (at Antix) keep referring back to mepis

Because the two communities share the same code base and many resources, and thus work together on many issues. The old"Mepis" is gone, but antiX MX (=MX Linux) is alive and well, and represents a unique symbiosis in the Linux world.

rokytnji · posted: 2016-08-14 16:36

As far as me personally. I have been a sick puppy for about a couple of weeks and we are trying to fix it.

Hence. Meds.

boombaby · posted: 2016-08-15 08:36

Hello again...

And the 8, 9 or 10 digit number? I am only guessing that some"upper limit" should not be breached (as a step to ensure"security")? What is it? Would it matter? Really matter?

Regards,

skidoo · posted: 2016-08-15 15:26

tcp_challenge_ack_limit specifies the maximum"challenge acks" per second limit.
The behavior of the"challenge ack" mechanism is detailed here:
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://tools.ietf.org/html/rfc5961"
linktext was:"https://tools.ietf.org/html/rfc5961"
====================================

Code: Select all

If the RST bit is set and the sequence number does not exactly
      match the next expected sequence value, yet is within the current
      receive window (RCV.NXT < SEG.SEQ < RCV.NXT+RCV.WND), TCP MUST
      send an acknowledgment (challenge ACK):

      <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>

      After sending the challenge ACK, TCP MUST drop the unacceptable
      segment and stop processing the incoming packet further.

When the limit is low, say 100, an attacker can easily flood/surpass that limit; after emitting 100 challenge acks, victim is resigned to
"shrugging, and allowing the (spoofed, injected by attacker) incoming packets"

And the 8, 9 or 10 digit number? ...What is it? Would it matter? Really matter?

The high limit is necessary (really matters) to ensure that a sufficiently high threshhold is enforced.
Consider how many rcv/ack transactions can occur per second via broadband (er gigbit/s) connection.

boombaby · posted: 2016-08-15 16:44

No, skidoo, I guess I worded that badly. Sorry. Let me try this way...

Across all links mentioned in this thread/topic there are incidences of 8, 9 or 10 digit numbers being used - EACH sort of giving/implying some kind of"maximum".

If the number of digits was limited to (say) 9, but the highest allowable value was (say)

189,012,345

then if I specified (say)

403,567,890

then my value would be beyond the actual limit. So, would that be a problem?

So - and to try and simplify it - I guess I am asking...

1.
is there max num of digits,

or

2.
is there a max value?

Get the drift? Is there a maximum something, and - if so - what is it?

I hope that is clearer.

Regards,

kmathern · posted: 2016-08-15 19:45

boombaby wrote:... 2. is there a max value? ...

It looks like the maximum allowed value for tcp_challenge_ack_limit might be 2,147,483,647, it accepts that value when I try to set it to that.

Code: Select all

$ sudo sysctl net.ipv4.tcp_challenge_ack_limit=2147483647
net.ipv4.tcp_challenge_ack_limit = 2147483647

If I try setting it to 2,147,483,648 I get a 'Invalid argument' message.

Code: Select all

$ sudo sysctl net.ipv4.tcp_challenge_ack_limit=2147483648
sysctl: setting key"net.ipv4.tcp_challenge_ack_limit": Invalid argument
net.ipv4.tcp_challenge_ack_limit = 2147483648

And checking afterwards I see that it didn't get changed

Code: Select all

$ sysctl net/ipv4/tcp_challenge_ack_limit
net.ipv4.tcp_challenge_ack_limit = 2147483647

2,147,483,647 (7FFFFFFF hex) (or 2^31 - 1) is the maximum positive value for a 32-bit signed binary integer.

I wouldn't set it that high though, 999,999,999 or the 1,073,741,823 value I mentioned in the forum.mepiscommunity.org thread (
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://forum.mepiscommunity.org/viewtopic.php?f=94&t=40336"
linktext was:"http://forum.mepiscommunity.org/viewtop ... 94&t=40336"
====================================
) are probably waaay more than enough.

In the debian patch they're only changing the default from 100 to 1000, though they're also adding some randomization.

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://anonscm.debian.org/cgit/kernel/linux.git/commit/?h=jessie-security&id=1bd5c3370523e5846019361b33a97c754db76f8d"
linktext was:"https://anonscm.debian.org/cgit/kernel/ ... 754db76f8d"
====================================

+This patch increases the default limit from 100 to 1000, and adds
+some randomization so that the attacker can no longer hijack
+sessions without spending a considerable amount of probes.

boombaby · posted: 2016-08-16 04:16

Thanks, kmathern. That great expansion (totally) completes answers to my last question.

For me, that now completes the thread. Thanks, Everyone.

Will leave link"open" for a day or two. Someone may have something to add (or remove).

I will change the subject title to better reflect the"meaning" of this procedure. (I hope Members don't mind.)

Regards,
aka boombaby