Bugtraq mailing list archives

Re: Regarding Mudge's OBP/FORTH root hack (PHRACK53)


From: jkb () MRC-LMB CAM AC UK (James Bonfield)
Date: Mon, 13 Jul 1998 09:22:11 +0100


Jericho Nunn wrote:

   Aside from the fact that it left me quite flabbergasted for quite
some time, mudge's OBP memory manipulation for aquiring root priviledges
poses a serious risk for environments where SUN workstation consoles are
easily accesible to unpriviledged individuals, such as university labs.

This has been known for a long time. Indeed some 7 years ago whilst I
was at univeristy, and in my more "cat and mouse" gaming moods, I used
this trick and a prom password was promptly added.

One serious point which isn't brought out in Phrack (apologies if it is
- I only skim read it) is how to detect such things. I found, using
SunOS 4.x at the time, that neither ps or who would show up the modified
user credentials.  It seems that SunOS4 had several copies in memory and
provided you modified the correct ones you could gain root privs without
being listed as such in the standard sysadmin tools. I do not know
whether this is still the case, but it's worth checking.

   An easy and quick work-around that avoids granting  just anybody at
the console the ability to "Stop-A" and drop into OBP, is to enable the
"security-mode" and "security-password" variables within OBP.  Changing
the default value of "security-mode" from 'none' to 'full', forces a
user who tries to halt the system to authenticate against the password
defined in "security-password" before having access to the OBP command
line.

As has been noted by others before, this helps, but isn't a foolproof
method.  Firstly, if physical access to the console is available then
it's possible to reset the PROM using hardware hacks (eg temporarily
disconnecting the battery). Lesser known is the trick one of my friends
spotted; that it's possible to corrupt the PROM stack and overwrite it's
memory including the password. His crude technique was, if I remember
correctly, a huge number of "L1-A" and "c" (this was in the old Sun
days) commands. After a while it just crumpled and refused to continue.
After that you could reboot it and there'd be no password. I think there
were also problems with L1-Aing during the power-up self tests and
bypassing the password that way. I would hope that all of these flaws
have been fixed now, but obviously only on modern hardware. Universities
often have lots of older hardware.

Other problems also exist, eg if kadb is still on the root partition and
there's no password on the PROM then you can also boot using kadb, in
which case L1-A leaps into kadb instead of the PROM direct. That amounts
to the same problem, although it's easier to control and it has commands
to directly display the various structures. (Or maybe, if things are
_really_ badly setup, just boot into single user mode.) Of course any
competant sysadmin ought to notice unexpected reboots (although it's a
bit late by then).

Finally, here's some old mail from a friend describing his experiments
with the old-style (non-"ok" prompt) PROM:

    Remember how at first we could "b kadb" (old prom), then they
    disallowed an argument but screwed up and we could still "b k" or
    any single-letter boot image? (with pw enabled) Well, with the new
    prom (pw enabled) you can't do that, but if you persist with
    things like "b <spaces until end-of-input bell>" "b <junk until
    bell, then delete 3>" and stuff, doing L1-a occasionally, or a
    plain "b" it eventually falls over.  It LOOKS like there's space
    for a local var to hold the input string, which gets overflowed by
    a gets-type call into other local vars.  We experimented with this
    for a while, and ended up with something like "b<254 spaces>" is
    ok, but "b<254 spaces>a" makes it break.  Suspicious?

It's certainly an unusual place to look for buffer overruns! :-)

James
--
James Bonfield (jkb () mrc-lmb cam ac uk)   Tel: 01223 402499   Fax: 01223 213556
Medical Research Council - Laboratory of Molecular Biology,
Hills Road, Cambridge, CB2 2QH, England.
Also see Staden Package WWW site at http://www.mrc-lmb.cam.ac.uk/pubseq/



Current thread: