https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-001.md
Do we have a fix in 5.*?
Will you make an patch for unsupported 4.*?
Do we have a fix in 5.*?
Will you make an patch for unsupported 4.*?
Crash any ProxMox, if you can open TCP session
- Thread starter mailinglists
- Start date
The patched kernel is already available in the pvetest/pve-no-subscription repository for 5.*, will be pushed to enterprise tomorrow. You can mitigate the issue by blocking small mss packets in your firewall.
Given that 4.* is out of support since june last year there won't be a patch. You can still use the mitigation path for it though.
See RedHat's Mitigation suggestion under the Resolve tab here: https://access.redhat.com/security/vulnerabilities/tcpsack
We have a subscription and are using the enterprise repository but it seems the updated kernel is not yet available yet?
[edit]
Sorry, I spoke too soon, it's available for me.
[edit]
Sorry, I spoke too soon, it's available for me.
Last edited:
Thanks for the fast update
One question tho: if a KVM mashine is attacked directly by its ip, will the host crash? As it just forwards the packages via bridge my understanding is that it should be fine. Is this correct?
Acutally im not asking this for proxmox but more for any router in a datacenter. They tend not to accept tcp connections directly, but only forward them.
Regards
With the kernel update on the Proxmox Ve Host the PVE Host and all containers are secured against this.
For VMs you need to pull in the respective kernel updates of the Linux Distribution inside the VM. Most a bit more popular Distros have updates ready since circa Tuesday.
A Firewall rule can also be applied which throws a way all segmented TCP packets with a very low size, see:
https://forum.proxmox.com/threads/proxmox-and-sack-attack.55257/
So, I'm rather a generalist in kernel internals knowledge and currently not to involved with the specifics of the TCP stack, with that in mind: yes, forwarded packages should not trigger this issue, as normally no TCP specific stuff is even done if a packet hits the forward chain early. But, any traffic directed to the router itself can trigger the issue. So I'd really try to update the router or, if no updates regarding this are available, apply firewall rules equivalent like the ones limiting small segmented TCP traffic, linked at in my previous post here.
Thanks. Thats good news!
unfortunately i cant update some switches because the ram is not enough, even tho the software is listed as "recommended update" for that concrete switch.. But since every TCP traffic (expect from trusted sources) is dropped, there should be not need to add specific rules for that CVE (in my case!!)
As soon as there is an public exploit i will test and report.
unfortunately i cant update some switches because the ram is not enough, even tho the software is listed as "recommended update" for that concrete switch.. But since every TCP traffic (expect from trusted sources) is dropped, there should be not need to add specific rules for that CVE
(in my case!!)As soon as there is an public exploit i will test and report.
For the benefit of those trying to find this advice via a web search, here are the relevant CVEs:
CVE-2019-11477: SACK Panic (Linux >= 2.6.29)
CVE-2019-11478: SACK Slowness (Linux < 4.15) or Excess Resource Usage (all Linux versions)
CVE-2019-11479: Excess Resource Consumption Due to Low MSS Values (all Linux versions)
CVE-2019-11477: SACK Panic (Linux >= 2.6.29)
CVE-2019-11478: SACK Slowness (Linux < 4.15) or Excess Resource Usage (all Linux versions)
CVE-2019-11479: Excess Resource Consumption Due to Low MSS Values (all Linux versions)
according to the Ubuntu wiki, there's no kernel patch for `CVE-2019-11479` -- which is the least serious vulnerability. https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SACKPanic
if I have a container with ubuntu OS in it how proxmox protects us and how each of the three CVE numbers (for linux) are affected?
You are encouraged to use the workaround with the filter of small segmented packets like mentioned in the link you posted. Given that Proxmox does offer you firewall management but doesn't mandate it it would be quite difficult to figure out how to apply such a rule into your ruleset to not interfer with other things. So please apply the rule yourself in the way you see it fit.
Container use the kernel from the host, so if you upgraded to pve-kernel-4.15.18-16-pve in version 4.15.18-41 or later and rebooted the host to actually boot the new kernel they are running the mitigations against the two main issues. Actual fixes are:
https://git.proxmox.com/?p=mirror_u...it;h=196379e675ffc658eb2414426d3f55311a575b46
https://git.proxmox.com/?p=mirror_u...it;h=94c027719d279e2a8ad90c83f2425d36137aaa80
As a note:
Details:
USN-4017-1 fixed vulnerabilities in the Linux kernel for Ubuntu.
Unfortunately, the update introduced a regression that interfered with
networking applications that setup very low SO_SNDBUF values. This
update fixes the problem.
So the current kernel 4.15.18-41 is still not fully patched.
Details:
USN-4017-1 fixed vulnerabilities in the Linux kernel for Ubuntu.
Unfortunately, the update introduced a regression that interfered with
networking applications that setup very low SO_SNDBUF values. This
update fixes the problem.
So the current kernel 4.15.18-41 is still not fully patched.
Just for completeness, you are referencing USN-4041-1: https://usn.ubuntu.com/4041-1/
Please link such information and not just copy the text, though we are tracking this of course and are aware. It's not overlooked and on our radar.
Will do.
It was more of a hin for other users then for you guys, i allready saw some updates in pvetest
FYI: should have been fixed with: https://git.proxmox.com/?p=pve-kernel.git;a=commitdiff;h=6ba8c6bc5d083be3dc054db38531b28393c4f92f
Which currently goes through our package repositories as 4.15.18-43, which as you already noticed is available on pvetest (will move to other repos this week)