On Thursday 11 August 2016 15:44:24 Doug wrote:
On 08/11/2016 12:50 PM, Gene Heskett wrote:
On Thursday 11 August 2016 12:47:09 Nicolas George wrote: CC:ing emc-developers, and trinity-users who may not yet be aware of this tcp attack vector thats quite dangerous. And my post to trinity-users was in error, so this corrects it.
Le quintidi 25 thermidor, an CCXXIV, Gene Heskett a écrit :
to add should be changed to forward slashes:
You are wrong, sysctl supports both slashes and dots as separators.
Regards,
I changed it back Nicolas, and sysctl -p now returns: root@coyote:/etc/init.d# sysctl -p sysctl: cannot stat /proc/sys//net.ipv4.tcp_challenge_ack_limit: No such file or directory
Put the slashes back and I get this: root@coyote:/etc/init.d# sysctl -p .net.ipv4.tcp_challenge_ack_limit = 999999999
Which I assume is the correct response. And yet the echo shows all dots.
WTH? Ahh, my bad, no damned biscuit, an extra leading slash snuck in. But if a dot and a slash are the same to sysctl, I should have a file in the wrong place? But I do not. /net is empty. It is in the right place now. And cats the correct value.
Sorry about the confusion everybody.
Cheers, Gene Heskett
Running PCLOS. I put in the original command with dots. When I run sysctl.p from a root environment I get no response, but no error either. Don't know the significance of that.
--doug
Neither do I Doug, sorry. See the announcement on /. today & read the link to the post from the guys that found it that is in the story, UCsomething IIRC, see below. A closer read may answer it.
https://ucrtoday.ucr.edu/39030
And please keep things like this on the list you read it from. A PM is unfair to the other readers of the list you read it on, so I'll cc the three lists it was cross posted to as it sounds pretty serious to me.
And I just noted that the sysctl command you quoted above is incorrect, its sysctl -p, not sysctl.p.
Maybe that helps?
Cheers, Gene Heskett
On Thu, 11 Aug 2016, Gene Heskett wrote:
And I just noted that the sysctl command you quoted above is incorrect, its sysctl -p, not sysctl.p.
as I indicated yesterday in my 'work-around' posts, the line I got which works is:
net.ipv4.tcp_challenge_ack_limit = 99999999
haven't tried it with slashes.
the re-load is
sysctl -p
E. Liddell says it is addressed in kernel 4.7; I'm on an old kernel and may fool around with updating it sometime when I have nothing more fun to do.
f.
On Thu, 11 Aug 2016 16:36:19 -0400 (EDT) Felmon Davis davisf@union.edu wrote:
E. Liddell says it is addressed in kernel 4.7; I'm on an old kernel and may fool around with updating it sometime when I have nothing more fun to do.
That's what I got by drilling down to the actual advisory (it also linked the specific git commit, although I didn't check that link). Keep in mind that 4.7 is *very* recent--the merge window for its successor, 4.8, just closed yesterday. I don't know if the patch was backported to the various long-term support kernel series like 4.1.
Significantly older kernels should also be in the clear, but I got contradictory indications about exactly when the problem code was added--possibly version 3.6.
E. Liddell
-
E. Liddell -
Felmon Davis -
Gene Heskett