Question

Why do I need to run as root (not r00t_)?

// main()
scan.scanProcessOffset(10838, 0x7f8c14000000); // proper pid and offset

void MemoryMapper::scanProcessOffset(unsigned int procId, unsigned long long offset)
{
    long attach = ptrace(PTRACE_ATTACH, procId, NULL, NULL);
    cout << attach << endl << errno << endl;

    long memory = ptrace(PTRACE_PEEKDATA, procId, offset);
    if (memory == -1 && errno == 3)
    {
        cout << errno << endl;
        errno = 0;
    }

    cout << memory;
}

As you can see the process I’m hooking into is owned by r00t_

r00t_@:/proc/10838$ ls -l 
lrwxrwxrwx 1 r00t r00t_ 0 2012-04-15 08:21 exe -> /usr/bin/gedit
-rw------- 1 r00t r00t_ 0 2012-04-15 09:04 mem

Output not running as root:

r00t_@:~/memedit$ ./a.out
-1
1
3
-1

Output as root:

r00t_@:~/memedit$ sudo ./a.out
0
0
140239607693344

why cant I attach when I am the owner of the process I’m trying to attach to?

Answer 1

While some applications use prctl() to specifically disallow PTRACE_ATTACH (e.g. ssh-agent), a more general solution implemented in Yama is to only allow ptrace directly from a parent to a child process (i.e. direct gdb and strace still work), or as the root user (i.e. gdb BIN PID, and strace -p PID still work as root).
In the event of a local app compromise, the attacker is then not able to attach to other processes and inspect their memory and running state.

This behaviour is controlled via the /proc/sys/kernel/yama/ptrace_scope sysctl value. The default is “1” to block non-child ptrace calls. A value of “0” restores the more permissive behaviour, which may be more appropriate for development systems and/or servers with only administrative accounts. Using sudo can also temporarily grant ptrace permissions via the CAP_SYS_PTRACE capability, though this method allows the ptrace of any process.