Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SACK Panic – Multiple TCP-based remote denial-of-service issues

access.redhat.com

Post reply on HN
Print view View original

31–40 of 134 posts

Re: SACK Panic – Multiple TCP-based remote denial-of-service issues

#31

Post by gravitas »

whyleyc wrote: post #29
gravitas wrote: post #18

I'm collecting vendor links internally for work: Red Hat / CentOS https://access.redhat.com/security/vulnerabilities/tcpsack https://access.redhat.com/security/cve/cve-2019-11477 https://access.redhat.com/security/cve/cve-2019-11478 https://access.redhat.com/security/cve/cve-2019-11479 Ubuntu https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SACKPanic https://people.canonical.com/~ubuntu-security/cve/2019/CVE-2... h…

Thanks for this. Any chance you can you edit the comment to make the links clicky please?

I am finding that HN has limited formatting options - if I don't indent by two spaces (aka code mode) it's a run-on mess, which then requires a large amount of ugly line breaks making the post 5x as large and unreadable. HN formatting instructions are all of 3 sentences long. https://news.ycombinator.com/formatdoc

Re: SACK Panic – Multiple TCP-based remote denial-of-service issues

#32

Post by syn0byte »

jkern wrote: post #5

So you can remotely cause a kernel panic on basically any system with kernel newer than 2.6.28? The doesn't sound great

No, not "any system". Besides needing SACK enabled (which is by default) you also need segment offloading and non-shite networking hardware that will respect and preserve stupid MSS fields in packets.

pending a patch simply disable SACK: ~$ echo 0 > /proc/sys/net/ipv4/tcp_sack

and/or disable segmentation offloading: ~$ ethtool -K eth? tso off

TCP and Checksum offloading still aren't super standard on customer grade NICs or virtual machines. I'd assume less than half of the internet's linux hosts are actually at risk.

Re: SACK Panic – Multiple TCP-based remote denial-of-service issues

#33

Post by whyleyc »

gravitas wrote: post #31
whyleyc wrote: post #29

Earlier quoted context omitted.

Thanks for this. Any chance you can you edit the comment to make the links clicky please?

I am finding that HN has limited formatting options - if I don't indent by two spaces (aka code mode) it's a run-on mess, which then requires a large amount of ugly line breaks making the post 5x as large and unreadable. HN formatting instructions are all of 3 sentences long. https://news.ycombinator.com/formatdoc

I agree that formatting could definitely do with some work!

If you put each link on a line and then leave a newline between each one you should get a nice list though.

Re: SACK Panic – Multiple TCP-based remote denial-of-service issues

#34

Post by oasisbob »

syn0byte wrote: post #32
jkern wrote: post #5

So you can remotely cause a kernel panic on basically any system with kernel newer than 2.6.28? The doesn't sound great

No, not "any system". Besides needing SACK enabled (which is by default) you also need segment offloading and non-shite networking hardware that will respect and preserve stupid MSS fields in packets. pending a patch simply disable SACK: ~$ echo 0 > /proc/sys/net/ipv4/tcp_sack and/or disable segmentation offloading: ~$ ethtool -K eth? tso off TCP and Checksum offloading still aren't super standard on customer grade N…

Isn't TSO enabled on EC2? Their bulletin implies it at least, I seem to remember the same.

Re: SACK Panic – Multiple TCP-based remote denial-of-service issues

#35

Post by foofc7c8 »

syn0byte wrote: post #32
jkern wrote: post #5

So you can remotely cause a kernel panic on basically any system with kernel newer than 2.6.28? The doesn't sound great

No, not "any system". Besides needing SACK enabled (which is by default) you also need segment offloading and non-shite networking hardware that will respect and preserve stupid MSS fields in packets. pending a patch simply disable SACK: ~$ echo 0 > /proc/sys/net/ipv4/tcp_sack and/or disable segmentation offloading: ~$ ethtool -K eth? tso off TCP and Checksum offloading still aren't super standard on customer grade N…

Can't find anywhere prerequisite on segment offloading, any link on this?

Re: SACK Panic – Multiple TCP-based remote denial-of-service issues

#36

Post by [deleted] »

whyleyc wrote: post #29
gravitas wrote: post #18

I'm collecting vendor links internally for work: Red Hat / CentOS https://access.redhat.com/security/vulnerabilities/tcpsack https://access.redhat.com/security/cve/cve-2019-11477 https://access.redhat.com/security/cve/cve-2019-11478 https://access.redhat.com/security/cve/cve-2019-11479 Ubuntu https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SACKPanic https://people.canonical.com/~ubuntu-security/cve/2019/CVE-2... h…

Thanks for this. Any chance you can you edit the comment to make the links clicky please?

[deleted]

Re: SACK Panic – Multiple TCP-based remote denial-of-service issues

#37

Post by syn0byte »

oasisbob wrote: post #34
syn0byte wrote: post #32

Earlier quoted context omitted.

No, not "any system". Besides needing SACK enabled (which is by default) you also need segment offloading and non-shite networking hardware that will respect and preserve stupid MSS fields in packets. pending a patch simply disable SACK: ~$ echo 0 > /proc/sys/net/ipv4/tcp_sack and/or disable segmentation offloading: ~$ ethtool -K eth? tso off TCP and Checksum offloading still aren't super standard on customer grade N…

Isn't TSO enabled on EC2? Their bulletin implies it at least, I seem to remember the same.

It may well be, I don't use EC2 much at all. Checking is easy enough: ~$ ethtool -k ethX

Also on the virtualization side, VMWare VMXNet adapters also support offloading for guests.

Re: SACK Panic – Multiple TCP-based remote denial-of-service issues

#38

Post by loeg »

gravitas wrote: post #18

I'm collecting vendor links internally for work: Red Hat / CentOS https://access.redhat.com/security/vulnerabilities/tcpsack https://access.redhat.com/security/cve/cve-2019-11477 https://access.redhat.com/security/cve/cve-2019-11478 https://access.redhat.com/security/cve/cve-2019-11479 Ubuntu https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SACKPanic https://people.canonical.com/~ubuntu-security/cve/2019/CVE-2... h…

https://github.com/Netflix/security-bulletins/blob/master/ad...

Re: SACK Panic – Multiple TCP-based remote denial-of-service issues

#39

Post by loeg »

dang wrote: post #3
hoffie wrote: post #2

Red Hat's article on these issues also provides further explanations: https://access.redhat.com/security/vulnerabilities/tcpsack

That seems to have a bit more information, so we switched to it from https://www.openwall.com/lists/oss-security/2019/06/17/5 . Thanks!

https://github.com/Netflix/security-bulletins/blob/master/ad... is the advisory by the party that discovered the issue. (Disclosure: I have met Jonathan Looney and know some of the Netflix engineering staff, but I don't work for Netflix.)

Re: SACK Panic – Multiple TCP-based remote denial-of-service issues

#40

Post by loeg »

sl-1 wrote: post #30

Is there any way to quickly test if any of my machines are vulnerable?

  [ "$(uname -s)" = Linux ] && echo "Vulnerable"
("CVE-2019-11479: Excess Resource Consumption Due to Low MSS Values (all Linux versions)", "CVE-2019-11478: SACK Slowness (Linux https://github.com/Netflix/security-bulletins/blob/master/ad...
Post reply on HN