CODEWITHSUNDEEP
linuxmultithreadingsecurityoperating-systemshared-memory
nerowim
nerowim

Reputation: 91

Is shared memory with an untrusted process safe?

I'm trying to create an x86 Linux program that runs with elevated privileges but can also run potentially unsafe code in a child process and communicate with it via shared memory, mainly for performance reasons. My idea looks like this:

What are the pitfalls of accessing the shared memory afterwards? Obviously the child process can supply invalid data and change it at any time, but can it actually harm the parent process in other ways like blocking the memory access, even killing it off or anything comparable?

Or is it safe to use e.g. memcpy()?

Are atomic operations safe? sem_timedwait?

Upvotes: 1

Views: 2090

Answers (2)

nerowim
nerowim

Reputation: 91

In this answer I will try to collect whatever I can find about the limitations of shared memory IPC with a hostile process and countermeasures.

Please correct me if you find a mistake or something better!

Use read-only-mapping for unidirectional communication

http://selinuxsymposium.org/2007/papers/11-SecureIPC.pdf

In section 3.3 this paper states that shared memory can be created by process A with Read/Write access and process B can be restricted to read access only.

If the root process wants to send data to the child process that contains fragile data structures that must not be manipulated by the child, it could use a read-only mapping.

But I am not sure if the above only applies to SELinux, how to actually do it or if it can be done with mmap only.

Something similar is stated here:

Shared Memory when it's for read only

Synchronization issues

Linux shared memory only allow read access

"There are all sorts of odd synchronisation issues involved with shared memory".

Unfortunately no more details.

pkeys - Memory protection keys

https://lwn.net/Articles/466304/

Intel Skylake only

2011 LWN article comparing various IPC mechanisms

https://lwn.net/Articles/466304/

LWN article about Chromium communicating with seccomp sandbox

https://lwn.net/Articles/347547/

Chromium sandboxing FAQ

https://chromium.googlesource.com/chromium/src/+/master/docs/design/sandbox_faq.md#But-can_t-malware-just-infect-the-process-at-the-other-end-of-the-pipe-or-shared-memory

"But can't malware just infect the process at the other end of the pipe or shared memory? Yes, it might, if there‘s a bug there. The key point is that it’s easier to write and analyze a correct IPC mechanism than, say, a web browser engine. Strive to make the IPC code as simple as possible, and have it reviewed by others."

So Chromium is doing some kind of shared memory IPC!

Upvotes: 1

mevets
mevets

Reputation: 10445

If you only use the memory for simple operations, like memcpy, the child cannot directly harm you, but if you really don't trust them what is the point in sharing?

Putting a semaphore in the memory is a bad idea; again, you can't trust them, which means, well, you can't trust them. Semaphores, mutexes, condvars, ... only work in a high degree of trust. Message passing is better, but doesn't need shared memory.

The worst I can imagine is a minor denial of service attack. During I/O, pages are typically unavailable for access. If your child forked many copies of itself, and managed to continuously directio the shared pages, it could substantively disrupt the parent's execution progress.

There are people with more devious imaginations than mine.

Upvotes: 2

Related Questions