> 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 reads disingenuous implying that Go programs are uniquely exposed or MPTCP is the only attack vector (it isn’t).
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.
Unfortunate news for Caddy which exposes unpatched Linux systems and may be common in container setups. Unclear if the container engine as a middle man actually helps mitigate the issue.
6 comments
[ 0.26 ms ] story [ 9.7 ms ] thread> 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 reads disingenuous implying that Go programs are uniquely exposed or MPTCP is the only attack vector (it isn’t).
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.