Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Singularity Rootkit: SELinux bypass and netlink filter (ss/conntrack hidden)

github.com

Post reply on HN
Print view View original

31–40 of 58 posts

Re: Singularity Rootkit: SELinux bypass and netlink filter (ss/conntrack hidden)

#31

Post by Joel_Mckay »

wmf wrote: post #29
RandomGerm4n wrote: post #14

This does not seem to work with Fedora Atomic. Because the system is read-only, the kernel module cannot be loaded. You would have to create an RPM package for the rootkit that you can then layer. In addition, due to Secure Boot, the kernel module would have to be signed with the same key as the system itself.

insmod can load a module from anywhere (surely /tmp is writable), even stdin. That's why you definitely want to block unknown kernel modules.

Most production OS I saw would do this on boot-up completion:

echo 1 > /proc/sys/kernel/modules_disabled

Which is supposed to block dynamic loading modules until a reboot.

It would be interesting if the PoC can get around that trick too. =3

Re: Singularity Rootkit: SELinux bypass and netlink filter (ss/conntrack hidden)

#32

Post by Joel_Mckay »

hulitu wrote: post #24
egberts1 wrote: post #21

Entry vector is via user-loadable kernel modules. Does not work if kernel Kconfig setting has: CONFIG_MODULES=n All deliverables should have this Kconfig setting disabled.

> CONFIG_MODULES=n does this work on normal linux desktops ? My impression was that either: 1). Kernel is too big. Try making modules - link error or 2) System will not boot due to missing/misconfigured parts.

Could always try:

echo 1 > /proc/sys/kernel/modules_disabled

Which is supposed to block dynamic loading modules until a reboot. =3

Re: Singularity Rootkit: SELinux bypass and netlink filter (ss/conntrack hidden)

#33

Post by bflesch »

KZerda wrote: post #18
bflesch wrote: post #4

Nice. Could it be detected by comparing output of `find /` at runtime with output of `find /` if you mount the disk on another system?

Yes. Offline is how a lot of rootkits are analyzed after the admin notices peculiar behavior. There are a lot of other tells that could be run online to find this rootkit though, most notably, its behavior with ftrace. Disabling ftrace, and then running a program that uses ftrace would tell right away that something's wrong.

Thanks. So for virtualized systems it would make sense to routinely clone the HDD and do such a comparison. Could easily be included in the backup software.

Re: Singularity Rootkit: SELinux bypass and netlink filter (ss/conntrack hidden)

#35

Post by matheuzsec »

Joel_Mckay wrote: post #32
hulitu wrote: post #24

Earlier quoted context omitted.

> CONFIG_MODULES=n does this work on normal linux desktops ? My impression was that either: 1). Kernel is too big. Try making modules - link error or 2) System will not boot due to missing/misconfigured parts.

Could always try: echo 1 > /proc/sys/kernel/modules_disabled Which is supposed to block dynamic loading modules until a reboot. =3

This is not permanent; if the system is rebooted, it will be undone :)

Re: Singularity Rootkit: SELinux bypass and netlink filter (ss/conntrack hidden)

#36

Post by lima »

Joel_Mckay wrote: post #31
wmf wrote: post #29

Earlier quoted context omitted.

insmod can load a module from anywhere (surely /tmp is writable), even stdin. That's why you definitely want to block unknown kernel modules.

Most production OS I saw would do this on boot-up completion: echo 1 > /proc/sys/kernel/modules_disabled Which is supposed to block dynamic loading modules until a reboot. It would be interesting if the PoC can get around that trick too. =3

If Kernel Lockdown is enabled, a zero-day exploit is required to bypass module restrictions without a reboot.

Unfortunately, threat actors tend to have a stash of them and the initial entry vector often involves one (container or browser sandbox escape), and once you have that, you are in ring 0 already and one flipped bit away from loading the module.

The Linux kernel is not really an effective privilege boundary.

Re: Singularity Rootkit: SELinux bypass and netlink filter (ss/conntrack hidden)

#37

Post by finagler »

mmh0000 wrote: post #12

Hiding from SELinux is clever, but SELinux (for most users not running MLS) is a final level of defense. If you get to the point where SELinux is saving your butt, you've got problems higher up in the stack. For me, the real scary part is the hiding "Audit Evasion" (for those not in the know, here's a link https://www.redhat.com/en/blog/configure-linux-auditing-audi... ); Audit is supposed to be able to track anythin…

> SELinux (for most users not running MLS) is a final level of defense

if so, why is it there at all?

Years back when our team was dealing with weird permission issues on multiple levels due to SELinux, I found little value in it.

Re: Singularity Rootkit: SELinux bypass and netlink filter (ss/conntrack hidden)

#38

Post by bitfilped »

finagler wrote: post #37
mmh0000 wrote: post #12

Hiding from SELinux is clever, but SELinux (for most users not running MLS) is a final level of defense. If you get to the point where SELinux is saving your butt, you've got problems higher up in the stack. For me, the real scary part is the hiding "Audit Evasion" (for those not in the know, here's a link https://www.redhat.com/en/blog/configure-linux-auditing-audi... ); Audit is supposed to be able to track anythin…

> SELinux (for most users not running MLS) is a final level of defense if so, why is it there at all? Years back when our team was dealing with weird permission issues on multiple levels due to SELinux, I found little value in it.

...as a last line of defense. MAC is also a stronger system than DAC to being with, so a lot of places may opt to have it in place anyway for inexperienced/careless/lazy admin mistakes. Sorry you struggled with writing SEL policies, but it's a very valuable tool when you run systems that are exposed to the internet or other hostile environments.

Re: Singularity Rootkit: SELinux bypass and netlink filter (ss/conntrack hidden)

#39

Post by worthless-trash »

Joel_Mckay wrote: post #31
wmf wrote: post #29

Earlier quoted context omitted.

insmod can load a module from anywhere (surely /tmp is writable), even stdin. That's why you definitely want to block unknown kernel modules.

Most production OS I saw would do this on boot-up completion: echo 1 > /proc/sys/kernel/modules_disabled Which is supposed to block dynamic loading modules until a reboot. It would be interesting if the PoC can get around that trick too. =3

Once you have memory write as ring0, all protections are dubious at best.

Why bother loading a module when you can inject code into any function you want.

Re: Singularity Rootkit: SELinux bypass and netlink filter (ss/conntrack hidden)

#40

Post by worthless-trash »

Joel_Mckay wrote: post #31
wmf wrote: post #29

Earlier quoted context omitted.

insmod can load a module from anywhere (surely /tmp is writable), even stdin. That's why you definitely want to block unknown kernel modules.

Most production OS I saw would do this on boot-up completion: echo 1 > /proc/sys/kernel/modules_disabled Which is supposed to block dynamic loading modules until a reboot. It would be interesting if the PoC can get around that trick too. =3

Or only allow signed kernel modules. Aka secure boot.

This doesn't solve all vectors but afaics this will prevent non signed modules from loading.

Post reply on HN