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 1 of 3  [1] 2 3  Next page →

#170972 — (OT kinda) Newly-discovered TCP flaw

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?

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

[toc] | [next] | [standalone]

#170974

	Hi.

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

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

Reco

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

#170976

On 2016-08-11, Reco <recoverym4n@gmail.com> wrote:
> 	Hi.
>
> On Thu, Aug 11, 2016 at 03:55:56PM +0000, 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=999999999

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  

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

#171049

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

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

#171057

On 2016-08-12, Hugo Vanwoerkom <hvw59601@care2.com> 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=999999999
>>
>> 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  

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

#171058

	Hi.

On Sat, 13 Aug 2016 09:04:34 +0000 (UTC)
Curt <curty@free.fr> 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

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

#171066

On 2016-08-13, Reco <recoverym4n@gmail.com> wrote:
> 	Hi.
>
> On Sat, 13 Aug 2016 09:04:34 +0000 (UTC)
> Curt <curty@free.fr> 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  

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

#171060

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.

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

#171065

On 2016-08-13, Pascal Hambourg <pascal@plouf.fr.eu.org> 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  

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

#171059

	Hi.

On Fri, 12 Aug 2016 16:35:59 -0500
Hugo Vanwoerkom <hvw59601@care2.com> wrote:

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

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

#170975

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

to add should be changed to forward slashes:

net/ipv4/tcp_challenge_ack_limit = 999999999

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

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

#170980

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

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

#170983

On 2016-08-11, Gene Heskett <gheskett@shentel.net> 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  

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

#170981

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 = 999999999
> 
> to add should be changed to forward slashes:
> 
> net/ipv4/tcp_challenge_ack_limit = 999999999
> 
> 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-

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

#170982

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

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

#170984

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
-- 
"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]

#170985

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

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

#170986

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
-- 
"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]

#170988

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

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.

Lisi

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

#170990

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.

-- 
Joe

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web