This bug was just public today.
I have several machines running SUSE Linux Enterprise Server from version 10 to 12 SP1.
How can I tell if any of these SLES are having the RFC 5961?
Thank you,
Based on the dates, probably vulnerable since 2012 was long ago and SLES
12 came out since then.
With that in mind, have you tried the configuration change to fix this?
echo 'net.ipv4.tcp_challenge_ack_limit = 999999999' >> /etc/sysctl.conf;
sysctl -pI’m having a hard time finding the CVE for this for some reason, but if
there is one then searching on SUSE’s site for CVE information is pretty
easy from the list of all of them ever: https://www.suse.com/security/cve/
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
On 11/08/16 17:14, pasiit wrote:
[color=blue]
‘This bug’
(http://www.theregister.co.uk/2016/08/10/linux_tor_users_open_corrupted_communications/)
was just public today.
I have several machines running SUSE Linux Enterprise Server from
version 10 to 12 SP1.
How can I tell if any of these SLES are having the RFC 5961?[/color]
From the bug report attached to
https://www.suse.com/security/cve/CVE-2016-5696.html it looks like this
might affect SLE12 kernels with a feature backported for SLE11 SP3 and
SP4 (but you’ll need Long Term Service Pack Support for any patches
released for SLE11 SP3).
Note that if you’re concerned about security you should have already
upgraded/migrated servers running old, unsupported versions of SLES to
current releases SLES11 SP4 or SLES12 SP1.
HTH.
Simon
SUSE Knowledge Partner
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below. Thanks.
No this vulnerable was just announced today.
[QUOTE]
From the bug report attached to
https://www.suse.com/security/cve/CVE-2016-5696.html it looks like this
might affect SLE12 kernels with a feature backported for SLE11 SP3 and
SP4 (but you’ll need Long Term Service Pack Support for any patches
released for SLE11 SP3).[/QUOTE]
Hi Simon,
Thank you for responding.
Your provided CVE does not mention anything about the vulnerability with the RFC 5961.
I can’t understand how you can determine that this RFC5961 vulnerability affect all SLES?
Best regards,
The bug linked to that CVE is for this issue, so SUSE is working on the
issue as Bug# 989152.
See the public comments here:
https://bugzilla.suse.com/show_bug.cgi?id=989152
Of particular interest:
…Therefore SLE11-SP3-LTSS, SLE11-SP4 and newer kernels (except
master/stable which already have the fix via 4.7) need commit 75ff39ccc1bd.
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
On 11/08/16 18:54, pasiit wrote:
[color=blue]
Thank you for responding.
Your provided CVE does not mention anything about the vulnerability with
the RFC 5961.[/color]
http://lmgtfy.com/?q=rfc+5961+cve
That gave me CVE-2016-5696 so I then hit SUSE’s security pages.
[color=blue]
I can’t understand how you can determine that this RFC5961 vulnerability
affect all SLES?[/color]
As ab said, from the publicly viewable comments of bug 989152 linked to
the SUSE CVE page, specifically comment 3[1].
HTH.
[1] https://bugzilla.suse.com/show_bug.cgi?id=989152#c3
Simon
SUSE Knowledge Partner
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below. Thanks.
That bug post Michal said: “need commit 75ff39ccc1bd”.
What is 75ff39ccc1bd?
Thank you,
On 08/12/2016 08:14 AM, pasiit wrote:[color=blue]
[color=green]
[1] https://bugzilla.suse.com/show_bug.cgi?id=989152#c3
[/color]That bug post Michal said: “need commit 75ff39ccc1bd”.
What is 75ff39ccc1bd?[/color]
Commits in git (and possibly other distributed version control systems)
are identified by a hash of their contents, which are represented by the
minimum amount needed to uniquely identify hem; in this case, the commit
(probably to the kernel since I assume that is where this RFC was
implemented as part of the TCP/IP stack) identifier is that string.
You should not need to worry about that; if you want to know if your
installed kernel has a fix, search for the CVE number or the Bug# in the
kernel’s package metadata; for example:
rpm -q --changelog kernel-default | lessSearch through and you should see several notes about bug fixes, and
eventually the one above. You could also, if really motivated, pull down
the ‘kernel-source’ package and search through it for the fix as shown in
other bug comments (bleh). It looks like the ‘net/ipv4/tcp_input.c’ and
Documentation/networking/ip-sysctl.txt files were updated/created, in
particular changing sysctl_tcp_challenge_ack_limit from 100 to 1000 by
default, along with some other code changes you can see.
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
I found out that my SLES10 machines don’t have the file /proc/sys/net/ipv4/tcp_challenge_ack_limit.
Base on some reading, this’s mean the machines don’e have the RFC5961. Therefore, these machines are not affected.
I did a rpm -q --changelog kernel-default | grep 75ff39ccc1bd on the affected machines (SLES11 → 12) and nothing come up.
Does this mean these machines are not patched for this vulnerable?
Does the command sysctl -p affect any thing on the running system (such as, restart service, stop something temporally)?
Thank you,
On 08/12/2016 10:04 AM, pasiit wrote:[color=blue]
I found out that my SLES10 machines don’t have the file
/proc/sys/net/ipv4/tcp_challenge_ack_limit.
Base on some reading, this’s mean the machines don’e have the RFC5961.
Therefore, these machines are not affected.[/color]
Yes, probably too old to have this issue because it’s old enough to still
have a lot of other issues. You really should patch, but I know sometimes
that is easier said than done.
[color=blue]
I did a
Code:rpm -q --changelog kernel-default | grep 75ff39ccc1bd
on the affected machines (SLES11 → 12) and nothing come up.
Does this mean these machines are not patched for this vulnerable?[/color]
I think you should look for the BugZilla number, or the CVE number, rather
than the commit itself, as you’re probably much more-likely to find those
in there. The Bug# from suse.com will be prefixed by ‘bsc#’ which is a
good indicator.
[color=blue]
Does the command
Code:sysctl -p
affect any thing on the running system (such as, restart service, stop
something temporally)?[/color]
The ‘sysctl -p’ command loads settings from the sysctl.conf file in case
they are not set. Yes, it will impact the system right away, and no you
probably will not notice, other than by having settings you tried to
change actually change.
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
[QUOTE=pasiit;33914]This bug was just public today.
I have several machines running SUSE Linux Enterprise Server from version 10 to 12 SP1.
How can I tell if any of these SLES are having the RFC 5961?
Thank you,[/QUOTE]
check if your system is affect by running command “cat /proc/sys/net/ipv4/tcp_challenge_ack_limit”.
If the file is there and the value is 100 or less. Then follow the workaround to fix the vulnerable.
- Open the config file with: sudoedit /etc/sysctl.conf
- Insert the line net.ipv4.tcp_challenge_ack_limit = 999999999 into the file and save it
- Run sudo sysctl -p to update the configuration
On 04/10/16 18:04, pasiit wrote:
[color=blue]
check if your system is affect by running command “cat
/proc/sys/net/ipv4/tcp_challenge_ack_limit”.
If the file is there and the value is 100 or less. Then follow the
workaround to fix the vulnerable.
- Open the config file with: sudoedit /etc/sysctl.conf
- Insert the line net.ipv4.tcp_challenge_ack_limit = 999999999 into the
file and save it- Run sudo sysctl -p to update the configuration[/color]
As noted at https://www.suse.com/security/cve/CVE-2016-5696.html (which
I posted earlier in this thread) SUSE have now released updated packages
for some currently supported versions of SUSE products affected by this
issue with more in QA.
HTH.
Simon
SUSE Knowledge Partner