mailing list archives
Re: OpenBSD Exploit
From: Artur Grabowski <art () STACKEN KTH SE>
Date: Mon, 6 Nov 2000 16:29:19 +0100
rloxley <rloxley () HACKPHREAK ORG> writes:
Usually Team HackPhreak keeps our code and research quite private
until we give lectures in our channel on undernet (#hackphreak). But what
really annoys us, is when a very big figure in the security community acts
disrespectful to the people who help build this internet infastructure. This
person who I speak of, is Theo de Raadt. Theo de Raadt claims that OpenBSD
hasn't experienced a local root hole in the default install for many years.
Next time, do your homework before making a complete fool out of yourself.
We have stopped claiming that since the two localhost holes we've found
in the last few months.
During his internal security audits, they find many bugs, yet they just
hide them, patch them, and never notify the public. This is very unethical
on the part of the OpenBSD team. I think you guys are lame. What worrys
Team Hackphreak, is how many other bugs have gone unnoticed.
We've said this many times and we'll repeat this: We don't try to find
exploits, we just fix bugs. Found something exploitable? Fine, publish it
and we'll stop claiming things. Didn't find anything exploitable? Shut up
and do something constructive.
We have found
many other exlpoitable holes in previous OpenBSD distributions, that have
miraculously been patched and never revealed.
Can you back your claim? Or is this just random rambling that you hope will
improve the credibility of your rant?
Next, there is the "Three
years without a remote hole in the default install". I hope this advisory
breaks that aswell, because, technically:
* Log into the remote host
* Grab our exploit
* Crash the kernel
Eeeeh? Wow. This is so clueless. Technically I can go and break the fingers
of a sysadmin of any operating system and get the root password. This doesn't
make it a localhost of remote attack.
There exists a bug in the UVM code which has blatently slipped passed
the seemlessly small minded OpenBSD security auditors. The bug exists in the
anonymous mapping code in UVM. This bug allows for any local user (or remote
user) to crash the entire OpenBSD system, rendering it completely useless.
Once the system has crashed, a local user (with access to the terminal) may
in fact hack the system. The system drops into DDB (man it). DDB allows for
debugging of the actual kernel. When one has access to the kernel, they can
do most anything: such as reading disk buffers, reading _copyright, reading
network mbuf's. So this scales to a most incredible attack, not just a DoS
(if you have read through this you have now more reason to switch to Linux).
? Tell me you are kidding.
Why bother with all this?
When you have access to the machine:
- boot it from a floppy.
- reboot the machine (power switch, reset button, whatever) and:
- boot it single user by typing "boot -s" in the boot prompt.
- boot your own kernel (if the sysadmin is clueless enough to let you have
writeable access to the root (/tmp or /var/tmp)).
- boot it into DDB by typing "boot -d" in the boot prompt. With ddb you can:
- binary patch your kernel (say, change the suser function).
- enable console debugger "w db_console 1"
- When you have the console debugger enabled, you can break into ddb
- steal the hard disk.
A very smart attacker will:
* Crash the kernel
* Assume the location of the box which crashed (@ the colo)
* Use DDB to gain god status
No, this would be a very stupid attacker. What can you do with a dead kernel?
How much time will someone allow you to search through the mbufs and disk
buffers? Waste of time.
Let's say you have enabled the console debugger and allowed the machine to
finish booting (after crashing or resetting).
1. start a shell.
2. get the pid of the shell.
$ echo $$
3. break into ddb.
Stopped at _Debugger+0x4: jmpl [%o7 + 0x8], %g0
4. find the struct proc * for the shell.
PID COMMAND STRUCT PROC * UAREA * VMSPACE/VM_MAP
7911 ksh 0xf8577600 0xfa0bb000 0xfa00fc30
5. find the p_cred pointer in struct proc.
ddb> exa 0xf8577610
6. find cr_uid in ucred.
ddb> exa 0xf83d4d64
7. change the uid.
ddb> w 0xf83d4d64 0
0xf83d4d64 0x47ac = 0
8. get out of ddb
Section 6 [Come 1 Come ALL]:
Team Hackphreak invites you to undernet #hackphreak for a great
learning experience. Just join us to teach and learn. But remember,
HARASSMENT = BAN. www.hackphreak.org/newbie.
If you would spend some time on education instead of irc, maybe you could
find some decent exploit some day.