lkml.org 
[lkml]   [1999]   [Dec]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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/

    \
     
     \ /
      Last update: 2005-03-22 13:55    [W:0.031 / U:28.576 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site