Message-ID: <871xcov8cj.fsf@benpfaff.org>
Date: Thu, 13 Jan 2005 22:21:48 -0800
From: Ben Pfaff <blp@...stanford.edu>
To: John Richard Moser <nigelenki@...cast.net>
Cc: bugtraq@...urityfocus.com
Subject: Re: Is DEP easily evadable?


John Richard Moser <nigelenki@...cast.net> writes:

> Ben Pfaff wrote:
>> John Richard Moser <nigelenki@...cast.net> writes:
>>>PaX does pretty nice randomization.  I think 15/16 for heap and stack
>>>and 24 for mmap(), though I could be overshooting the 24.  I'm on amd64
>>>so I can't just run paxtest and see; though I could read the source code.
>> 
>> In some fairly reasonable circumstances, this may not be
>> enough. [...]
>
> Brad says he's seen it, and that at the time of that writing he'd
> already solved that problem.
>
> Apparently in grsecurity, once you've caused a program to segfault or
> get a PaX kill, it's flagged to delay all future forks by 30 seconds, or
> something like that.  I don't know the exact details.

That's acceptable if you can afford to transform a (potentially
non-exploitable) segfault-inducing bug into a full-scale DoS.
It's a trade-off that in my opinion each site has to evaluate for
itself.  We talked about this in the paper.  Let me excerpt (this
is from tag-stripped LaTeX sources so it doesn't have the
references in the full paper):

    Monitoring and Catching Errors

    The PaX developers suggest that ASLR be combined with "a
    crash detection and reaction mechanism", which we call a
    "watcher".  An attacker who attempts to discover addresses
    within ASLR-protected executables will, in the process,
    trigger segmentation violations through his inevitably
    incorrect guesses.  The watcher can detect these segmentation
    violations and take action to impede the attacker; for
    example, shut down the program under attack.

    We do not believe that the crash watcher is a viable defense
    mechanism because of the limited actions the crash watcher
    can undertake when it discovers that a PaX-protected forking
    daemon is experiencing segmentation faults.  Either the
    watcher alerts an administrator or it acts on its own.  If it
    acts on its own, it can either shut down the daemon entirely
    or attempt to prevent the attacker from exploiting it.

    If the watcher alerts an administrator, then it is difficult
    to see how the administrator can react in time.  Our
    demonstrated attack can be completed in 216 seconds on the
    average, less time than would be necessary to diagnose the
    network traffic, read BugTraq, assess the severity of the
    situation, and take corrective measures.  The administrator
    could also shut down the daemon before attempting a
    diagnosis, but in this case he would be acting no more
    intelligently than the watcher might.

    If, indeed, the watcher shuts down the daemon altogether
    pending an administrator's attention, then it in effect acts
    as a force multiplier for denial of service.  If Amazon.com's
    Apache servers are PaX-protected and watched, and a
    vulnerability is discovered in Apache that allows a
    segmentation violation to be induced, then Amazon can be
    taken offline persistently, with a minimum of attacker
    effort.  Being taken offline persistently can be costly;
    reports in 2000 show that Amazon loses about $180,000 per
    hour of downtime.

    While it may be true that Amazon would do better with
    disabled servers than compromised servers--that, in the end,
    is an economic question--it is, nevertheless, also true that
    it is difficult to distinguish exploitable vulnerabilities
    from mere (segfault-inducing) denial of service.  Neither an
    automated watcher program nor a system administrator working
    under time pressure can be expected to make the correct
    determination.

    It is worth illustrating how difficult these two cases are to
    distinguish, even for expert programmers.  The Apache
    chunked-encoding vulnerability was for several days believed,
    by the Apache developers themselves, not to be exploitable on
    32-bit platforms: "Due to the nature of the overflow on
    32-bit Unix platforms this will cause a segmentation
    violation and the child will terminate".  After the release
    of a working exploit for 32-bit BSD platforms, the Apache
    developers revised their analysis: "Though we previously
    reported that 32-bit platforms were not remotely exploitable,
    it has since been proven by Gobbles that certain conditions
    allowing exploitation do exist".

    Furthermore, unless the segfault watcher shuts down the
    daemon permanently after a single segmentation violation, an
    attacker can still slip under the radar.  For example, if the
    watcher acts after observing ten crashes in a one-minute
    period, the attacker can seek addresses by brute force at the
    rate of nine attempts per minute.  The same holds if the
    watcher keeps a daemon shut down for several seconds after a
    crash.  Such a watcher is, furthermore, as much a force
    multiplier for denial of service as one that shuts down the
    watched daemon after a single crash.

    Finally, a watcher could attempt to prevent an attacker from
    exploiting a vulnerability while allowing the daemon to
    continue running.  It might, for example, attempt to
    determine the network source of the offending requests and
    selectively firewall the source away from the daemon.  But
    this assumes that the attacker can be effectively localized.
    With zombie networks numbering hundreds of thousands of
    compromised hosts available for use as launchpads, attackers
    can design and deploy worms that attack vulnerable daemons in
    a coordinated fashion: no source machine needs to connect to
    the attacked machine more than once, so a firewalling watcher
    is of no value.  Properly-engineered automated threats,
    therefore, are capable of bypassing even firewalling watchers
    unimpeded.

    Sites that run large numbers of servers often load-balance
    incoming requests.  In such situations clients are not always
    guaranteed persistent sessions with a single server, but
    instead get a different server assigned to each
    request. (Load balancing slows down our attack only by a
    factor of 2.)  A watcher running locally on one of these
    servers would be unable to detect an attack, since subsequent
    segfault-inducing requests are likely to be routed to
    different servers.  In order to detect such an attack, a
    networked watcher is required that can correlate
    segfault-inducing requests.  Such a networked watcher would
    be difficult to implement and would not be much better at
    making watcher decisions than a host based watcher, due to
    the inherent difficulty of implementing a realistic watcher
    strategy.

    In summary, the discussion above suggests that any reasonable
    implementation of the crash watcher suggested by the PaX
    documentation cannot prevent an attack such as we describe
    above from succeeding, except at the cost of facilitating and
    exacerbating denial-of-service vulnerabilities in the watched
    daemon.

-- 
Ben Pfaff 
email: blp@...stanford.edu
web: http://benpfaff.org

Powered by blists - more mailing lists