Hacker News Reader

Comment by agwa | Hacker News Reader

> A common exploit vector is going through shared memory (which can let you change the UID of running programs and other malicious actions).

What? Citation needed. /dev/shm is simply a mount point for a memory-backed filesystem, much like /tmp. There's absolutely nothing special you can do with it.

The POSIX shared memory (i.e. shm_open) implementation on Linux does put its files in /dev/shm. By making /dev/shm read-only you're effectively disabling POSIX shared memory. Maybe some applications have vulnerabilities because they use POSIX shared memory unsafely? In that case you probably want to identify and upgrade those applications instead of disabling something system-wide that may cause legitimate programs to break.

View on HN

It appears he's just referring to an ancient (2.6.16.5) Linux kernel bug. "Don't use unpatched versions of obsolete kernels" would be better advice.

To be honest, I don't know what the author means; but I've seen web exploits using /dev/shm as alternative location to dump scripts (the other usual suspects are /tmp and /var/tmp). The web server process can write there, spawn a new process, etc.

I think it's better to protect the entry point (ie. in PHP, use php.ini open_basedir).

I could see making all writable filesystems noexec - _that_ would make sense. Making all of /dev/shm read-only, and thus breaking the POSIX shared memory API? Madness.

It is a common hiding place once the box has been broken into, not necessarily something that would be attacked right away. If you look on google you can see plenty of evidence of people's boxes being compromised through insecure shared memory and you can find plenty of examples of shared memory being exploited for privilege escalation and hiding malicious files.

What makes /dev/shm a better hiding place than /tmp or /var/tmp?

In automated exploitation (e.g. scanning for common classes of web vulnerabilities) /dev/shm is better because it doesn't touch the disk filesystem. It's also not an obvious place people use on a regular basis (as opposed to /tmp) so (some) people are less likely to look for things in there.

/tmp sometimes uses tmpfs which is also memory based, but not always and you won't know until you're in /tmp.

/dev/shm is a better hiding place than /tmp or /var/tmp because if someone notices something weird on a server their instinct might to be power it off or reboot it. A power cycle will wipe /dev/shm since it is memory backed storage. Lots of places will remove the network, power off the machine, and disk image the affected server for later analysis.

/tmp is also normally cleared on a reboot.

More precisely, it should not be relied on being persistent across reboots, vs /var/tmp which can be.

Reply on news.ycombinator.com