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/
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:03:27 PDT