Very Computer

        >      If fsck(8) fails during system boot, a privileged shell is run
        >      on the system console. This behavior can represent a security
        >      vulnerability if users, who would normally not have root access,
        >      have physical access to the console at boot time.  An attacker
        >      can force the failure to occur.

Eh, I don't understand the relevance of this.  When will CERT
issue an advisory about the vulnerability of people walking up to
the machine and carrying its disks away :-) Isn't this "root
shell on the console after fsck" vulnerability rather bogus.  If
you have physical access to the machine, there is not much
security anyway.
--
Tor Lillqvist,
working, but not speaking, for the Technical Research Centre of Finland,
Laboratory for Information Processing (VTT/TIK).

On Suns it is possible to make rootshells hard to get, at least as
long as people do not tamper with the hardware.
(You set a PROM password, so you can't do anything from the outside
of SunOS. You set a non-secure flag on console, and single user boots
will not complete unless the root password is typed.)

This advisory gives you a way to fix the one remaining problem with
SOlaris 2.x boots.  However, if you PROMS are in secure mode, it is almost
impossible to force fsck to exit like this.

Casper

Quote:> This advisory gives you a way to fix the one remaining problem with
> SOlaris 2.x boots.  However, if you PROMS are in secure mode, it is almost
> impossible to force fsck to exit like this.

But on many older Suns it appears possible to bypass the PROM password by
either overflowing the forth stack or by frogging things sufficiently for it
to prompt 'boot:'. (Why should there ever be such prompts in secure mode!?)

[ On the opposite side of this argument: I know it remains true that however
your system, if people have physical access they can always break in by ones
means or another. But it still pays to make it as hard as possible. ]

I haven't experimented with Sparc 10's or any of the other newer Sun machines,
with the PROM in mind, yet.

        James

Quote:>But on many older Suns it appears possible to bypass the PROM password by
>either overflowing the forth stack or by frogging things sufficiently for it
>to prompt 'boot:'. (Why should there ever be such prompts in secure mode!?)

But on many older, older Suns (or perhaps that should be three olders) it
is possible to look at the PROM password without being prompted for it.
That was always one of my favorites. :-)

--
                                             Jeff Stehman

Sun's don't just have this vunderability --- HP-UX (9.01) is also fond
of starting root shells when fsck fails!

Cheers
Russell
----------------------------------------------------------

Quote:>This advisory gives you a way to fix the one remaining problem with
>SOlaris 2.x boots.  However, if you PROMS are in secure mode, it is almost
>impossible to force fsck to exit like this.

If I turn the power on and off enough times, I bet I can corrupt the file
system to the point that a manual fsck is necessary. Under Solaris having
the prom password set and non-secure consoles does nothing, since the stupid
rc script just execs a sh on /dev/console for me.

James

It is true that setting turing off the power enough times will
probably result in a corrupted filesystem that will need a manual fsck.

You seem to forget that if you put the EEPROM in full secure mode,
the machine won't boot after a power failure or system crash or
whatever.  It will just sit there asking for the password.
So, as soon as the kernel stops running, you'll need the password
to get it going again.

Casper

Yes, but with the latest release of those proms, there is a key sequence you
can hit while booting which resets them to factory defaults. This is kinda
stupid, but it does work. Basically, if I can get console access to a current
solaris 2.2 machine, then getting a root shell on the console isn't too hard.

James

The L1-N sequence or other should clear everything, except the
password.  If it does clear the password, it's broken.
(In that case, you can also get root-access to any SunOS machine)

Casper

It won't boot with any special instructions, but it will boot with whatever
the default boot string is.  Ours boot back to multi-user, which is certainly
plenty to let you nuke the fils system by turning on/off.

Quote:>Yes, but with the latest release of those proms, there is a key sequence you
>can hit while booting which resets them to factory defaults. This is kinda
>stupid, but it does work. Basically, if I can get console access to a current
>solaris 2.2 machine, then getting a root shell on the console isn't too hard.

Yes, but if security-mode=full is set (4.1.3 anyway) then that key sequence
will NOT work (I've tried it).  

--
Marc Fraioli          |  "We will create new Hiroshimas and Nagasakis.  I

                      |   get your own Chernobyl in Germany."
                      |                         -Vladimir Zhirinovsky

Basically, if I can get to the cabinet of a Sun machine (and you haven't
done something odd with the case screws) I can get to the root prompt too.

All it takes is a $200 3.5" hard disk in my pocket.  Pop it open, change the
drive select jumpers on the primary disk and plug mine in.  Turn on power,
mount the now-wide-open disk drive, and change the root password.

Elapsed time: 5 minutes.

If the problem is severe enough that this is at issue then you need to do
something which protects against physical wire snooping (ie: encrypted
ethernet cards) and lock down the hardware so I can't get into it.  
And/or run diskless.

Otherwise, if I want into the machine, you're hosed.

Consider what you're trying to accomplish, and how.  Then look at how
someone would get around it.  If you need more security than the EEPROM
password gives you then you're into the realm of secure hardware and/or
LAN links.

--

Modem: [+1 312 248-0900]        | Clarinet feed in Chicago.  Send email to

Better get an extra NVRAM too, you'll need it to subvert
the security-mode=full setting.

With eeprom security-mode=full you get:

        - an unerasable (w/o opening the machine or getting root access)
          EEPROM password.
        - a machine that won't boot once interrupted, halted or powercycled.
          (once you're in the PROM monitor, you'll need to type a password.
           after a powercycle, it will first ask the password, then boot)

Of course, there are ways to subvert this.  Opening the machine,
taking out the PROM and reading the password (it is stored in cleartext).

But opening the machine can be made difficult (cable through the
*on the back on lunchbox systems).

Or is there someone who knows (and has tried in the minutes before posting
a reply, otherwise don't bother) a way to get root with a system
with security-mode=full by attacking the hardware/software in a way that
does not involve the NVRAM.

(I agree that a solution where root access on the machine doesn't matter
to the rest of the net is preferable.  This security-mode=full stuff does
seem useful in other environments, especially in easily accesible
not closely supervised labs)

Casper

Quote:>Better get an extra NVRAM too, you'll need it to subvert
>the security-mode=full setting.

Or just bring a new system and hang the 'secure' disk off it.

Quote:>But opening the machine can be made difficult (cable through the
>screw on the back on lunchbox systems).

Nothing that a few tools can't deal with in minutes.

Quote:>Or is there someone who knows (and has tried in the minutes before posting
>a reply, otherwise don't bother) a way to get root with a system
>with security-mode=full by attacking the hardware/software in a way that
>does not involve the NVRAM.

See above 8)

Quote:>(I agree that a solution where root access on the machine doesn't matter
>to the rest of the net is preferable.  This security-mode=full stuff does
>seem useful in other environments, especially in easily accesible
>not closely supervised labs)

That's the rub - it's very difficult to guarantee the security of a system
when it's vulnerable to physical attack.  Better (where possible) to
spend a little time doing the physical security with hardware that's
designed for it (doors, windows, controlled-access systems) than trying
to take a plastic box & do the same with it.

If you're using individual workstations in the lab environment, then yes,
you have a major security disaster looming 8)  Probably better to put
a server in the next room (locked) and use some cheap Xterms 8)

Quote:>Casper

(ObInsecurity: Getting into a Multimax a friend of mine bought with no
               passwords; walk around the back, unplug some disk, boot,
               play... Very educational. (*sniff* lovely machine that,
--

# "The question 'why are the fundamental laws of nature mathematical'  #
# then invites the trivial response 'because we define as fundamental  #
# those laws which are mathematical'". Paul Davies, _The_Mind_of_God_. #

|>
|> That's the rub - it's very difficult to guarantee the security of a system
|> when it's vulnerable to physical attack.

I suspect difficult is an understatement.

If I can prepare ahead of time (for instance my own eeprom to
replace the one in the system), I can pretty much get into *any*
computer system if I have *physical* access.

I may have a hard time covering up the fact a breach occurred,
but that does not prvent the breach.

|> Better (where possible) to
|> spend a little time doing the physical security with hardware that's
|> designed for it (doors, windows, controlled-access systems) than trying
|> to take a plastic box & do the same with it.

Physical access control is the only way to go for real security.

|> If you're using individual workstations in the lab environment, then yes,
|> you have a major security disaster looming 8)  Probably better to put
|> a server in the next room (locked) and use some cheap Xterms 8)

Well, making the server refuse to honor root logins on the non-secure
workstations is probably sufficient. (That is use the 'no-root' NFS
export to provide the file systems to the workstations, and require
the password with all root logins, even from trusted hosts).

That is, configure the system so that a root login on a non-secure
workstation is only useful on that one machine.

--

The peace of God be with you.