I have a service with LOCAL SYSTEM privileges, and I want it to be able to communicate with my client application, which is run under unprivileged users (I'm on Windows). I am using boost::interprocess for "shared memory", which really just creates memory-mapped files under the hood. Right now I simply create a memory-mapped file with GENERIC_READ and GENERIC_WRITE given to everyone, so that the client can communicate with the service. However, I'm wondering what the current security risks of that are, and how to make this secure?
For one, someone could overwrite the data in the memory mapped file, interrupting communication between the client and the service. But I'm wondering if something more drastic is possible, like someone redirecting the service to other memory addresses to execute malicious code by editing the memory-mapped file. I don't store pointers within the memory-mapped file itself, I only use the boost::interprocess offset_ptr and plain data.
Yes people tampering with your shared memory can compromise most applications.
No, using
offset_ptrdoes not innoculate against that.As a trivial counter example, imagine a linked list or graph using
offset_ptr. If a malicious actor made a cycle in that list, it could lead to DoS by infinite loop if your application doesn't protect against that.offset_ptronly allows pointer values to be interpreted as the equivalent addresses in separate process spaces, but it provides no validation of the actual value. A simple counter-example here is when you make the pointer point outside the valid range for the shared memory region. It doesn't matter that you store it usingoffset_ptr, the pointer value will still be invalid.Access Control
What you seem to be after is access control. This is hard to achieve portably, and as such only limited control is present in Boost Interprocess, in the form of
boost::interprocess::permissions:The default permissions are a null
SECURITY_ATTRIBUTESon windows or644filemode on POSIX (u=rw,go=r).To restrict read and write access to the owner (effectively the user creating the shared memory object) on linux, use e.g.
0600.Demo
Coliru
When run with e.g.
sotest 1 2 3prints e.g.And the shared memory mode is
-rw-------: