[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

Blacklist more kernel modules to reduce attack surface

Instead of creating a bunch of different threads for different kernel modules, we can just use this one.

We can blacklist more kernel modules to reduce attack surface further. This can include a bunch of uncommon modules or things unlikely to be used.

We can blacklist a bunch of uncommon filesystems by creating a file in /etc/modprobe.d with

install cramfs /bin/true
install freevxfs /bin/true
install jffs2 /bin/true
install hfs /bin/true
install hfsplus /bin/true
install squashfs /bin/true
install udf /bin/true

This blacklists cramfs, freevxfs, jffs2, hfs, hfsplus, squashfs and udf.

We can blacklist the CD-ROM kernel modules with

install cdrom /bin/true
install sr_mod /bin/true

I doubt CD-ROMs would be used within Whonix and the CD-ROM kernel driver has had some vulnerabilities before such as CVE-2018-11506.

We can blacklist the PC speaker module with

install pcspkr /bin/true

This will mostly be helpful for discretion purpose. This can cause the computer to make various beeps or other noises.

Tails also blacklists this.

https://git-tails.immerda.ch/tails/plain/config/chroot_local-includes/etc/modprobe.d/no-pc-speaker.conf

https://redmine.tails.boum.org/code/issues/5724

The MEI is the interface between the Intel ME and the OS. The Intel ME is dangerous as it has access to basically everything and the MEI may have some vulnerability that allows exploitation of the ME.

It can be disabled with

install mei /bin/true
install mei-me /bin/true

Tails also blacklists this although it seems to be because of a bug that messed up shutdown.

allow loading signed kernel modules by default / disallow kernel module loading by default won’t make this pointless as many of these can be loaded at boot, before kernel.modules_disabled=1 is set and some users may revert that (if it is ever implemented).

1 Like

There is talk of implementing an alternative verified boot using emulated disc drives and iso images /cc @Patrick These changes would very likely interfere with this.

squashfs may be used for live mode?

IMO let’s stick to what Tails does at the moment.

1 Like

No, the initial boot drive doesn’t depend on what the chainloaded kernel on the main drive does.

Note, that security-misc package is unspecific to Whonix. A general package.

security-misc will be installed by default in Kicksecure and on Whonix-Host. Therefore must not break general hosts.

Can you implement a new vm-hardening package?

3 Likes

I doubt CD-ROMs would be used within Whonix and the CD-ROM kernel driver has had some vulnerabilities before such as CVE-2018-11506.

How to exploit, how to make the kernel load the module?

Irrelevant in a VM without cd-rom drive?

A VM without cd-rom drive won’t have the module. Won’t need the config therefore?

and a VM with cd-rom drive should work out of the box because the drive was manually added?

2 Likes

I just tested it and live mode works fine with squashfs blacklisted.

It can easily be removed for things that need CD-ROMs. I imagine most would be using USBs instead anyway.

No, it’s loaded by default whether you add it or not. Run lsmod and you’ll see the cdrom and sr_mod modules already loaded.

lsmod | grep cd

Shows nothing for me in a Qubes VM.

1 Like

How could an attacker make the kernel load such a module?

Similar as above:

  • A sysadmin having attached a device which contains such a file system and wanting to mount it, should be able to.
  • Without attempting to mount such a device, no module will be load.

No module load -> no exploitation attempt using that module possible.

Or are there other ways a non-root user may cause loading such a module?

2 Likes

Live mode does not use squashfs, but the host/iso does which will fail if the module is not loaded.
Instead of blacklisting you could also skip compiling them into the custom kernel. I guess the cloud kernel from the debian repo won’t have most of those and other stuff. But I also could not get it to work.

Why just stick to non-root?

2 Likes

Because root access means game over if malware gained root. The attacker has way too many ways to compromise the system in persistent ways. Root should be allowed to load the module / mount any disk.

2 Likes

Modprobing stuff would be one of the options for a kernel exploit. Certainly not the only one but at least one options less for the attacker.

Edit: We also have apparmor which limits what a user, including root, can do.

2 Likes

Larger discussion. Created Untrusted Root - does it make sense to try to improve security by restricting root? for it.

2 Likes

It’s there for me in Virtualbox. Virtualbox might add CD-ROM support by default while Qubes only adds the bare minimum. If so, is there a way to disable it in the Virtualbox ovas by default?

An attacker could attempt to mount something containing the filesystem which will load the module.

Things like thunar-volman and udisks allow unprivileged mounting.

Root can just remove the file that blacklists these modules anyway.

Ubuntu’s default blacklisted modules: https://git.launchpad.net/ubuntu/+source/kmod/tree/debian/modprobe.d?h=ubuntu/disco

2 Likes
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]