Re: (OT kinda) Newly-discovered TCP flaw

[Curt]

On 2016-08-13, Reco  wrote:
>   Hi.
>
> On Sat, 13 Aug 2016 09:04:34 + (UTC)
> Curt  wrote:
>
>> I am reading (see link below) that "The RFC 5961 spec is implemented in
>> Linux kernel v 3.6 and later."
>> 
>> http://www.linuxinsider.com/story/83798.html
>> 
>> As I'm running a v 3.2 kernel, I guess I'm actually not concerned by the
>> matter (or am I)? I applied the patch anyway, as I'm in doubt. 
>
> https://security-tracker.debian.org/tracker/source-package/linux
>
> says that wheezy's kernel is affected by CVE-2016-5696 too.

Okay. Thank you. 

> Reco
>
>


-- 
Même l’avenir n’est plus ce qu’il était. 
Paul Valéry  

Re: (OT kinda) Newly-discovered TCP flaw

[Curt]

On 2016-08-13, Pascal Hambourg  wrote:
>>
>> As I'm running a v 3.2 kernel, I guess I'm actually not concerned by the
>> matter (or am I)?
>
> You are if you are using the latest Debian 3.2 kernel. Please see my 
> previous reply to the same assumption in this thread.

Thank you.

> "Later" does not mean "higher".

Distinction duly noted.

> The flawed feature was backported in the upstream 3.2.37 kernel.
> The latest Debian 3.2 kernel is currently based on the upstream 3.2.81 
> kernel.
>
>


-- 
Même l’avenir n’est plus ce qu’il était. 
Paul Valéry  

Re: (OT kinda) Newly-discovered TCP flaw

[Reco]

Hi.

On Sat, 13 Aug 2016 09:04:34 + (UTC)
Curt  wrote:

> I am reading (see link below) that "The RFC 5961 spec is implemented in
> Linux kernel v 3.6 and later."
> 
> http://www.linuxinsider.com/story/83798.html
> 
> As I'm running a v 3.2 kernel, I guess I'm actually not concerned by the
> matter (or am I)? I applied the patch anyway, as I'm in doubt. 

https://security-tracker.debian.org/tracker/source-package/linux

says that wheezy's kernel is affected by CVE-2016-5696 too.

Reco

Re: (OT kinda) Newly-discovered TCP flaw

[Pascal Hambourg]

Le 13/08/2016 à 11:04, Curt a écrit :


I am reading (see link below) that "The RFC 5961 spec is implemented in
Linux kernel v 3.6 and later."

As I'm running a v 3.2 kernel, I guess I'm actually not concerned by the
matter (or am I)?


You are if you are using the latest Debian 3.2 kernel. Please see my 
previous reply to the same assumption in this thread.


"Later" does not mean "higher".

The flawed feature was backported in the upstream 3.2.37 kernel.
The latest Debian 3.2 kernel is currently based on the upstream 3.2.81 
kernel.

Re: (OT kinda) Newly-discovered TCP flaw

[Reco]

Hi.

On Fri, 12 Aug 2016 16:35:59 -0500
Hugo Vanwoerkom  wrote:

> On 08/11/2016 11:46 AM, Curt wrote:
> > On 2016-08-11, Reco  wrote:
> >>Hi.
> >>
> >> On Thu, Aug 11, 2016 at 03:55:56PM +, 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=9
> >
> > 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

Re: (OT kinda) Newly-discovered TCP flaw

[Curt]

On 2016-08-12, Hugo Vanwoerkom  wrote:
>>>
>>> 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=9
>>
>> 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? Or rather what effect 
> will it have if it never is removed?

My guess is nothing (will or would happen). Surely the consultation of
your favorite search engine should keep you informed on the evolution of
this affair.

What's ironic is in attempting to throttle the number of challenge acks as a
security measure they opened up the big flaw. Must be one of those moral
lessons hiding in there somewhere.

I am reading (see link below) that "The RFC 5961 spec is implemented in
Linux kernel v 3.6 and later."

http://www.linuxinsider.com/story/83798.html

As I'm running a v 3.2 kernel, I guess I'm actually not concerned by the
matter (or am I)? I applied the patch anyway, as I'm in doubt. 


> Hugo
>
>
>
>


-- 
Même l’avenir n’est plus ce qu’il était. 
Paul Valéry  

Re: The Debian/Ubuntu/Mint installer was Re: (OT kinda) Newly-discovered TCP flaw

[Lisi Reisz]

On Saturday 13 August 2016 04:11:19 Gene Heskett wrote:
> On Friday 12 August 2016 19:02:15 Lisi Reisz wrote:
> > On Friday 12 August 2016 16:57:09 Gene Heskett wrote:
> > > If that works, I will STFU about their broken installer, if not,
> > > that campaign to get it fixed to work with a pre-partitioned disk
> > > will continue.
> >
> > It does in general work with a pre-partitioned disk.  Anyhow it works
> > for me, and many others.  We have still not established why it doesn't
> > work for you; but you have to admit Gene that since the problem
> > appears personal to you, it just MAY be to do with you and not the
> > installer  I agree it may not, but we haven't established exactly
> > what you do that is different from the rest of us, so no-one can tell.
> >
> > Most of the rest of us are sometimes guilty of PEBKAC or, whisper it
> > low, and heaven forfend, a senior moment or two (or three). ;-)
> >
> > Lisi
>
> Shush now Lisi, you're giving away all my secrets. ;-)  The next time I
> try, I will have the Official guide to properly setting up a static
> network according to the *buntu guru's under my left hand.  Succeeding
> in that, then we follow another similar doc I've printed out to try to
> make a pre-formatted GPT disk usable without giving up and letting the
> installer partition it AND format it to suit itself.

I have done exactly that, without any difficulty at all: partitioned using 
Gparted then installed on those partitions.  I rather think that the problem 
is that you try to skip the partitioner. You can't do that.  You have to 
assign the partitions to where you want them via the partitioner, but you can 
tell the partitioner not to do anything or format anything, at least in 
Debian.  And I imagine that Ubuntu is the same, anyhow in the alternate 
installer.  But you have to tell the installer which partition to use for 
what, e.g. sda1 for /home and sda2 for / , and you do that with the 
partitioner.

Lisi

> Which usually 
> winds up with something too small...
>
> I am not always the P in PEBKAC...
>
> Cheers, Gene Heskett

Re: The Debian/Ubuntu/Mint installer was Re: (OT kinda) Newly-discovered TCP flaw

[Gene Heskett]

On Friday 12 August 2016 19:02:15 Lisi Reisz wrote:

> On Friday 12 August 2016 16:57:09 Gene Heskett wrote:
> > If that works, I will STFU about their broken installer, if not,
> > that campaign to get it fixed to work with a pre-partitioned disk
> > will continue.
>
> It does in general work with a pre-partitioned disk.  Anyhow it works
> for me, and many others.  We have still not established why it doesn't
> work for you; but you have to admit Gene that since the problem
> appears personal to you, it just MAY be to do with you and not the
> installer  I agree it may not, but we haven't established exactly
> what you do that is different from the rest of us, so no-one can tell.
>
> Most of the rest of us are sometimes guilty of PEBKAC or, whisper it
> low, and heaven forfend, a senior moment or two (or three). ;-)
>
> Lisi

Shush now Lisi, you're giving away all my secrets. ;-)  The next time I 
try, I will have the Official guide to properly setting up a static 
network according to the *buntu guru's under my left hand.  Succeeding 
in that, then we follow another similar doc I've printed out to try to 
make a pre-formatted GPT disk usable without giving up and letting the 
installer partition it AND format it to suit itself.  Which usually 
winds up with something too small...

I am not always the P in PEBKAC...

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

The Debian/Ubuntu/Mint installer was Re: (OT kinda) Newly-discovered TCP flaw

[Lisi Reisz]

On Friday 12 August 2016 16:57:09 Gene Heskett wrote:
> If that works, I will STFU about their broken installer, if not, that
> campaign to get it fixed to work with a pre-partitioned disk will
> continue.

It does in general work with a pre-partitioned disk.  Anyhow it works for me, 
and many others.  We have still not established why it doesn't work for you; 
but you have to admit Gene that since the problem appears personal to you, it 
just MAY be to do with you and not the installer  I agree it may not, but 
we haven't established exactly what you do that is different from the rest of 
us, so no-one can tell.

Most of the rest of us are sometimes guilty of PEBKAC or, whisper it low, and 
heaven forfend, a senior moment or two (or three). ;-)

Lisi

Re: (OT kinda) Newly-discovered TCP flaw

[Hugo Vanwoerkom]

On 08/11/2016 11:46 AM, Curt wrote:

On 2016-08-11, Reco  wrote:

Hi.

On Thu, Aug 11, 2016 at 03:55:56PM +, 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=9


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? Or rather what effect 
will it have if it never is removed?


Hugo

Re: (OT kinda) Newly-discovered TCP flaw

[deloptes]

Gene Heskett wrote:

> Wouldn't a network restart fix that?  Or are there other low hanging
> fruit in this scene?

I'm not sure as it is in the kernel - I don't know what and how is using
this piece of code.

Re: (OT kinda) Newly-discovered TCP flaw

[John L. Ries]

A report on this showed up on ZDNet this morning:

http://www.zdnet.com/article/linux-tcp-flaw-lets-anyone-hijack-internet-traffic

Apparently, it affects Linux 3.6 and up.  Hopefully, I don't have to root
my Android devices to fix the problem there (we'll see how quickly Samsung
rolls out the patch).

--|
John L. Ries  |
Salford Systems   |
Phone: (619)543-8880 x107 |
or (435)867-8885  |
--|


On Fri, 12 Aug 2016, rhkra...@gmail.com wrote:

> Oops, my apologies, I did have a senior moment (but not the one I allluded to
> earlier)--the reference I found to runtime was in the man page for sysctl, not
> the README.
>
>
> On Friday, August 12, 2016 10:54:52 AM Greg Wooledge wrote:
> > I did some web surfing when this thread was posted, to try to track
> > down *which kernel versions* are affected by this TCP security flaw.
> > I haven't seen this information posted yet.
> >
> > http://www.cs.ucr.edu/~zhiyunq/pub/sec16_TCP_pure_offpath.pdf says:
> > "The feature is outlined in RFC 5961, which is implemented faithfully
> > in Linux kernel version 3.6 from late 2012."
> >
> > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5696 says:
> > "net/ipv4/tcp_input.c in the Linux kernel before 4.7 does not properly
> > determine the rate of challenge ACK segments, which makes it easier
> > for man-in-the-middle attackers to hijack TCP sessions via a blind
> > in-window attack."
> >
> > So the flaw appears to be in Linux kernels from 3.6 to 4.6 inclusive,
> > which includes Jessie (3.16) but not Wheezy (3.2) or earlier.
> > The jessie-backports kernel right now is 4.6, but only for a brief
> > time.  The last plan I saw was for Stretch to ship with 4.10, which
> > should include the fix for this flaw.
> >
> > Now on to the thread:
> >
> > On Fri, Aug 12, 2016 at 10:42:36AM -0400, rhkra...@gmail.com wrote:
> > > In the README for sysctl on my wheezy system, it says "configure kernel
> > > parameters at runtime".
> >
> > Not on mine.
> >
> > greg@remote:~$ grep run /etc/sysctl.d/README.sysctl
> > greg@remote:~$
> >
> > > I may be having a senior moment, but, atm, I'm not completely sure what
> > > runtime means
> >
> > "At boot time", I would think.  But I don't know where your file actually
> > came from, so my guesses about the author's intent might be somewhat off.
> >
> > README.sysctl is short enough to post in its entirety here, so this is
> > what mine says on a wheezy system:
> >
> >
> ==
> > Kernel system variables configuration files
> >
> > Files found under the /etc/sysctl.d directory that end with .conf are
> > parsed within sysctl(8) at boot time.  If you want to set kernel variables
> > you can either edit /etc/sysctl.conf or make a new file.
> >
> > The filename isn't important, but don't make it a package name as it may
> > clash with something the package builder needs later. It must end with
> > .conf though.
> >
> > My personal preference would be for local system settings to go into
> > /etc/sysctl.d/local.conf but as long as you follow the rules for the names
> > of the file, anything will work. See sysctl.conf(8) man page for details
> > of the format.
> >
> ==
>
>

Re: (OT kinda) Newly-discovered TCP flaw

[Curt]

On 2016-08-12, rhkra...@gmail.com  wrote:
> On Friday, August 12, 2016 08:22:26 AM Curt wrote:
>> On 2016-08-12, Gene Heskett  wrote:
>> > I interpret that, since the word "at run time" in that README to mean a
>> > reboot.  And I do not see an exception in that README that should muddy
>> > that meaning.
>> 
>> I do not have the phrase "at run time" anywhere in my README.
>
> In the README for sysctl on my wheezy system, it says "configure kernel 
> parameters at runtime".

I concur with Greg on what the file contains.

> I may be having a senior moment, but, atm, I'm not completely sure what 
> runtime means--I guess it means any time sysctl is run, which is probably  
> once during bootup (or maybe startup of a vm), and other times manually "on 
> demand".  Right?
>

To me kernel parameters configured at "run time" means while the kernel
is executing (the system is up and running). This would preclude any
rebooting (which brings the system down, however briefly).

Of course, I ain't no hacker, so more informed minds may weigh in.


-- 
Même l’avenir n’est plus ce qu’il était. 
Paul Valéry  

Re: (OT kinda) Newly-discovered TCP flaw

[Gene Heskett]

On Friday 12 August 2016 08:22:26 Curt wrote:

> On 2016-08-12, Gene Heskett  wrote:
> >> Simply using the command 'net.ipv4.tcp_challenge_ack_limit =
> >> 9' as root sets the value, but does not survive a reboot.
> >> Running 'sysctl -p' with no argument after having issued the above
> >> command does nothing but reread '/etc/sysctl.conf' (and gives no
> >> output). 'sysctl -p xxx.conf' echos the new value in xxx.conf.
> >
> > And if this has been installed into the /etc/sysctl.conf file, what
> > will it be set to after a reboot?
>
> To the new value you've entered in that file. 'sysctl -p
> /etc/sysctl.conf/' or 'sysctl -p /etc/sysctl.d/xxx.conf' sets the
> value while the kernel is running.  That value will be "parsed within
> sysctl(8) at boot time." To create a new value you either edit
> /etc/sysctl.conf or make a new file under the /etc/sysctl.d directory
> ending in '.conf'.
>
> At least, that's the way I understand it.
>
> > I interpret that, since the word "at run time" in that README to
> > mean a reboot.  And I do not see an exception in that README that
> > should muddy that meaning.
>
> I do not have the phrase "at run time" anywhere in my README.

It is there, as "at runtime" in my wheezy copy of that man page.
The README OTOH says "at boot time" and I have to assume that the equ of 
sysctl -p it invoked at runtime, eg boot up.

In /etc/init.d the applicable file might be procps, it will call sysctl.
A root "service procps restart" is uneventful, and the value of:
root@coyote:/etc/init.d# service procps restart
[ ok ] Setting kernel variables ...done.
root@coyote:/etc/init.d# cat /proc/sys/net/ipv4/tcp_challenge_ack_limit 
9
is preserved.

Based on that, I'll not worry about doing a reboot in the next 10 
minutes.  I have a new 1Tb drive, and a ubuntu 16.04 LTS Mate dvd that I 
need to figure out how to make networking work in the live dvd mode. 
Then I'll do a test install following their directions for how to use a 
pre-partitioned in GPT format disk that has already been formatted.

That of course qualifies as a reboot, and is subject to this attack as 
soon as networking is enabled. I don't know if I can apply this fix even 
before I bring up the network, but should.  Interesting time killing 
experiment, but thats all it is.  I have that 16.04 lts in xfce flavor 
on my flea powered 14 year old laptop.  Even with xfce, the bloated 
state is obvious.

If that works, I will STFU about their broken installer, if not, that 
campaign to get it fixed to work with a pre-partitioned disk will 
continue.  But its a test install only as I will reformat it, and load 
it from the latest .iso that can run linuxcnc.

> Tata,
>
> Curt

Be well.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: (OT kinda) Newly-discovered TCP flaw

[Greg Wooledge]

On Fri, Aug 12, 2016 at 05:19:21PM +0200, Pascal Hambourg wrote:
> Why then is the sysctl present in the current Wheezy's 3.2 kernel ?
> 
> The patches which introduced the flawed feature were backported in 
> upstream 3.2.37 kernel.
> 
> 

Oh, interesting.  Thank you for that.

Is it safe to say, then, that the flaw is potentially present in any kernel
where /proc/sys/net/ipv4/tcp_challenge_ack_limit exists?  (Assuming that
there is a /proc file system at all.)

Re: (OT kinda) Newly-discovered TCP flaw

[rhkramer]

Oops, my apologies, I did have a senior moment (but not the one I allluded to 
earlier)--the reference I found to runtime was in the man page for sysctl, not 
the README.


On Friday, August 12, 2016 10:54:52 AM Greg Wooledge wrote:
> I did some web surfing when this thread was posted, to try to track
> down *which kernel versions* are affected by this TCP security flaw.
> I haven't seen this information posted yet.
> 
> http://www.cs.ucr.edu/~zhiyunq/pub/sec16_TCP_pure_offpath.pdf says:
> "The feature is outlined in RFC 5961, which is implemented faithfully
> in Linux kernel version 3.6 from late 2012."
> 
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5696 says:
> "net/ipv4/tcp_input.c in the Linux kernel before 4.7 does not properly
> determine the rate of challenge ACK segments, which makes it easier
> for man-in-the-middle attackers to hijack TCP sessions via a blind
> in-window attack."
> 
> So the flaw appears to be in Linux kernels from 3.6 to 4.6 inclusive,
> which includes Jessie (3.16) but not Wheezy (3.2) or earlier.
> The jessie-backports kernel right now is 4.6, but only for a brief
> time.  The last plan I saw was for Stretch to ship with 4.10, which
> should include the fix for this flaw.
> 
> Now on to the thread:
> 
> On Fri, Aug 12, 2016 at 10:42:36AM -0400, rhkra...@gmail.com wrote:
> > In the README for sysctl on my wheezy system, it says "configure kernel
> > parameters at runtime".
> 
> Not on mine.
> 
> greg@remote:~$ grep run /etc/sysctl.d/README.sysctl
> greg@remote:~$
> 
> > I may be having a senior moment, but, atm, I'm not completely sure what
> > runtime means
> 
> "At boot time", I would think.  But I don't know where your file actually
> came from, so my guesses about the author's intent might be somewhat off.
> 
> README.sysctl is short enough to post in its entirety here, so this is
> what mine says on a wheezy system:
> 
> 
==
> Kernel system variables configuration files
> 
> Files found under the /etc/sysctl.d directory that end with .conf are
> parsed within sysctl(8) at boot time.  If you want to set kernel variables
> you can either edit /etc/sysctl.conf or make a new file.
> 
> The filename isn't important, but don't make it a package name as it may
> clash with something the package builder needs later. It must end with
> .conf though.
> 
> My personal preference would be for local system settings to go into
> /etc/sysctl.d/local.conf but as long as you follow the rules for the names
> of the file, anything will work. See sysctl.conf(8) man page for details
> of the format.
> 
==

Re: (OT kinda) Newly-discovered TCP flaw

[Pascal Hambourg]

Le 12/08/2016 à 16:54, Greg Wooledge a écrit :


So the flaw appears to be in Linux kernels from 3.6 to 4.6 inclusive,
which includes Jessie (3.16) but not Wheezy (3.2) or earlier.


Why then is the sysctl present in the current Wheezy's 3.2 kernel ?

The patches which introduced the flawed feature were backported in 
upstream 3.2.37 kernel.




Debian regularly updates its kernels with more recent upstream releases 
of the same series (here 3.2.x), although keeping the same version 
(3.2.O) in the package name. The real version is currently 3.2.81.

Re: (OT kinda) Newly-discovered TCP flaw

[Greg Wooledge]

I did some web surfing when this thread was posted, to try to track
down *which kernel versions* are affected by this TCP security flaw.
I haven't seen this information posted yet.

http://www.cs.ucr.edu/~zhiyunq/pub/sec16_TCP_pure_offpath.pdf says:
"The feature is outlined in RFC 5961, which is implemented faithfully
in Linux kernel version 3.6 from late 2012."

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5696 says:
"net/ipv4/tcp_input.c in the Linux kernel before 4.7 does not properly
determine the rate of challenge ACK segments, which makes it easier
for man-in-the-middle attackers to hijack TCP sessions via a blind
in-window attack."

So the flaw appears to be in Linux kernels from 3.6 to 4.6 inclusive,
which includes Jessie (3.16) but not Wheezy (3.2) or earlier.
The jessie-backports kernel right now is 4.6, but only for a brief
time.  The last plan I saw was for Stretch to ship with 4.10, which
should include the fix for this flaw.

Now on to the thread:

On Fri, Aug 12, 2016 at 10:42:36AM -0400, rhkra...@gmail.com wrote:
> In the README for sysctl on my wheezy system, it says "configure kernel 
> parameters at runtime".

Not on mine.

greg@remote:~$ grep run /etc/sysctl.d/README.sysctl
greg@remote:~$ 

> I may be having a senior moment, but, atm, I'm not completely sure what 
> runtime means

"At boot time", I would think.  But I don't know where your file actually
came from, so my guesses about the author's intent might be somewhat off.

README.sysctl is short enough to post in its entirety here, so this is
what mine says on a wheezy system:

==
Kernel system variables configuration files

Files found under the /etc/sysctl.d directory that end with .conf are
parsed within sysctl(8) at boot time.  If you want to set kernel variables
you can either edit /etc/sysctl.conf or make a new file.

The filename isn't important, but don't make it a package name as it may clash
with something the package builder needs later. It must end with .conf though.

My personal preference would be for local system settings to go into
/etc/sysctl.d/local.conf but as long as you follow the rules for the names
of the file, anything will work. See sysctl.conf(8) man page for details
of the format.
==

Re: (OT kinda) Newly-discovered TCP flaw

[rhkramer]

On Friday, August 12, 2016 08:22:26 AM Curt wrote:
> On 2016-08-12, Gene Heskett  wrote:
> > I interpret that, since the word "at run time" in that README to mean a
> > reboot.  And I do not see an exception in that README that should muddy
> > that meaning.
> 
> I do not have the phrase "at run time" anywhere in my README.

In the README for sysctl on my wheezy system, it says "configure kernel 
parameters at runtime".

I may be having a senior moment, but, atm, I'm not completely sure what 
runtime means--I guess it means any time sysctl is run, which is probably  
once during bootup (or maybe startup of a vm), and other times manually "on 
demand".  Right?

Re: (OT kinda) Newly-discovered TCP flaw

[Curt]

On 2016-08-12, Gene Heskett  wrote:
>>
>> Simply using the command 'net.ipv4.tcp_challenge_ack_limit =
>> 9' as root sets the value, but does not survive a reboot.
>> Running 'sysctl -p' with no argument after having issued the above
>> command does nothing but reread '/etc/sysctl.conf' (and gives no
>> output). 'sysctl -p xxx.conf' echos the new value in xxx.conf.
>>
> And if this has been installed into the /etc/sysctl.conf file, what will 
> it be set to after a reboot?

To the new value you've entered in that file. 'sysctl -p
/etc/sysctl.conf/' or 'sysctl -p /etc/sysctl.d/xxx.conf' sets the value
while the kernel is running.  That value will be "parsed within
sysctl(8) at boot time." To create a new value you either edit
/etc/sysctl.conf or make a new file under the /etc/sysctl.d directory
ending in '.conf'.

At least, that's the way I understand it.

> I interpret that, since the word "at run time" in that README to mean a 
> reboot.  And I do not see an exception in that README that should muddy 
> that meaning.

I do not have the phrase "at run time" anywhere in my README.

Tata,

Curt
> Cheers, Gene Heskett


-- 
Même l’avenir n’est plus ce qu’il était. 
Paul Valéry  

Re: (OT kinda) Newly-discovered TCP flaw

[Gene Heskett]

On Friday 12 August 2016 06:40:27 deloptes wrote:

> Gene Heskett wrote:
> > And if this has been installed into the /etc/sysctl.conf file, what
> > will it be set to after a reboot?
> >
> > I interpret that, since the word "at run time" in that README to
> > mean a reboot.  And I do not see an exception in that README that
> > should muddy that meaning.
>
> you either activate it (what you put in the /etc/sysctl.conf file)
> with -p option or it will be set on reboot. the advantage of reboot is
> that all programs will take notice of this option, while when changing
> it in run time, it could be that some programs still use the old value
> until tcp conn closes.
> this is how i understand it
>
> regards

Obviously, now that its been pointed out, that is a possibility.

Wouldn't a network restart fix that?  Or are there other low hanging 
fruit in this scene?

Thanks. 

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: (OT kinda) Newly-discovered TCP flaw

[deloptes]

Gene Heskett wrote:

> And if this has been installed into the /etc/sysctl.conf file, what will
> it be set to after a reboot?
> 
> I interpret that, since the word "at run time" in that README to mean a
> reboot.  And I do not see an exception in that README that should muddy
> that meaning.

you either activate it (what you put in the /etc/sysctl.conf file) with -p
option or it will be set on reboot. the advantage of reboot is that all
programs will take notice of this option, while when changing it in run
time, it could be that some programs still use the old value until tcp conn
closes.
this is how i understand it

regards

Re: (OT kinda) Newly-discovered TCP flaw

[Gene Heskett]

On Friday 12 August 2016 04:58:06 Curt wrote:

> On 2016-08-11, Bob Weber  wrote:
> > The way to do it is to put the line:
> >
> > net.ipv4.tcp_challenge_ack_limit = 9
> >
> > in a file in the /etc/sysctl.d directory named xxx.conf (replace xxx
> > with your preferred name).
> >
> > Then run "sysctl -p xxx.conf" and the new value is installed in the
> > kernel tree.  My system had a value of 100 before I changed it.  At
> > boot the file will be read so the new value will be used then also.
>
> Yes, I have a README.sysctl file in the /etc/sysctl.d directory that
> explains the process as you do (with certain precisions).
>
> Simply using the command 'net.ipv4.tcp_challenge_ack_limit =
> 9' as root sets the value, but does not survive a reboot.
> Running 'sysctl -p' with no argument after having issued the above
> command does nothing but reread '/etc/sysctl.conf' (and gives no
> output). 'sysctl -p xxx.conf' echos the new value in xxx.conf.
>
> > ...Bob

And if this has been installed into the /etc/sysctl.conf file, what will 
it be set to after a reboot?

I interpret that, since the word "at run time" in that README to mean a 
reboot.  And I do not see an exception in that README that should muddy 
that meaning.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: (OT kinda) Newly-discovered TCP flaw

[Curt]

On 2016-08-11, Bob Weber  wrote:
> The way to do it is to put the line:
>
> net.ipv4.tcp_challenge_ack_limit = 9
>
> in a file in the /etc/sysctl.d directory named xxx.conf (replace xxx with your
> preferred name).
>
> Then run "sysctl -p xxx.conf" and the new value is installed in the kernel
> tree.  My system had a value of 100 before I changed it.  At boot the file 
> will
> be read so the new value will be used then also.

Yes, I have a README.sysctl file in the /etc/sysctl.d directory that
explains the process as you do (with certain precisions).

Simply using the command 'net.ipv4.tcp_challenge_ack_limit = 9'
as root sets the value, but does not survive a reboot. Running 'sysctl
-p' with no argument after having issued the above command does nothing
but reread '/etc/sysctl.conf' (and gives no output). 'sysctl -p
xxx.conf' echos the new value in xxx.conf.

> ...Bob
>
>


-- 
Même l’avenir n’est plus ce qu’il était. 
Paul Valéry  

Re: (OT kinda) Newly-discovered TCP flaw

[Gene Heskett]

On Thursday 11 August 2016 16:35:06 deloptes wrote:

> Joe wrote:
> > On Thu, 11 Aug 2016 20:31:37 +0100
> >
> > Lisi Reisz  wrote:
> >> I copied and pasted the commands exactly, and ran them as root, and
> >> got an echo of net.ipv4.tcp_challenge_ack_limit = 9 in
> >> response to the first and a blank return in response to the second.
> >> I don't know the significance.
> >
> > Go and read /proc/net/ipv4... and it should show the changed value.
> >
> > I believe the echo means it worked. I also believe it needs to be
> > added to /etc/sysctl.conf (without the 'sysctl -p') to be redone on
> > boot. It seems to affect every current Debian up to sid.
>
> I don't see it in the /proc tree (kernel 4.6.4 on jessie)
>
> # ls -1 /proc/net/ip*
> /proc/net/ip6_flowlabel
> /proc/net/ip_tables_matches
> /proc/net/ip_tables_names
> /proc/net/ip_tables_targets
> /proc/net/ipv6_route
>
> and on the firewall (2.6.26.2 wheezy)
>
>  sysctl -w net.ipv4.tcp_challenge_ack_limit=9
> sysctl: cannot stat /proc/sys/net/ipv4/tcp_challenge_ack_limit: No
> such file or directory
>
> I don't understand if it is bad.
>
> on the file server (kernel 3.2.0 jessie)
>
> cat /proc/sys/net/ipv4/tcp_challenge_ack_limit
> 9
>
> interesting ...
>
> Do you have recommendations?

It looks like you have it right.

> regards


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: (OT kinda) Newly-discovered TCP flaw

[Gene Heskett]

On Thursday 11 August 2016 15:31:37 Lisi Reisz wrote:

> On Thursday 11 August 2016 20:06:26 Gene Heskett wrote:
> > 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 = 9
> > > >
> > > > 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.
> >
> > 
> >
> > 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?
>
> I copied and pasted the commands exactly, and ran them as root, and
> got an echo of net.ipv4.tcp_challenge_ack_limit = 9 in
> response to the first and a blank return in response to the second.  I
> don't know the significance.
>
> Lisi

cat that file Lisi.  Thats in /proc/sys/net.ipv4.tcp_challenge_ack_limit.  
I think we did as we were told if it contains those 9 9's.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: (OT kinda) Newly-discovered TCP flaw

[Bob Weber]

The way to do it is to put the line:

net.ipv4.tcp_challenge_ack_limit = 9

in a file in the /etc/sysctl.d directory named xxx.conf (replace xxx with your
preferred name).

Then run "sysctl -p xxx.conf" and the new value is installed in the kernel
tree.  My system had a value of 100 before I changed it.  At boot the file will
be read so the new value will be used then also.


Check what is there now with:

sysctl -a | grep net.ipv4.tcp_challenge_ack_limit

You should see 999... after you run the sysctl -p command.

When the kernel is fixed then you just need to delete the xxx.conf file and the
next boot the default value will get used.

...Bob

Re: (OT kinda) Newly-discovered TCP flaw

[deloptes]

Joe wrote:

> /sys/

I compiled the kernels (4.6.4 and 2.6.26.2) myself and this is not present
in any of them. It is present only in the debian kernel ... need to read
more tomorrow where it is coming from.
One good reason to keep compiling the kernels on the critical machines with
only the options I need.

regards

Re: (OT kinda) Newly-discovered TCP flaw

[Joe]

On Thu, 11 Aug 2016 22:35:06 +0200
deloptes  wrote:

> Joe wrote:
> 
> > On Thu, 11 Aug 2016 20:31:37 +0100
> > Lisi Reisz  wrote:
> > 
> >   
> >> 
> >> I copied and pasted the commands exactly, and ran them as root, and
> >> got an echo of net.ipv4.tcp_challenge_ack_limit = 9 in
> >> response to the first and a blank return in response to the second.
> >> I don't know the significance.
> >>   
> > 
> > Go and read /proc/net/ipv4... and it should show the changed value.
> > 
> > I believe the echo means it worked. I also believe it needs to be
> > added to /etc/sysctl.conf (without the 'sysctl -p') to be redone on
> > boot. It seems to affect every current Debian up to sid.  
> 
> I don't see it in the /proc tree (kernel 4.6.4 on jessie)
>  
> # ls -1 /proc/net/ip*
> /proc/net/ip6_flowlabel
> /proc/net/ip_tables_matches
> /proc/net/ip_tables_names
> /proc/net/ip_tables_targets
> /proc/net/ipv6_route
> 
> and on the firewall (2.6.26.2 wheezy)
> 
>  sysctl -w net.ipv4.tcp_challenge_ack_limit=9
> sysctl: cannot stat /proc/sys/net/ipv4/tcp_challenge_ack_limit: No
> such file or directory
> 
> I don't understand if it is bad.
> 
> on the file server (kernel 3.2.0 jessie)
> 
> cat /proc/sys/net/ipv4/tcp_challenge_ack_limit
> 9
> 
> interesting ...
> 
> Do you have recommendations?
> 

I forgot the /sys/. Sorry. It is present on my wheezy and sid (4.6.4-1).

-- 
Joe

Re: (OT kinda) Newly-discovered TCP flaw

[deloptes]

Joe wrote:

> On Thu, 11 Aug 2016 20:31:37 +0100
> Lisi Reisz  wrote:
> 
> 
>> 
>> I copied and pasted the commands exactly, and ran them as root, and
>> got an echo of net.ipv4.tcp_challenge_ack_limit = 9 in
>> response to the first and a blank return in response to the second.
>> I don't know the significance.
>> 
> 
> Go and read /proc/net/ipv4... and it should show the changed value.
> 
> I believe the echo means it worked. I also believe it needs to be added
> to /etc/sysctl.conf (without the 'sysctl -p') to be redone on boot. It
> seems to affect every current Debian up to sid.

I don't see it in the /proc tree (kernel 4.6.4 on jessie)
 
# ls -1 /proc/net/ip*
/proc/net/ip6_flowlabel
/proc/net/ip_tables_matches
/proc/net/ip_tables_names
/proc/net/ip_tables_targets
/proc/net/ipv6_route

and on the firewall (2.6.26.2 wheezy)

 sysctl -w net.ipv4.tcp_challenge_ack_limit=9
sysctl: cannot stat /proc/sys/net/ipv4/tcp_challenge_ack_limit: No such file
or directory

I don't understand if it is bad.

on the file server (kernel 3.2.0 jessie)

cat /proc/sys/net/ipv4/tcp_challenge_ack_limit
9

interesting ...

Do you have recommendations?

regards

Re: (OT kinda) Newly-discovered TCP flaw

[Joe]

On Thu, 11 Aug 2016 20:31:37 +0100
Lisi Reisz  wrote:


> 
> I copied and pasted the commands exactly, and ran them as root, and
> got an echo of net.ipv4.tcp_challenge_ack_limit = 9 in
> response to the first and a blank return in response to the second.
> I don't know the significance.
> 

Go and read /proc/net/ipv4... and it should show the changed value.

I believe the echo means it worked. I also believe it needs to be added
to /etc/sysctl.conf (without the 'sysctl -p') to be redone on boot. It
seems to affect every current Debian up to sid.

-- 
Joe

Re: (OT kinda) Newly-discovered TCP flaw

[Lisi Reisz]

On Thursday 11 August 2016 20:06:26 Gene Heskett wrote:
> 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 = 9
> > >
> > > 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.
>
> 
>
> 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?

I copied and pasted the commands exactly, and ran them as root, and got an 
echo of net.ipv4.tcp_challenge_ack_limit = 9 in response to the first 
and a blank return in response to the second.  I don't know the significance.

Lisi

Re: (OT kinda) Newly-discovered TCP flaw

[Gene Heskett]

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 = 9
> >
> > 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.



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
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: (OT kinda) Newly-discovered TCP flaw

[Doug]

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 = 9

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

Re: (OT kinda) Newly-discovered TCP flaw

[Gene Heskett]

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 = 9

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
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: (OT kinda) Newly-discovered TCP flaw

[Curt]

On 2016-08-11, Gene Heskett  wrote:
> On Thursday 11 August 2016 12:47:09 Nicolas George wrote:
>
>> 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,
>
> Apparently not on my wheezy based install, I got no such file or 
> directory errors out of the "sysctl -p" command until I had changed it.

Running Wheezy; command worked with dots as per Reco's suggestion.
Can't imagine why it failed on your machine. 

> Cheers, Gene Heskett


-- 
Même l’avenir n’est plus ce qu’il était. 
Paul Valéry  

Re: (OT kinda) Newly-discovered TCP flaw

[Nicolas George]

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,

-- 
  Nicolas George

Re: (OT kinda) Newly-discovered TCP flaw

[Gene Heskett]

On Thursday 11 August 2016 12:47:09 Nicolas George wrote:

> 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,

Apparently not on my wheezy based install, I got no such file or 
directory errors out of the "sysctl -p" command until I had changed it.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: (OT kinda) Newly-discovered TCP flaw

[Dan Ritter]

On Thu, Aug 11, 2016 at 12:16:30PM -0400, Gene Heskett wrote:
> On Thursday 11 August 2016 11:55:56 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?
> 
> I do not know if wheezy is/can be affected, however the fix promulgated 
> by the link to the UCR announcement is wrong, at least for my wheezy 
> install, in that when I investigated my machine, the dots in that 
> string:
> 
> net.ipv4.tcp_challenge_ack_limit = 9
> 
> to add should be changed to forward slashes:
> 
> net/ipv4/tcp_challenge_ack_limit = 9
> 
> as that is the directory structure on this wheezy based machine, and then 
> the following update command:
> 
> sysctl -p

Not exactly. While the directory structure certainly uses
slashes, the sysctl.conf uses either slashes or dots, and 
dots are the convention used by almost everyone across Linux
distros, including examples in Debian documentation.

-dsr-

Re: (OT kinda) Newly-discovered TCP flaw

[Curt]

On 2016-08-11, Reco  wrote:
>   Hi.
>
> On Thu, Aug 11, 2016 at 03:55:56PM +, 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=9

Thank you very much for this. 

> To solve the problem you should wait until Debian-provided kernels gain
> a backport for CVE-2016-5696.
>
> Reco
>
>


-- 
Même l’avenir n’est plus ce qu’il était. 
Paul Valéry  

Re: (OT kinda) Newly-discovered TCP flaw

[Gene Heskett]

On Thursday 11 August 2016 11:55:56 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?

I do not know if wheezy is/can be affected, however the fix promulgated 
by the link to the UCR announcement is wrong, at least for my wheezy 
install, in that when I investigated my machine, the dots in that 
string:

net.ipv4.tcp_challenge_ack_limit = 9

to add should be changed to forward slashes:

net/ipv4/tcp_challenge_ack_limit = 9

as that is the directory structure on this wheezy based machine, and then 
the following update command:

sysctl -p

works w/o error.  All done as root of course.

No clue if the fix works, I haven't been attacked that I am aware of.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: (OT kinda) Newly-discovered TCP flaw

[Reco]

Hi.

On Thu, Aug 11, 2016 at 03:55:56PM +, 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=9

To solve the problem you should wait until Debian-provided kernels gain
a backport for CVE-2016-5696.

Reco