5

Although I'm not any kind of kernel specialist and I do not program in languages like C/C++ and thus I do not have deep understanding of critical concepts of managing processes at OS level I do have feeling that processes / daemons / socket listeners I write in languages like PHP and JavaScript (Node), despite being fairly simple, cold be used by malicious program, not necessarily root privileged.

So, I wish to know is it possible for unprivileged user to modify/inject into other user's (root) process, and if so, what would be vector / entry point for this?

(obvious stupidity like setuid-ing the binary that executes argv[1] or STDIN line are not in scope of this question.)


I'm asking this question because I want to extend my knowledge regarding subject - damage done by, let's say some web shell that got into apache/www-data writable dir and managed to inject into root-owned process would be, by definition, fatal for security.

2 Answers2

6

This is far from being a simple task thanks to memory protection techniques.

In the old times of MS-DOS, Windows 9x and equivalent home computing systems, the memory was indeed equally shared amongst all the running process. In such conditions your feeling is right: any user process can access and modify memory from other processes, even the operating system kernel has no mean to fully shield itself.

But this is old story now. As an inheritance from mainframe computers (big bulky fridge-looking units used for highly sensitive and parallel tasks), home computers OS and processor architectures received real memory protection techniques.

At the basis of this technique there is a map allowing to match a memory segment with its owning process. Thanks to this, a process is not allowed anymore to access anything outside of its own memory. If a process attempts to break this rule (most often as the result of a bug) the operating system mercilessly kills it (this is dreaded segmentation fault, or "segfault" for the intimates).

Does this means that the threat you are describing can never happen anymore? In security, never say "never": every system as secure as it may seem has its flaw:

  • The whole thing is controlled by the operating system kernel, so a flaw in the kernel may lead to bypass this security and obtain access to whole memory like in the good old days. An example on Linux could be the ptrace system call, designed to allow to trace (debug) a process. Vulnerabilities are found from time to time allowing an unprivileged process to abuse this function into getting such ability.
  • On the other side of the chain, you may also want to bypass the operating system completely and directly attack the physical RAM storage. The most well known attack in this category is the Row Hammer: it has been found that on a lot of RAM modules the fact of quickly and repeatedly changing the value stored at a location may, due to some electronic weakness, affect and possibly change a value stored at a nearby location.

Where your nightmare may come true regarding your "fairly simple" scripting language is that there is for instance a working JavaScript implementation of the Row Hammer attack. So definitively yes, it is possible for an unprivileged JavaScript program to inject some code in a root process. However, this is not a simple thing, and as new ways to do this get discovered, new protection techniques gets developed: the endless story of IT security ;) !

WhiteWinterWolf
  • 19,082
  • 4
  • 58
  • 104
1

Yes, but it depends on the OS. One way of doing this is known as a Buffer Overflow attack. These attacks are results of vulnerabilities at the Kernel level, so they are relatively rare.

There is an entire video on the subject by Computerphile: https://m.youtube.com/watch?v=1S0aBV-Waeo

Kris Molinari
  • 251
  • 1
  • 6
  • Most buffer overflows are user application-level vulnerabilities, and by itself can't be used to elevate access to root from unprivileged processes. A buffer overflow vulnerability in a privileged process or in the kernel itself can sometimes be used as entry point for unprivileged process to do privilege escalation, but that is an issue in the privileged process. – Lie Ryan Mar 27 '17 at 02:46