Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #170972 > unrolled thread

(OT kinda) Newly-discovered TCP flaw

Back to article view | Back to linux.debian.user

Contents

  (OT kinda) Newly-discovered TCP flaw Curt <curty@free.fr> - 2016-08-11 18:00 +0200
    Re: (OT kinda) Newly-discovered TCP flaw Reco <recoverym4n@gmail.com> - 2016-08-11 18:30 +0200
      Re: (OT kinda) Newly-discovered TCP flaw Curt <curty@free.fr> - 2016-08-11 18:50 +0200
        Re: (OT kinda) Newly-discovered TCP flaw Hugo Vanwoerkom <hvw59601@care2.com> - 2016-08-12 23:40 +0200
          Re: (OT kinda) Newly-discovered TCP flaw Curt <curty@free.fr> - 2016-08-13 11:10 +0200
            Re: (OT kinda) Newly-discovered TCP flaw Reco <recoverym4n@gmail.com> - 2016-08-13 11:20 +0200
              Re: (OT kinda) Newly-discovered TCP flaw Curt <curty@free.fr> - 2016-08-13 17:20 +0200
            Re: (OT kinda) Newly-discovered TCP flaw Pascal Hambourg <pascal@plouf.fr.eu.org> - 2016-08-13 11:20 +0200
              Re: (OT kinda) Newly-discovered TCP flaw Curt <curty@free.fr> - 2016-08-13 17:20 +0200
          Re: (OT kinda) Newly-discovered TCP flaw Reco <recoverym4n@gmail.com> - 2016-08-13 11:20 +0200
    Re: (OT kinda) Newly-discovered TCP flaw Gene Heskett <gheskett@shentel.net> - 2016-08-11 18:40 +0200
      Re: (OT kinda) Newly-discovered TCP flaw Gene Heskett <gheskett@shentel.net> - 2016-08-11 19:00 +0200
        Re: (OT kinda) Newly-discovered TCP flaw Curt <curty@free.fr> - 2016-08-11 19:30 +0200
      Re: (OT kinda) Newly-discovered TCP flaw Dan Ritter <dsr@randomstring.org> - 2016-08-11 19:00 +0200
      Re: (OT kinda) Newly-discovered TCP flaw Nicolas George <george@nsup.org> - 2016-08-11 19:10 +0200
        Re: (OT kinda) Newly-discovered TCP flaw Gene Heskett <gheskett@shentel.net> - 2016-08-11 20:00 +0200
          Re: (OT kinda) Newly-discovered TCP flaw Doug <dmcgarrett@optonline.net> - 2016-08-11 20:50 +0200
            Re: (OT kinda) Newly-discovered TCP flaw Gene Heskett <gheskett@shentel.net> - 2016-08-11 21:10 +0200
              Re: (OT kinda) Newly-discovered TCP flaw Lisi Reisz <lisi.reisz@gmail.com> - 2016-08-11 21:40 +0200
                Re: (OT kinda) Newly-discovered TCP flaw Joe <joe@jretrading.com> - 2016-08-11 22:10 +0200
                  Re: (OT kinda) Newly-discovered TCP flaw deloptes <deloptes@gmail.com> - 2016-08-11 22:40 +0200
                    Re: (OT kinda) Newly-discovered TCP flaw Joe <joe@jretrading.com> - 2016-08-11 22:50 +0200
                      Re: (OT kinda) Newly-discovered TCP flaw deloptes <deloptes@gmail.com> - 2016-08-12 00:00 +0200
                      Re: (OT kinda) Newly-discovered TCP flaw Bob Weber <bobrweber@gmail.com> - 2016-08-12 00:00 +0200
                        Re: (OT kinda) Newly-discovered TCP flaw Curt <curty@free.fr> - 2016-08-12 11:00 +0200
                          Re: (OT kinda) Newly-discovered TCP flaw Gene Heskett <gheskett@shentel.net> - 2016-08-12 12:00 +0200
                            Re: (OT kinda) Newly-discovered TCP flaw deloptes <deloptes@gmail.com> - 2016-08-12 12:50 +0200
                              Re: (OT kinda) Newly-discovered TCP flaw Gene Heskett <gheskett@shentel.net> - 2016-08-12 13:30 +0200
                                Re: (OT kinda) Newly-discovered TCP flaw deloptes <deloptes@gmail.com> - 2016-08-12 22:30 +0200
                            Re: (OT kinda) Newly-discovered TCP flaw Curt <curty@free.fr> - 2016-08-12 14:30 +0200
                              Re: (OT kinda) Newly-discovered TCP flaw rhkramer@gmail.com - 2016-08-12 16:50 +0200
                                Re: (OT kinda) Newly-discovered TCP flaw Greg Wooledge <wooledg@eeg.ccf.org> - 2016-08-12 17:00 +0200
                                  Re: (OT kinda) Newly-discovered TCP flaw Pascal Hambourg <pascal@plouf.fr.eu.org> - 2016-08-12 17:20 +0200
                                    Re: (OT kinda) Newly-discovered TCP flaw Greg Wooledge <wooledg@eeg.ccf.org> - 2016-08-12 17:40 +0200
                                  Re: (OT kinda) Newly-discovered TCP flaw rhkramer@gmail.com - 2016-08-12 17:40 +0200
                                    Re: (OT kinda) Newly-discovered TCP flaw "John L. Ries" <jries@salford-systems.com> - 2016-08-12 18:40 +0200
                                Re: (OT kinda) Newly-discovered TCP flaw Curt <curty@free.fr> - 2016-08-12 18:10 +0200
                              Re: (OT kinda) Newly-discovered TCP flaw Gene Heskett <gheskett@shentel.net> - 2016-08-12 18:00 +0200
                                The Debian/Ubuntu/Mint installer was Re: (OT kinda) Newly-discovered TCP flaw Lisi Reisz <lisi.reisz@gmail.com> - 2016-08-13 01:10 +0200
                                  Re: The Debian/Ubuntu/Mint installer was Re: (OT kinda) Newly-discovered TCP flaw Gene Heskett <gheskett@shentel.net> - 2016-08-13 05:20 +0200
                                    Re: The Debian/Ubuntu/Mint installer was Re: (OT kinda) Newly-discovered TCP flaw Lisi Reisz <lisi.reisz@gmail.com> - 2016-08-13 10:50 +0200
                    Re: (OT kinda) Newly-discovered TCP flaw Gene Heskett <gheskett@shentel.net> - 2016-08-12 05:00 +0200
                Re: (OT kinda) Newly-discovered TCP flaw Gene Heskett <gheskett@shentel.net> - 2016-08-12 04:50 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#170994

Joe wrote:

> On Thu, 11 Aug 2016 20:31:37 +0100
> Lisi Reisz <lisi.reisz@gmail.com> wrote:
> 
> 
>> 
>> I copied and pasted the commands exactly, and ran them as root, and
>> got an echo of net.ipv4.tcp_challenge_ack_limit = 999999999 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=999999999
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
999999999

interesting ...

Do you have recommendations?

regards

[toc] | [prev] | [next] | [standalone]

#170995

On Thu, 11 Aug 2016 22:35:06 +0200
deloptes <deloptes@gmail.com> wrote:

> Joe wrote:
> 
> > On Thu, 11 Aug 2016 20:31:37 +0100
> > Lisi Reisz <lisi.reisz@gmail.com> wrote:
> > 
> >   
> >> 
> >> I copied and pasted the commands exactly, and ran them as root, and
> >> got an echo of net.ipv4.tcp_challenge_ack_limit = 999999999 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=999999999
> 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
> 999999999
> 
> interesting ...
> 
> Do you have recommendations?
> 

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

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#170996

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

[toc] | [prev] | [next] | [standalone]

#170997

The way to do it is to put the line:

net.ipv4.tcp_challenge_ack_limit = 999999999

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

[toc] | [prev] | [next] | [standalone]

#171018

On 2016-08-11, Bob Weber <bobrweber@gmail.com> wrote:
> The way to do it is to put the line:
>
> net.ipv4.tcp_challenge_ack_limit = 999999999
>
> 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 = 999999999'
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  

[toc] | [prev] | [next] | [standalone]

#171020

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

> On 2016-08-11, Bob Weber <bobrweber@gmail.com> wrote:
> > The way to do it is to put the line:
> >
> > net.ipv4.tcp_challenge_ack_limit = 999999999
> >
> > 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 =
> 999999999' 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 <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#171021

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

[toc] | [prev] | [next] | [standalone]

#171023

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 <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#171047

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.

[toc] | [prev] | [next] | [standalone]

#171025

On 2016-08-12, Gene Heskett <gheskett@shentel.net> wrote:
>>
>> Simply using the command 'net.ipv4.tcp_challenge_ack_limit =
>> 999999999' 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  

[toc] | [prev] | [next] | [standalone]

#171030

On Friday, August 12, 2016 08:22:26 AM Curt wrote:
> On 2016-08-12, Gene Heskett <gheskett@shentel.net> 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?

[toc] | [prev] | [next] | [standalone]

#171032

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, rhkramer@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.
======================================================================

[toc] | [prev] | [next] | [standalone]

#171035

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.

<https://cdn.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.2.37>

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.

[toc] | [prev] | [next] | [standalone]

#171036

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.
> 
> <https://cdn.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.2.37>

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.)

[toc] | [prev] | [next] | [standalone]

#171040

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, rhkramer@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.
> 
======================================================================

[toc] | [prev] | [next] | [standalone]

#171043

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, rhkramer@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, rhkramer@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.
> >
> ======================================================================
>
>

[toc] | [prev] | [next] | [standalone]

#171042

On 2016-08-12, rhkramer@gmail.com <rhkramer@gmail.com> wrote:
> On Friday, August 12, 2016 08:22:26 AM Curt wrote:
>> On 2016-08-12, Gene Heskett <gheskett@shentel.net> 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  

[toc] | [prev] | [next] | [standalone]

#171041

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

> On 2016-08-12, Gene Heskett <gheskett@shentel.net> wrote:
> >> Simply using the command 'net.ipv4.tcp_challenge_ack_limit =
> >> 999999999' 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 
999999999
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 <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

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

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

[toc] | [prev] | [next] | [standalone]

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

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 <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | linux.debian.user

csiph-web