Comment by jlgaddis | Hacker News Reader

Comment by jlgaddis | Hacker News Reader

  $ echo "install dccp /bin/true" >> /etc/modprobe.d/dccp.conf
  $ sudo rmmod dccp   # in case it's already loaded

This is a good idea for any modules you don't expect to ever need. In my case:

  $ cat /etc/modprobe.d/disabled_modules.conf
  install appletalk /bin/true
  install bluetooth /bin/true
  install cramfs /bin/true
  install dccp /bin/true
  install firewire-core /bin/true

  *snipped*

  install tipc /bin/true
  install udf /bin/true
  install usb-storage /bin/true
  install vfat /bin/true

The original -- to me -- recommendations for this were found in some "hardening guide" for RHEL (CIS, NSA, etc.), although I don't remember which.

See also the "modprobe.blacklist=" kernel parameter, which you'll have to use for "modules" that are compiled into the kernel itself (i.e., they are not actually loadable kernel modules).

15 years ago, when building your own kernels was a normal everyday thing, I simply built my kernels with everything compiled in and modules disabled. This (would have) prevented attacks such as kernel-level rootkits.

In addition, "one neat trick" was that you could halt (not poweroff) the machine (!) -- such as in the case of a Linux box simply acting as a router/firewall -- and the kernel would still be running. Good luck compromising that! :-)

This is a useful post. I'm going to nerd out at you though and point out that disabling LKMs doesn't really do anything to disable kernel-resident rootkits; any kernel memory corruption vulnerability can be used to create an ad-hoc module loader.

If you Google for amodload, you can find (uuencoded, in a Bugtraq message --- it's 2017 and I just uudecoded something!) Josh Daymont's old SunOS 4.1.3 modloader hack, which overwrote a kernel socket callback and used socket buffers to hold module text.

> This is a useful post. I'm going to nerd out at you though and point out that disabling LKMs doesn't really do anything to disable kernel-resident rootkits; ...

I really hate to question you but... are you sure?

The particular case that I'm thinking of was probably ~15 years ago. There was some 0-day or worm or something (details are a little vague now, obviously) that would install a kernel module and then loaded it to hide itself.

I can recall a discussion at the time and this was a recommendation. It wasn't just disabling individual modules -- it was actually disabling support for loading kernel modules. That is, whatever the kernel itself needed in order to support dynamic loading of modules at run-time was needed; the kernel was not able to load a module.

Like I said, it's been probably 15 years ago and I'm sure I'm not remembering everything 100% correctly so you may very well be correct... but I'm almost certain you could entirely disable loading of kernel modules (the kernel itself didn't support loading them).

Googling "amodload" now, thanks for the pointer...

The kernel has function pointers and dynamic memory. You can "build" a module if you need to.

Interesting. Thanks.

Check out amodload; that was what was so interesting about it at the time: it built its own module loader back into a kernel compiled without loadable modules. If course: table stakes for modern rootkits!

Thanks for the replies and pointers, Thomas. You've given me even more to read and learn about.

Surely if you can write to /dev/mem, it doesn't matter whether your kernel has support for modules or not. You could just create a rootkit which is not in the form of a loadable module.

EDIT: Here's an example of this very thing. https://www.blackhat.com/presentations/bh-europe-09/Lineberr...

Great advice. Using /bin/false also works, as I found on the Arch Wiki. Do you know what the difference is?

  modprobe dccp #with /bin/false fails with
  
  modprobe: ERROR: Error running install command for dccp
  modprobe: ERROR: could not insert 'dccp': Operation not permitted

/bin/true sets the return code to 0, signifying success to the modprobe process, /bin/false sets it to 1, signifying failue, and producing said message.

Due to the way modprobe may be hooked by various things, its best to use /bin/true to ensure less breakage.

Like throwaway2048 mentioned, the only difference is the return code.

I think the original documentation described them something like this: /bin/true does nothing, successfully. /bin/false does nothing, unsuccessfully.

Sounds like your referring to STIG.

Among others, yes.

Isn't VFAT required for UEFI?

Wouldn't it only be required if you wanted to mount the UEFI system partition? (Which is formatted in a variant of the FAT FS, IIRC.) If you don't want to mount the system partition, you shouldn't need the module. (Although, my system puts kernel images there. IDK if this is typical of UEFI systems. IIRC, Grub is capable of loading from ext FSs, so this shouldn't be a hard-and-fast requirement.)

Well, even if kernel images didn't go there, you would still need to access it for grub updates. So it might not be a good recommendation for everyday users.

No idea, that particular host doesn't use UEFI.

Reply on news.ycombinator.com