Why isn't access to /proc/pid/mem a security vulnerability?

Question

I've played around a bit with /proc/pid/mem and /proc/pid/maps. I wrote a simple c program that just periodically reads from a variable (whose address is written to stdout), and I was able to change its value with dd.

#include <stdio.h>
#include <unistd.h>

int main() {
    pid_t pid = getpid();
    int value = 5;

    do {
        printf("value: %d\naddress: %p\npid: %d\n", value, &value, pid);
    } while (getchar() != -1);

    return 0;
}

echo '0x2a000000' | xxd -p -r | dd of=/proc/$PID/mem bs=1 seek=$((ADDR)) count=4 conv=notrunc

When I hit enter in the first program, the value gets updated to 42.

So my question is, why isn't this a problem? I didn't even have root access. If I had installed malware onto my computer it could read/write to any programs' memory.

Even if you don't know the exact address of the variable you can still print out the entire stack and heap using the addresses of /proc/pid/maps.

Answer 1

It possibly is a security vulnerability. That's why there's for example the Linux security module Yama, that restricts ptrace and thereby access to /proc/<pid>/mem.

As Linux grows in popularity, it will become a larger target for malware. One particularly troubling weakness of the Linux process interfaces is that a single user is able to examine the memory and running state of any of their processes. For example, if one application (e.g. Pidgin) was compromised, it would be possible for an attacker to attach to other running processes (e.g. Firefox, SSH sessions, GPG agent, etc) to extract additional credentials and continue to expand the scope of their attack without resorting to user-assisted phishing.

This is not a theoretical problem. SSH session hijacking (http://www.storm.net.nz/projects/7) and arbitrary code injection (http://c-skills.blogspot.com/2007/05/injectso.html) attacks already exist and remain possible if ptrace is allowed to operate as before. Since ptrace is not commonly used by non-developers and non-admins, system builders should be allowed the option to disable this debugging system.

source: Kernel documentation on Yama

---

I can't reproduce your experiment on Linux kernel 5.4.0, i.e. I get a Permission denied error:

$ echo '<addr>' | xxd -p -r | dd of=/proc/<pid>/mem bs=1 seek=$((ADDR)) count=4 conv=notrunc  
dd: failed to open '/proc/<pid>/mem': Permission denied

The behavior depends on your system's configuration. For example if the Linux security module Yama is active and ptrace_scope is set to mode 1, by default, a process can only read it's own or its childrens' mem-files.

1 - restricted ptrace: a process must have a predefined relationship
    with the inferior it wants to call PTRACE_ATTACH on. By default,
    this relationship is that of only its descendants when the above
    classic criteria is also met. To change the relationship, an
    inferior can call prctl(PR_SET_PTRACER, debugger, ...) to declare
    an allowed debugger PID to call PTRACE_ATTACH on the inferior.
    Using PTRACE_TRACEME is unchanged.

(ibid)

   /proc/pid/mem
         This file can be used to access the pages of a process's
         memory through open(2), read(2), and lseek(2).

         Permission to access this file is governed by a ptrace
         access mode PTRACE_MODE_ATTACH_FSCREDS check; see
         ptrace(2).

man 5 proc

   PTRACE_MODE_ATTACH_FSCREDS
         Defined as PTRACE_MODE_ATTACH | PTRACE_MODE_FSCREDS.

man 2 ptrace

More details on the access checks can be found in this CloudFlare blog post on "Diving into /proc/[pid]/mem".