[lug] newbie question - rc.sysinit

[D. Stimits]

Chris Riddoch wrote:
> 
> "D. Stimits" <stimits at idcomm.com> writes:
> 
> > Chris Riddoch wrote:
> > >
> > > <snip>
> > >
> > > Having followed this, and a couple other threads for a while, the idea
> > > of having signatures on kernel modules sounds almost feasable, except
> > > for a couple problems...
> > >
> > > Someone with root access can look at any area of memory or the hard
> > > drive.  The private key has to be kept somewhere... and the
> > > passphrase, too, if you expect modules to be able to autoload without
> > > the administrator sitting in front of the keyboard.
> >
> > Part of this is the art of steganography...hiding data within data. A
> > naive implementation might put the means to sign or verify signature in
> > an easily altered location.
> 
> Right, right. But the problem is, you've got to have the code that
> will perform the steganography somewhere in the kernel. That could be
> analyzed to see what exactly the kernel does in order to get the
> signature.

Getting the signature gathering code, if it could be altered in place in
memory, would defeat it unfortunately. The main concern I'd have is
getting the private signature. If you manage some means to defeat actual
overwrite of the kernel on the drive and the boot sector, then any crack
would be successful only until the next reboot. Interesting to me is
that there has been recent kernel devel list talk about what would be
required to install new kernels without rebooting...nobody really wants
to go through the pain of making that possible, so I doubt it would ever
happen, but it would make for interesting security problems.

> 
> > It should also be possible to force required memory locations to be
> > read only, enforced by cpu hardware.
> 
> Well, my knowledge of hardware-supported limits on memory access is
> limited to a class on assembly language and a couple weeks where we
> discussed attributes on memory pages.  But the problem remains, if
> root can make it read-only, root can also make it read-write.

True, but like most security, it is one in a series of difficulties to
overcome, and no one measure is ever enough to be guaranteed. Having to
first find, and then alter, code that is buried in memory, is a
significant barrier to script kiddies (and with steganography, the
location of burial would be different from one kernel to the next,
possibly even from one reboot to the next).

> 
> > > Seems that the best way to really be secure about this would be to
> > > build a kernel *without* module support.  Is anybody quite sure that
> > > this would completely remove the ability to add modules?
> >
> > You can, but some features are only available in modules.
> 
> Well, the more security you have, the more you encroach on usability.
> The kind of security we're talking about here would rather severely
> damage the sort of usability you'd expect on a desktop.

It is worse than that if you consider that without modules, even the
services that exist as compiled in, would make the kernel so huge that
you then get boot difficulties from shear size.

> 
> > Then you still have the problem of the kernel image itself being
> > replaced, and re-running lilo.
> 
> True, there's more ways to do it.
> 
> > This is one place where bios virus options can be used
> > to stop remote writes of boot sectors, but not of the image itself (it
> > is possible to force a replacement kernel to be put at the original
> > inode location, avoiding the problems of boot sector protection).
> 
> Hopefully your bios isn't stored in flash memory.  Otherwise someone
> could change your bios to disable the virus protection, and probably
> disable any password protection.  The bios is flashable, most of the
> time.

To flash the bios, you have to sit at the console. You can't do it with
root privilege from a remote login. Very very few of all cracked
machines (that I've heard about) in the news (or just in security group
postings) involve someone physically entering the room and flashing your
bios (which is no longer a software issue).

> 
> > But a real win is not to cripple your machine, but to have it fully
> > available while still being problematic for script kiddies to crack.
> 
> Well, I think there are a few options, depending on what level of
> security you want.
> 
> 1) Take firewalling, traffic analysis, security updates, and kernel
> updates seriously.

This by itself will stop most every script kiddie in the world. Probably
even discourage quite a few moderately capable crackers.

> 
> 2) All of #1, and do code reviews yourself.

Good if you have the time and expertise.

> 
> 3) Unplug yourself from the network.

Not practical for many situations. It is another case of security
through crippling capabilities (in some strange way, it is a denial of
service).

> 
> If it were me, and I had the time, I'd do #2. As it is, I just do #1
> and trust the Debian folk to do updates in a timely manner.
> 
> > There are not very many real experts that go around doing these things,
> > often it is someone with little knowledge and a script, or just moderate
> > knowledge capable of altering things on existing scripts. Once you use
> > steganography, the attacker will be seriously challenged.
> 
> I don't think that's your silver bullet here.  There's only so much
> you can do to hide it, because something executable has to be able to
> get at it.  It has to get unraveled and unencrypted and extracted
> *somehow*, after all, and the mechanism for doing so can be watched
> while it's happening.

Hmm. That makes me wonder. If a stealth module can hide itself, why not
make an intentional stealth module that does the pgp signature stuff?
Make the kernel lie about its presence, turn the stealth module against
the crackers ("fight fire with fire").

> 
> > > Even then, I suppose, the infinitely-capable adversary could
> > > binary-patch the kernel's area of memory while it's running. Heh.
> 
> > Yup. You could take steps to avoid that vulnerability though. Hiding the
> > data is one means, though there are others.
> 
> The best way to hide it would be to send a request to a machine whose
> only purpose is to check if the kernel is allowed to load the
> module. It could even *copy* the module to the other computer so it
> could check the actual module, which would then send a message back
> granting or denying the ability.  The whole exchange would have to be
> done in some way to guarantee that each computer is, and is doing,
> what it claims.

That seems overly complicated to implement without a lot of holes. But
it does make me wonder about something else. It would be interesting if
an independent system could be made to run as a sort of watchdog,
simultaneously, on the same machine, based on a CD rom system that can't
be overwritten. A ghost in the machine to watch over it.

> 
> The basic rule is, you can't trust a computer if it's been rooted.

One of the goals of better module security is to stop the root in the
first place. And if you can't stop it, then make it much harder to hide
the root kit. Right now there are a *lot* of machines out there which
are rooted and the owners don't even know it.

> 
> The other thing is, none of this is necessary for handling your
> average script kiddie.  It's the determined person whose only target
> is your computer that you need to be worried about.

I see so many attempts on my machine that I have to disagree. You have
to worry about both. The greatest effort would be to stop a determined
attacker, but if you have an insecure machine, chances are you'll be
rooted in a day on many domains (take cable modem domains for an example
there). It isn't unusual that within 10 seconds after bringing my modem
up I see buffer overflow attempts on port 515 (printer vulnerability),
or some form of test against 53 or 111. And the scripts these days can
be quite thorough against known vulnerabilities.

D. Stimits, stimits at idcomm.com

> 
> --
> Chris Riddoch         |  epistemological
> socket at peakpeak.com   |  humility
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug