Rendered at 16:26:16 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
grey-area 1 days ago [-]
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.
nialse 2 days ago [-]
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.
fractorial 2 days ago [-]
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
commandersaki 2 days ago [-]
Does `sysctl -w net.mptcp.enabled=0` work?
kyrra 1 days ago [-]
hopefully it doesn't hurt. I've set it just incase.
nialse 2 days ago [-]
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.
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.
> 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