[svlug] Security question: read-only drive

[Dagmar d'Surreal]

On Wed, 7 Feb 2001, Drew Bertola wrote:

> Aaron Lehmann writes:
> > On Tue, Feb 06, 2001 at 08:19:28AM +0000, Drew Bertola wrote:
> > > Not if the C code to control the switch is binary only (locally) and
> > > protected by hardcoded password (argv[1]) with an algorithm like MD5
> > > to keep it safe within the binary.  (Not to mention the obscurity
> > > involved).
> > 
> > Bullshit. When you're root, you don't need those binaries to work for
> > you to get hardware-level access.
> > 
> > Even if you didn't know how the hardware stuff worked and the security
> > through obscurity of the hardware interfaces was enough (which is not a
> > good bet), you're root. That binary-only crap will not stop you. Simply
> > disassemble the binary and change the MD5 comparison into a noop. It's
> > not that hard. Security by obscririty gets you nowhere.
> 
> First you have to get root.  That's the whole point.  Ok, maybe as an
> exercise there are whole's in this remote control thing.  But
> obscurity works in my favor here.
> 
> Remember, there's this real obscure way to control the read-only
> switch which, lets say is listed as "/root/.ac_history".  I don't know
> why you'd bother to try executing it on a system to which you
> illigitametly gained root access.  Not to mention I've only executed
> it via ssh and you need to know the password to get it to do anything.
> 
> Heck, I could even hack 'ls' so as not to list it.  Not that I'd ever
> go that far.  But what are you gonna do, install a pristine 'ls'?
> That's not something a bad guy normally plans on.
> 
> So, back to your first bit, you've broken in and gotten root.  Aside
> from the fact that it's not part of your m.o., you decide it would be
> fun to start writing random bytes to i/o space?  I bet you lock the
> machine before finding the right byte and bit pattern to unlock the
> drive.
> 
> Don't underestimate the power of obscurity.  If your root password
> wasn't obscure it wouldn't be much good.

I'm going to attempt to let this serve as my last comment on the matter.

What scenario you just described is a *fatally* flawed approach.

The intruder has gained root access, and your system is utterly unaware of
it, not only that, you seem to be unconcerned that the intruder has gained
unauthorized control of the system because you're counting on them not
being able to change the non-writeable filesystem to protect you.  Making
the filesystem non-writeable doesn't do you much good if an intruder gains
control of the system and you a) don't notice or b) don't do anything
about it.  Clearly they can still instruct the system to do whatever they
want.  The one and only thing that it *can* do for you is prevent your
detection mechanisms from being tampered with.

...or to put it another way...  If I gain control of a system that
happens to have most of it's filesystem non-writeable, it's only going to
inhibit my ability to do whatever I want with that machine by a very small
degree, and there are people out there who are a lot better at mutilating
carefully prepared security models than I am.