Messages in this thread | | | Date | Fri, 3 Dec 1999 15:41:23 -0500 (EST) | From | "Robert G. Brown" <> | Subject | Re: malware defense |
| |
On Fri, 3 Dec 1999 andrew@daviel.org wrote:
> I wondered if it were possible to do something like compute a checksum > of images before running them and compare with a database of digitally > signed checksums, or do the old VMS thing and assign images network > privileges. I had thought to write a daemon that occasionally runs through > /proc/*/exe and checks things. > > It occurs to me that the Java community has been through all this already, > though I get the impression that signing of objects is pretty rare still, > and the tools I had seen for signing Netscape applets were commercial. > > > thoughts ? > ideas ? > "been there, done that" ?
The problem is that >>any<< daemon, running basically outside of the kernel as an ordinary task, just continues a vicious cycle of:
a: (bad guys) develop clever(er) exploit (good guys) develop clever(er) counterexploit goto a:
How do you protect against corruption/replacement of the daemon software that checks the images? Quid custode custodes? Right now, "rootkit" packages come with pre-scripted cracking tools that, when they succeed, encapsulate the cracker invisibly, blinding the tools required to "see" them. This just adds another tool or layer of tools they have to replace. After all, how are you to know if the daemon you started is truly the daemon that is currently running if the cracker controls the daemon, ps, ls, and all that? They'll all lie to you, just like they do now for many rootkits.
As long as the crackers have access to the open source of the anti-cracking daemons and tools you are using to try to control them, you are forever going to be trying to lock a door in a universe where unscrupulous locksmiths always have access to the door. Not that there isn't a benefit in adding another security layer for the crackers to have to master -- it is at least another place for them to make mistakes and perhaps ups the ante of difficulty so you only get nailed by the better quality of cracker and not the riffraff off of the street, so to speak, at least until the rootkit comes out that encapsulates all the work done by the Ubercracker to get into systems thus protected.
Note that in endgame 2 (snoop and steal) or in endgame 3 (just steal all the useful and possibly valuable software and data on your system) there is more than just the macho incentive that drives the riffraff cracker. The crackers derive real value worth money from their success, not just bragging rights to their K001 friends. Somebody who expects to make hundreds of thousands of dollars from their cracking activities is going to take the time to carefully develop counter-countermeasures to any countermeasure you dream up and actually publish. This situation is bound to become more and more common. Want to increase the profitability of your HMO? Find out how to steal hospital or employment data on patients seeking insurance and deny coverage to the sick, lame and lazy. Want to make money selling marketing lists? Set up traps like those of the Russians that you describe. Want to succeed in politics? Electro-Watergate is just around the corner, if any presidential candidates have dirt recorded on them in any database in the world, some dirtball will undoubtedly soon winkle it out -- and sell it.
There are still some strategies that are reasonably likely to protect hosts (mostly ones that involve really carefully monitoring one's system, knowing what one is doing, not being careless, more than the use of any specific tools). I'm certain that this subject gives nightmares to e.g. red hat/rufus folks and to the debian package site folks. After all, they could arguably be sued if somebody succeeded in trojaning say, the master copy of the 6.1 distribution on the red hat ftp site and somebody lost money as a consequence. Even without being sued, think of how their corporate reputation would suffer ("Red Hat cannot even keep their OWN website safe, how can they protect ours...").
The strategic defense that I think is "best" for midsize domains that require a fair amount of "free access" (like a University) is to adopt an "inside out firewall", or "ring of defences" with increasing layers of security from the outside in rather than from the inside out. In this strategy, each interior layer to safeguards the ones outside. For example, you might have one (or more) "totally defended" box that can only be accessed from the physical console kept in a locked room and with an attached lineprinter that makes hardcopies of all the logs in realtime so electronic deletion is literally impossible. This box might offer >>only<< a (carefully sanitized and scrutinized and buffer-overwrite-bug-free) syslogd as an incoming connection, for example.. This box might protect a set of limited access servers that are sufficiently complex that mere rootkits are unlikely to succeed by logging >>all<< activity on those servers -- hopefully on a time/event granularity that would permit any unauthorized intrusion to be detected without exception and logged on the central host where the cracker cannot possibly get at it.
Those servers might then serve (and protect) a collection of relatively secure workstations with normal (but sensible and tcp-wrapped) port offerings. With a clever enough arrangement of RO mounts of space from the protected servers, you could at least arrange a system that would have to have the kernel itself compromised in order to hide a cracker, which would in turn require a reboot (red flag) and/or leave time for the crack to be revealed in the logs. Around these there might be an even lower security ring of insecure hosts (visiting laptops, insecure OS architectures, and so forth) that are on the network but provide few services and receive little trust.
Note that this is a sort of feudal arrangement, with the castle keep at the center protecting the castle, the castle protecting the town, and possible with the town protecting an even lower security ring of peasants (e.g. WinXX stations, Macintoads). The systems administrator is the feudal lord who sits in the keep and controls the castle while jealously guarding their (IP) domain. Smarter than trying to build the Great Wall of China or a Maginot Line (to cite two famous failures of the firewall strategy:-) around the whole thing.
To keep this conversation relevant to a kernel list: Rather than trying to provide the protection you suggest via a daemon, I'd suggest trying to provide it with a kernel module. A daemon can be caught, controlled, killed, replaced, its port saturated and blocked. A kernel module, especially if it is written to be "insert only" and essentially crash a system with lots of loud and dire warnings piped directly into a port on a truly secure host if it were to be removed or reinserted or the system was tampered with in certain key ways, might provide protection at a level where crackers couldn't (easily, at least) defeat it with scripted "smart" binaries in a compromised system. At the very least you could WAY up the ante -- somebody would likely have to work directly with /dev/kmem to rewrite part of a running kernel to defeat the protection.
If they're THAT good, what the hell, let them HAVE the bloody system. They deserve it.
rgb
Robert G. Brown http://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@phy.duke.edu
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |