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

[D. Stimits]

rm at mamma.varadinet.de wrote:
> 
> 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 ;-)

I was under the impression (maybe falsely) that if the cmos was set to
require a password, and if it also was set with virus protection against
boot sector alterations, that it would not be modifiable without local
access. It sounds like even this is easily defeated? In theory the code
to protect, when virus and pass are set to be required, would also
require physically cutting the battery backup to the cmos if the pass is
ever forgotten. If other access is possible, then it seems the bios
password and virus portions are defective.

> 
> [...]
> 
> >
> > 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).

Some filesystems do support ACL's (access control lists) for extended
mandatory access, but that too is part of the kernel...if the kernel
does not want to honor it, it won't help. It seems that there is a need
to arm the kernel with an absolute shield section that out of single
user mode cannot be modified or viewed. Once you have that, the options
increase dramatically. If this couldn't be done, perhaps there would be
a way to transparently do strong encryption of that block of memory,
making observation useless. With encrypted memory, there could still be
problems with someone modifying it; it would be interesting if cpu's
came with hardware support of mandatory memory encryption for specified
blocks of ram.

D. Stimits, stimits at idcomm.com

> 
> > 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
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug