Protecting our SLES 11/12 servers against SACK Panic" / CVE-2019-11477

Recently, one of the more severe Linux security issues of this year has been
published.
 
A remote attacker able to make TCP connections to a Linux machine can
crash this machine, regardless of the service running.
 
The codename is "SACK Panic" / CVE-2019-11477.
There are two more issues in the block, but these are less severe
(just causing higher memory, compute time or bandwith usage.)
 
- CVE-2019-11478: SACK Slowness or Excess Resource Usage
- CVE-2019-11479: Excess Resource Consumption Due to Low MSS Values

All SUSE Linux and openSUSE versions are affected. 
 
Since, we have Oes11sp1/2/3, Oes2015sp1, sles12sp3 servers in our environment. how can we ensure their immunity to this vulnerability for different versions of SLES. 
All wonderful ideas will be highly appreciated.
Parents
  • There are no security patches released yet it seems to fix this issue and only some workaround only being advised. 

     
    No idea if it will have any impact on our currently running services 
  • We are in that waiting game, of hoping effective patches come out before any exploits start poking around the net.

    My Thoughts: 

    That an exploit would be a Denial of Service issue, so how bad would it be for a given set of externally facing services to be down?  If a given service can readily be down the time of a reboot, then probably safe to wait until the patches are ready. If such a down time has direct consequence, then be seriously testing out the work around options and start implementing them.

    I can imagine extortion attempts of `pay money or we take you down`, but in those cases you have a bit of warning to get cracking about getting work arounds into production.

    We are early in the process and will have patching to do soon, but until their are attacks in the wild, we have some breathing room.

    more on the topic with a firewall speed bump at https://isc.sans.edu/diary/rss/25046

Reply
  • We are in that waiting game, of hoping effective patches come out before any exploits start poking around the net.

    My Thoughts: 

    That an exploit would be a Denial of Service issue, so how bad would it be for a given set of externally facing services to be down?  If a given service can readily be down the time of a reboot, then probably safe to wait until the patches are ready. If such a down time has direct consequence, then be seriously testing out the work around options and start implementing them.

    I can imagine extortion attempts of `pay money or we take you down`, but in those cases you have a bit of warning to get cracking about getting work arounds into production.

    We are early in the process and will have patching to do soon, but until their are attacks in the wild, we have some breathing room.

    more on the topic with a firewall speed bump at https://isc.sans.edu/diary/rss/25046

Children
No Data