[lug] Steganography (was: newbie question - rc.sysinit)

[rm at mamma.varadinet.de]

On Sat, Jul 14, 2001 at 12:09:14AM -0600, Chris Riddoch wrote:
> > 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.
> 
> Not necessarily. If you manage to track down what the kernel is doing
> when it loads the module, through each and every step, then the hacker
> grabs the signature (which has been revealed by examining the running
> kernel) and simply signs her module with the same key you took such
> pains to protect.  Puts it in the appropriate place, changes some
> files, and now the module looks just as secure as all the rest because
> it was signed with the very same signature.  No reboots necessary.

That reminds me of a crack of some commercial cryptography program:
They had a very clever cryptographic function that would return 0 on
success and -1 on failure. To crack the program just meant that one
would need to change the one (!) assembler instruction after the call
to the key checking function (jump on zero -> jump on non-zero). If
you have access to the kernels address space you only need top patch
the functions that _call_ the signature checking functions.

> > 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.

There actually are good reasons for having this feature (at least for
high availability servers).

[...]

> 
> > 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).
> 
> Don't be so sure that physical access is necessary. Most bioses are
> software-updatable, these days. Mine is, I bet yours is, too. No
> hardware twidling. A quick google search found this:
> 
> http://www.firmware.com/support/bios/flashchp.htm
>    "Flash chips are a relatively new type of non-volatile memory chip
>    that can be erased and reprogrammed without being removed from the
>    system they are used in....This allows motherboard manufacturers to
>    make BIOS updates available electronically (such as through FTP
>    sites...)  instead of requiring chips to be removed and replaced."

Yup. A really nasty cracker could actually replace the bios ith Linux!
(given that the hardware is supported by the Linux Bios Project ;-)


[...]

> 
> And here's my proposal: have a look at the "capabilities" attribute in
> the kernel.  It's rather Un-Unix-like, 

really? I thought BSD supports  capabilities since quite a while (same
with AIX if memory serves me right).

> but it does away with the idea
> of "Root can do everything, some programs can be granted root
> abilities while still letting users run them safely".  The Unix Way
> is, in principle, not so bad, but the whole idea could be changed...
> 
> User A is allowed to tweak with modules.  No other users are.  User B
> is allowed to listen on sockets on ports below 1024.  Your network
> daemons run as user B.  Cracker gets in on a buffer overflow, ends up
> as user B, and can't tweak with modules because user B can't do that.
> Only user A can do that.  All the hacker can do is, well, listen on
> sockets.  (And whatever is allowed by all users)
> 
> The idea is, you assign more specific labels to the privileges of the
> users on the system in order to minimize the scope of access provided
> by a breach, and to grant some access to normal users without letting
> them take over the server.  At least, that's my understanding of it.
> Someone correct me if I'm misrepresenting it.  I haven't actually
> taken the Operating Systems class yet.
> 

 Ralf