linux-kernel - Inconsistent execve SIGTRAP-ing after ptraced child's PTRACE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 8 Aug 2007 00:43:41 +0200 (CEST)
From:	"Eelis van der Weegen" <lkml@...tacts.eelis.net>
To:	linux-kernel@...r.kernel.org
Subject: Inconsistent execve SIGTRAP-ing after ptraced child's 
     PTRACE_TRACEME.

How can a parent process intercepting a ptraced child's system calls using
PTRACE_SYSCALL know which SIGTRAP's are system call entries and which are system
call exits?

Since there does not seem to be a way for the parent to get this information
from the system, ptrace examples floating around on the web generally use a
boolean in_syscall flag that they toggle at each SIGTRAP. This mechanism seems
perfectly adequate, but for it to work correctly the flag must obviously be
appropriately initialized, and that is where things get vague.

Let's assume that the child's ptrace-ing begins after it first does
PTRACE_TRACEME and then calls execve. According to the ptrace man page, after
doing PTRACE_TRACEME "all subsequent calls to exec() by this process will cause
a SIGTRAP to be sent to it, giving the parent a chance to gain control before
the new program begins execution". The problem is that this does not specify
whether the parent will see SIGTRAP's for both entry to and exit from execve, or
only for exit from it. To my great surprise, I observed both behaviors on actual
machines (in particular, I observed the former on an x86_64 dual core machine).

This inconsistency foils the in_syscall flag approach, as there is no way to
know whether the parent should initialize that flag to true or false (since
apparently both can occur). Hence, my question is: is this behavior intentional?
Should there not be a guarantee that /either/ only the execve exit, /or/ both
entry and exit, are SIGTRAPed?

I have attached a testcase program. On some machines (2.6.18.8-0.5-default #1
SMP x86_64, and a 2.6.18.8-0.3-default #1 SMP i686) it shows only one initial
execve occurence, while on another (2.6.18-8.1.8.el5 #1 SMP x86_64, dual core)
it shows two.

Regards,

Eelis

View attachment "ptracetest.c" of type "text/x-csrc" (843 bytes)