Unfortunate news for Caddy which exposes unpatched Linux systems (confirmed) and may be common in container setups. Unclear if the container engine as a middle man actually helps mitigate the issue.
> Note that disabling MPTCP on a program-by-program basis is a fragile mitigation. Accidentally leaving a single MPTCP listener exposed will still leave a system vulnerable. Further, it assumes that all viable exploits for this bug depend on MPTCP. Again, we strongly recommend upgrading to a patched kernel version
The title is highlighting an unexpected exposure path. (Not my submission.) An unfortunately common combination. Agreed that the issue is in Linux, somehow the go surface area makes the situation much worse though.
There are some suggested mitigations on the issue:
You may also build a program with a different default by
placing a godebug multipathtcp=0 line in the main module's go.mod file; or
adding a //go:debug multipathtcp=0 line directly before the package main line.
Still unclear though whether that will fully mitigate this.
Unfortunate news for Caddy which exposes unpatched Linux systems (confirmed) and may be common in container setups. Unclear if the container engine as a middle man actually helps mitigate the issue.
From TFA:
> Note that disabling MPTCP on a program-by-program basis is a fragile mitigation. Accidentally leaving a single MPTCP listener exposed will still leave a system vulnerable. Further, it assumes that all viable exploits for this bug depend on MPTCP. Again, we strongly recommend upgrading to a patched kernel version
The title is highlighting an unexpected exposure path. (Not my submission.) An unfortunately common combination. Agreed that the issue is in Linux, somehow the go surface area makes the situation much worse though.
Does `sysctl -w net.mptcp.enabled=0` work?