After I found the alert
I’ve switched my system offline, hoping that we might have a patch pretty soon. I’ve seen the proposal for mitigation, but did not understand it; therefore i don’t like to run it. Furthermore I’ve seen more alerts meanwhile …
So my question: How are you handling this and how risky is it, to switch online again (all actual updates are installed)?
The mitigation:
Explaination:
rmmod is a utility to remove a module from the Linux kernel. In this context it removes esp4, esp6 and rxrpc modules from your kernel.
The next line:
printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf
creates a file /etc/modprobe.d/dirtyfrag.conf with the contents:
install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false
This prevents these modules being loaded each boot. Without this you would have to run the rmmod command every time you rebooted your machine, and would also mean an attacker would just need to reboot your machine in order to make it vulnerable again.
Additionally, not in Phils instructions, once you have applied this you must reboot as a machine that had loaded these modules is still vulnerable until it boots without the modules.
Unless you are using IPSec it is unlikely you will be using these modules anyway. You can confirm with lsmod | sort (this lists loaded modules and sorts them alphabetically).
I am waiting on a kernel update (6.18.30-2) on testing branch for [ALERT] ssh-keysign-pwn, but I know that my system cannot be affected by this (or previous) vulnerabilities, so I have not disabled online access
(But the weather is good so I will probably be hanging out in the garden with my mp3 player most of the time)
Thanks a lot, excellent explanation!
Obviously I’m not using IPsec:
$ lsmod | sort
iprqbypass
iwl...
Am I right, to run the two commands OFFline, reboot and then switch ONline again?
How are the experiences from the community with the mitigation so far? I could wait for the kernel update until Monday …
Don’t be that paranoid. Of the 4 vulnerabilities, 2 are already patched and installed, 1 is patched and will come with next stable update (or you can switch to other branch), one is in the making but there is mitigation. The mitigation may have side effects by a very small number of users, so it is pretty much a solution too. Besides, keeping the pc offline doesn’t make any sense for local privileges escalation (unless you run a ssh server). Philipp joked with the sentence that you shoud turn off the pc, turn off the electricity, close all doors windows curtains and hide under the bed 
Use your pc as usual and keep it updated. With every update there are many more vulnerabilities patched, that are there but just don’t make it to the newspaper frontpages.
P.s. and apply the mitigation disabling the modules
That is not correct, as the first command unloads the affected modules from the running kernel, and therefore, doing so removes the vulnerability.
An attacker would already need to have root access on your system in order to reload the kernel modules into the running kernel, in which case they wouldn’t need to, since they’d have root access already.
Yes.
I simply ran the commands to blacklist the modules. I wasn’t using them anyway.
Panic is an ill adviser.
Sorry I wasn’t very clear on this point - You want to be looking for the modules affected not for IPSEC. So esp4, esp6 and rxrpc
The exploit allows anyone who is already logged into a vulnerable Linux computer to boost their access privilege from a regular user to the all-powerful Linux superuser account. So your computer is really only vulnerable if you have other accounts on it and those people are untrusted. I’m assuming if you’re asking these questions, that doesn’t fit your scenario.
I’d be more worried about any cloud services etc that contain your data rather than general PC users.
Thanks
esp4, esp6 and rxrpc
are not loaded. And I don’t have other accounts on it.
So: Should I run the mitigation or not?
Yes I borked up that explanation. What I should have said is if the system is already compromised, the mitigation doesn’t remove the access until the system is rebooted with the mitigation in place.
As per: Mitigation doesn't stop exploit · Issue #1 · V4bel/dirtyfrag · GitHub
Yes, to prevent them being loaded in the future.
Since I’m the only user who logs on to my machines, (the only user created, other than root) and I already have access to the superuser account, it’s a non-issue for me.
One thing to think about, though, is that if this were happening in Microsoft:
There was an issue about 10 to 15 years ago whereby a very dangerous exploit in Outlook Express was published, and where it turned out that Microsoft had already been aware of this vulnerability for over a decade but decided not to publish anything or even remedy the problem because “it hadn’t been exploited in the wild yet.”
I’m trying to give them some credit for improving over the years…
I didn’t apply any mitigation. I’ll just refrain from installing new software until the fix is out. I’m the only user of my two machines, so I’m not worried at all.
there’s no reason for micro-bashing when linux-maintainers/devs act in the same manner. a impact at the ssh-system caused by an bug that was known and blantantly ignored for six years (!) is no ruhmesblatt.
Mod edit:- Some enjoy having a dig at our friends in Redmond – at the end of the day, they (as with Linux projects) are sometimes under immense pressure to deliver a product to market – spare a kind thought for hard workers everywhere.
They, as in Microsoft the Company, often deserve many of the derogatory comments, especially recently where it is actually possible they left certain back doors in place, rather than fixing the ‘bugs’ that caused them.