5 ms·

"This attack did not work against any Linux distribution we tested until the release of Ubuntu 19.10, and we noticed that the rp_filter settings were set to “lo

"This attack did not work against any Linux distribution we tested until the release of Ubuntu 19.10, and we noticed that the rp_filter settings were set to “loose” mode. We see that the default settings in sysctl.d/50-default.conf in the systemd repository were changed from “strict” to “loose” mode on November 28, 2018, so distributions using a version of systemd without modified configurations after this date are now vulnerable. Most Linux distributions we tested which use other init systems leave the value as 0, the default for the Linux kernel." Anybody happen to know why systemd decided this was something they should be messing with?

arianvanp 7y ago
`git blame` is your friend sysctl.d: switch net.ipv4.conf.all.rp_filter from 1 to 2 This switches the RFC3704 Reverse Path filtering from Strict mode to Loose mode. The Strict mode breaks some pretty common and reasonable use cases, such as keeping connections via one default route alive after another one appears (e.g. plugging an Ethernet cable when connected via Wi-Fi). The strict filter also makes it impossible for NetworkManager to do connectivity check on a newly arriving default route (it starts with a higher metric and is bumped lower if there's connectivity). Kernel's default is 0 (no filter), but a Loose filter is good enough. The few use cases where a Strict mode could make sense can easily override this. The distributions that don't care about the client use cases and prefer a strict filter could just ship a custom configuration in /usr/lib/sysctl.d/ to override this. https://github.com/systemd/systemd/commit/230450d4e4f1f5fc9fa4295ed9185eea5b6ea16e https://github.com/systemd/systemd/commit/230450d4e4f1f5fc9f... There was NEWS entry for this here: https://github.com/systemd/systemd/blob/230450d4e4f1f5fc9fa4295ed9185eea5b6ea16e/NEWS#L73-L80 https://github.com/systemd/systemd/blob/230450d4e4f1f5fc9fa4... as to _why_ they would make the change? Systemd trieds to be project for distros to have a sane base system. Introducing this change was probably something they deemed as being useful in a base system. Especially in the context of laptops and mobile devices this default seems sane.
- 0xbadcafebee 7y ago
  > Systemd trieds to be project for distros to have a sane base system Systemd tries to force a monolithic operating system to behave like a microkernel, and uses propaganda and manipulation to enforce whatever preference its designers have for how all systems should run onto all the Linux distributions it can. You can call that 'sane', I'll call it totalitarian empire-building.
jeroenhd 7y ago
On Github I found this commit: https://github.com/systemd/systemd/commit/230450d4e4f1f5fc9fa4295ed9185eea5b6ea16e https://github.com/systemd/systemd/commit/230450d4e4f1f5fc9f... The explanation in the commit message said this: ------ This switches the RFC3704 Reverse Path filtering from Strict mode to Loose mode. The Strict mode breaks some pretty common and reasonable use cases, such as keeping connections via one default route alive after another one appears (e.g. plugging an Ethernet cable when connected via Wi-Fi). The strict filter also makes it impossible for NetworkManager to do connectivity check on a newly arriving default route (it starts with a higher metric and is bumped lower if there's connectivity). Kernel's default is 0 (no filter), but a Loose filter is good enough. The few use cases where a Strict mode could make sense can easily override this. The distributions that don't care about the client use cases and prefer a strict filter could just ship a custom configuration in /usr/lib/sysctl.d/ to override this. ------ I do not know enough about NetworkManager or sysctl parameters to completely understand if this is a valid reason or not, but this sounds like an acceptable explanation for the change to me.
Foxboron 7y ago
It should be noted that setting the rp_filter to either 0 or 1 doesn't mitigate the entire attack. Just parts of it.
- tolleydbg 7y ago
  Correct. It does completely prevent the attack for IPv4, however, so we didn't notice the attack until the rp_filter settings were changed. I can verify that turning rp_filter on in my use case is an acceptable solution on Manjaro and Ubuntu. EDIT: To clear up the confusion below, I was saying that setting the rp_filter variable to strict mode does prevent this attack from working against IPv4, and in my situation, this is enough since I am not using IPv6 or any complicated routing on my network etc.
  - Hello71 7y ago
    I don't understand why it would be different for IPv6. are you just referring to the fact that there is no sysctl for reverse path filtering for IPv6? does it still work with ip6tables -t raw -A PREROUTING -m rpfilter --invert -j DROP?
  - Foxboron 7y ago
    I'm confused! You write that turning rp_filter to 0 or 1 prevents the attack? While the report says that parts of the attack can't be accomplished. Does it completely prevent the attack, or only parts of it? This isn't clear when reading this comment, and the initial oss-sec disclosure. Important as Arch Linux is contemplating possible patching or not.
    - loeg 7y ago
      They edited their comment to clarify that only strict mode ("2") prevents the attack, against IPv4.
      - Foxboron 7y ago
        2 is loose. 1 is strict.
JackRabbitSlim 7y ago
Let me paraphrase: "All the questionable Redhat-backed additions like systemd and Networkmanager aren't great or particularly fit and fixing them so plugging in network cables doesn't disrupt existing connections was too hard. Have downgraded security instead. If you care just re-enable and suffer our broken stack." GCC 2.96, Pulse Audio, NetworkManager, systemd... I've assumed the death of (truly open) Linux would be at the hands of Redhat, this is just another stab wound.
- arianvanp 7y ago
  The issue has nothing to do with systemd. Systemd just happened to enable a sysctl parameter that is needed for multiple network interfaces to work fluently in the first place. This is a problem in Linux kernel networking stack or openvpn.

arianvanp 7y ago

`git blame` is your friend sysctl.d: switch net.ipv4.conf.all.rp_filter from 1 to 2 This switches the RFC3704 Reverse Path filtering from Strict mode to Loose mode. The Strict mode breaks some pretty common and reasonable use cases, such as keeping connections via one default route alive after another one appears (e.g. plugging an Ethernet cable when connected via Wi-Fi). The strict filter also makes it impossible for NetworkManager to do connectivity check on a newly arriving default route (it starts with a higher metric and is bumped lower if there's connectivity). Kernel's default is 0 (no filter), but a Loose filter is good enough. The few use cases where a Strict mode could make sense can easily override this. The distributions that don't care about the client use cases and prefer a strict filter could just ship a custom configuration in /usr/lib/sysctl.d/ to override this. https://github.com/systemd/systemd/commit/230450d4e4f1f5fc9fa4295ed9185eea5b6ea16e https://github.com/systemd/systemd/commit/230450d4e4f1f5fc9f... There was NEWS entry for this here: https://github.com/systemd/systemd/blob/230450d4e4f1f5fc9fa4295ed9185eea5b6ea16e/NEWS#L73-L80 https://github.com/systemd/systemd/blob/230450d4e4f1f5fc9fa4... as to _why_ they would make the change? Systemd trieds to be project for distros to have a sane base system. Introducing this change was probably something they deemed as being useful in a base system. Especially in the context of laptops and mobile devices this default seems sane.

0xbadcafebee 7y ago
> Systemd trieds to be project for distros to have a sane base system Systemd tries to force a monolithic operating system to behave like a microkernel, and uses propaganda and manipulation to enforce whatever preference its designers have for how all systems should run onto all the Linux distributions it can. You can call that 'sane', I'll call it totalitarian empire-building.

jeroenhd 7y ago

On Github I found this commit: https://github.com/systemd/systemd/commit/230450d4e4f1f5fc9fa4295ed9185eea5b6ea16e https://github.com/systemd/systemd/commit/230450d4e4f1f5fc9f... The explanation in the commit message said this: ------ This switches the RFC3704 Reverse Path filtering from Strict mode to Loose mode. The Strict mode breaks some pretty common and reasonable use cases, such as keeping connections via one default route alive after another one appears (e.g. plugging an Ethernet cable when connected via Wi-Fi). The strict filter also makes it impossible for NetworkManager to do connectivity check on a newly arriving default route (it starts with a higher metric and is bumped lower if there's connectivity). Kernel's default is 0 (no filter), but a Loose filter is good enough. The few use cases where a Strict mode could make sense can easily override this. The distributions that don't care about the client use cases and prefer a strict filter could just ship a custom configuration in /usr/lib/sysctl.d/ to override this. ------ I do not know enough about NetworkManager or sysctl parameters to completely understand if this is a valid reason or not, but this sounds like an acceptable explanation for the change to me.

Foxboron 7y ago

It should be noted that setting the rp_filter to either 0 or 1 doesn't mitigate the entire attack. Just parts of it.

tolleydbg 7y ago
Correct. It does completely prevent the attack for IPv4, however, so we didn't notice the attack until the rp_filter settings were changed. I can verify that turning rp_filter on in my use case is an acceptable solution on Manjaro and Ubuntu. EDIT: To clear up the confusion below, I was saying that setting the rp_filter variable to strict mode does prevent this attack from working against IPv4, and in my situation, this is enough since I am not using IPv6 or any complicated routing on my network etc.
- Hello71 7y ago
  I don't understand why it would be different for IPv6. are you just referring to the fact that there is no sysctl for reverse path filtering for IPv6? does it still work with ip6tables -t raw -A PREROUTING -m rpfilter --invert -j DROP?
- Foxboron 7y ago
  I'm confused! You write that turning rp_filter to 0 or 1 prevents the attack? While the report says that parts of the attack can't be accomplished. Does it completely prevent the attack, or only parts of it? This isn't clear when reading this comment, and the initial oss-sec disclosure. Important as Arch Linux is contemplating possible patching or not.
  - loeg 7y ago
    They edited their comment to clarify that only strict mode ("2") prevents the attack, against IPv4.
    - Foxboron 7y ago
      2 is loose. 1 is strict.

JackRabbitSlim 7y ago

Let me paraphrase: "All the questionable Redhat-backed additions like systemd and Networkmanager aren't great or particularly fit and fixing them so plugging in network cables doesn't disrupt existing connections was too hard. Have downgraded security instead. If you care just re-enable and suffer our broken stack." GCC 2.96, Pulse Audio, NetworkManager, systemd... I've assumed the death of (truly open) Linux would be at the hands of Redhat, this is just another stab wound.

arianvanp 7y ago
The issue has nothing to do with systemd. Systemd just happened to enable a sysctl parameter that is needed for multiple network interfaces to work fluently in the first place. This is a problem in Linux kernel networking stack or openvpn.