[17948] in bugtraq
Ptrace & Non-readable
daemon@ATHENA.MIT.EDU (esimon@HUSHMAIL.COM)
Wed Dec 6 18:25:48 2000
Content-Type: multipart/mixed;
boundary="Hushpart_boundary_JzcsMhqSDSFnPBHYMagdMADuzDhDPSyA"
Mime-Version: 1.0
Message-Id: <200012061354.FAA04011@user3.hushmail.com>
Date: Wed, 6 Dec 2000 13:19:56 -0800
Reply-To: esimon@HUSHMAIL.COM
From: esimon@HUSHMAIL.COM
To: BUGTRAQ@SECURITYFOCUS.COM
--Hushpart_boundary_JzcsMhqSDSFnPBHYMagdMADuzDhDPSyA
Content-type: text/plain
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.
--Hushpart_boundary_JzcsMhqSDSFnPBHYMagdMADuzDhDPSyA--
IMPORTANT NOTICE: If you are not using HushMail, this message could have been read easily by the many people who have access to your open personal email messages.
Get your FREE, totally secure email address at http://www.hushmail.com.
