More vulnerabilities [PinTheft] [DirtyDecrypt]

Arch specific vulnerability;

and another Dirty* vulnerability

addendum;
mitigation for the Arch specific issue;

rmmod rds_tcp rds
printf 'install rds /bin/false\ninstall rds_tcp /bin/false\n' > /etc/modprobe.d/pintheft.conf

mitigation for DirtyDecrypt remains same as DirtyFrag:

sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; echo 3 > /proc/sys/vm/drop_caches; true"

addendum 2:
“manjaro is not arch”, if manjaro kernels are built (unlike arch) with these RDS modules disabled, there is chance manjaro-kernels are unaffected. ATM i have hard time accessing manjaro gitlab to see if that is the case. pretty sure will get to the bottom of this soon enough.

could only access linux618 build-config and RDS modules are also enabled like it is in arch.

7 Likes

This is looking bad for Linux, but on the other hand, I can’t help but wonder what number of vulnerabilities are found in closed source software that we the public never find out about.

1 Like

Transparency makes open source stronger as long as fixes get made (and I’m confident that will happen with Linux kernel and other open source projects like Arch). I looked at the PinTheft PoC and yeah, the modules are there, but for my system, there is no use case where that PoC would happen. For production systems, the story could be very different. Everyone should do their due diligence and react accordingly. I add the mitigation steps when it makes sense and track the news. Thanks for the heads up!

4 Likes

Actually you don’t need it, you can check currently booted kernel build parameters with

 zcat /proc/config.gz | grep -i rds

and yes, on linux70 it’s also enabled.

2 Likes

On kernel 7.1. those are on manual.

In another topic someone posted what is probably the ultimate solution

p.s. added the new info to update FAQ/Solutions

5 Likes

What about if, one has already run modulejail?

https://forum.manjaro.org/t/belgian-sysadmin-creates-modulejail-for-automatically-blacklisting-unused-modules/187739/20

That should have made all those modules unavailable.

Exactly. (One can open the modulejail.conf and check, what i personally did)

1 Like

I can confirm that running sudo sh ~/.local/bin/modulejail -p desktop a couple of days ago on my system did disable all of the mentioned modules:

❯ rmmod rds_tcp rds esp4 esp6 rxrpc
rmmod: ERROR: Module rds_tcp is not currently loaded
rmmod: ERROR: Module rds is not currently loaded
rmmod: ERROR: Module esp4 is not currently loaded
rmmod: ERROR: Module esp6 is not currently loaded
rmmod: ERROR: Module rxrpc is not currently loaded
❯ grep -Ei 'rds |rds_tcp |esp4 |esp6 |rxrpc ' /etc/modprobe.d/modulejail-blacklist.conf
install esp4 /bin/sh -c '/usr/bin/logger -t modulejail "blocked: esp4" 2>/dev/null; exit 0'
install esp6 /bin/sh -c '/usr/bin/logger -t modulejail "blocked: esp6" 2>/dev/null; exit 0'
install rds /bin/sh -c '/usr/bin/logger -t modulejail "blocked: rds" 2>/dev/null; exit 0'
install rds_tcp /bin/sh -c '/usr/bin/logger -t modulejail "blocked: rds_tcp" 2>/dev/null; exit 0'
install rxrpc /bin/sh -c '/usr/bin/logger -t modulejail "blocked: rxrpc" 2>/dev/null; exit 0'
4 Likes

I’ve installed this modulejail.conf, does I need it even with the latest kernels installed (7.0.9 - 6.18.32) ?

With the speed AIs are breaking things nowadays i will leave it as a precaution.

4 Likes

Me too. It’s unlikely I will ever need those modules anyway.

1 Like