Problem with ptrace() in 10.20

[Knut Eckstein]

Dear all,

during the last weeks I've been working on a port of The Coroners Toolkit (TCT) to HP-UX 10.20. Details about the port can be found in a message that I posted to the security forum last week.

During the port the following problem turned up:

The pcat program in TCT uses ptrace(READDATA) to copy the TEXT,
DATA and STACK segment of a process for later analysis by the
investigator. It returns with EIO when trying to read the STACK area
of the init process (PID==1). I observed the same behaviour with
processes running "/bin/sh" and "/usr/dt/bin/dtrc". The inital
ptrace(ATTACH) works fine as do the read operations on the TEXT and
DATA segments. I know that OpenBSD and Linux flat out refuse a
ptrace(ATTACH) to the init process for security reasons, but this
seems to be a slightly different issue here. I also looked at the
pst_vm_status.pst_flags and the pst_vm_status.pst_permission bits
returned for each segment by pstat_getprocvm, but I can't see any
differences between these "troublemaking" processes and others.
Any help on this issue is greatly appreciated.

[Knut Eckstein]

Problem solved. I was actually trying to read the wrong memory region, because the STACK memory region grows "upward" from the address given by pstat_getprocvm. I asssumed it grew "downward" as many stacks do so on many architectures, but in HP-UX it is not the case.

Best regards,

Knut Eckstein