Debian Bug report logs - #261755
wget: Server responses &c written to the tty verbatim (escape sequences, control characters, ...)

version graph

Package: wget; Maintainer for wget is Noël Köthe <noel@debian.org>; Source for wget is src:wget.

Reported by: Jan Minar <jjminar@fastmail.fm>

Date: Wed, 28 Jul 2004 00:48:01 UTC

Severity: grave

Tags: patch, security

Found in version 1.8.1-6.1

Fixed in versions wget/1.9.1-5, wget/1.9.1-11

Done: Frank Lichtenheld <djpig@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Noèl Köthe <noel@debian.org>:
Bug#261755; Package wget. Full text and rfc822 format available.

Acknowledgement sent to Jan Minar <jjminar@fastmail.fm>:
New Bug report received and forwarded. Copy sent to Noèl Köthe <noel@debian.org>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Jan Minar <jjminar@fastmail.fm>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Cc: bug-wget@gnu.org
Subject: wget: Server responses &c written to the tty verbatim (escape sequences, control characters, ...)
Date: Wed, 28 Jul 2004 02:31:09 +0200
[Message part 1 (text/plain, inline)]
Package: wget
Version: 1.8.1-6.1
Severity: grave
Justification: user security hole
Tags: security patch

Hi.

Wget does absolutely no filtering of the server-supplied error messages,
and redirection URLs.  And probably just anywhere else.

Both 1.8 & 1.9 branches exhibit this behaviour.

A simple not-very-functional demo is attached.

I found out there are just too many places where wget should filter, but
doesn't.  The enclosed patch is covering just one of these places,
sadly.  And even this tiny bit is covered badly, as, e.g., there's no
need to mark the message as server-generated, when in fact it's our
message about the lack of any message from the server, heh.

The comments in the patch should explain my reasoning in detail -- the
basic goals:

(1) Filter escape sequences & friends
	-- HTTP 1.1 RFC allows [^\r\n\x00-\x1f\127]
(2) Mark the beginning & the end, and purpose of the message (``Remote
 	server said: >>> ... <<<'')
(3) Don't allow ending faking (remove extraneous whitespace, escape the end mark)
	-- ``A recipient MAY replace any linear white space with a single SP
	before interpreting the field value''  -- RFC 2616, Section 2.2

Please CC me, when appropriate.

Cheers.
Jan.

-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux kontryhel 2.4.26-jan #3 SMP Mon Apr 19 05:00:00 CEST 2004 i686
Locale: LANG=C, LC_CTYPE=cs_CZ.ISO-8859-2

Versions of packages wget depends on:
ii  libc6                         2.2.5-11.5 GNU C Library: Shared libraries an

-- 
   "To me, clowns aren't funny. In fact, they're kind of scary. I've wondered
 where this started and I think it goes back to the time I went to the circus,
			  and a clown killed my dad."
[wgettrap (text/plain, attachment)]
[wget.scam.patch (text/plain, attachment)]
[Message part 4 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Noèl Köthe <noel@debian.org>:
Bug#261755; Package wget. Full text and rfc822 format available.

Acknowledgement sent to Florian Weimer <fw@deneb.enyo.de>:
Extra info received and forwarded to list. Copy sent to Noèl Köthe <noel@debian.org>. Full text and rfc822 format available.

Message #10 received at 261755@bugs.debian.org (full text, mbox):

From: Florian Weimer <fw@deneb.enyo.de>
To: 261755@bugs.debian.org
Subject: Patch review
Date: Fri, 30 Jul 2004 20:25:37 +0200
+	/* We encode each byte using at most 4 bytes, + trailing '\0'. */
+	buf = xmalloc (4 * strlen (reason_phrase_ptr) + 1);

Where is this buffer freed?  Or is this compatible with the existing
approach to memory management in wget?

-	  logprintf (LOG_NOTQUIET, _("%s ERROR %d: %s.\n"),
+	  /*
+	   * XXX Let's not allow the attacker pretend it's us speaking.
+	   *
+	   * It's important to:
+	   * (1) Explain who created the message
+	   * (2) Mark very visibly the beginning & end of the message
+	   * (3) Make clear we have no connection whatsoever with this message
+	   */
+	  /* logprintf (LOG_NOTQUIET, _("%s ERROR %d: %s.\n"), */
+	  logprintf (LOG_NOTQUIET,
+			_("%s ERROR: Remote server said: >>> %d %s <<<.\n"),

I suppose that it would be better to use C-style quoting (with "")
instead of yet another ad-hoc string literal syntax.  To increase
backwards compatibility, it's probably best to add the quotes only if
potentially harmful characters are actually contained in the server
response.

Note that you'd also have to change escape_reason_phrase().

-	  logprintf (LOG_NOTQUIET, "%d %s\n\n", hstat.statcode, hstat.error);
+	  logprintf (LOG_NOTQUIET, _(">>> %d %s <<<\n\n"),
+			  hstat.statcode, hstat.error);

Same here.

What's the status of this bug with respect to upstream?  Has it been
sent in for review?



Information forwarded to debian-bugs-dist@lists.debian.org, Noèl Köthe <noel@debian.org>:
Bug#261755; Package wget. Full text and rfc822 format available.

Acknowledgement sent to Noèl Köthe <noel@debian.org>:
Extra info received and forwarded to list. Copy sent to Noèl Köthe <noel@debian.org>. Full text and rfc822 format available.

Message #15 received at 261755@bugs.debian.org (full text, mbox):

From: Noèl Köthe <noel@debian.org>
To: Florian Weimer <fw@deneb.enyo.de>, 261755@bugs.debian.org
Subject: Re: Bug#261755: Patch review
Date: Fri, 30 Jul 2004 21:47:16 +0200
[Message part 1 (text/plain, inline)]
Am Fr, den 30.07.2004 schrieb Florian Weimer um 20:25:

> What's the status of this bug with respect to upstream?  Has it been
> sent in for review?

bug/patch submitter CC: the report to the upstream mailinglist (archive:
http://www.mail-archive.com/wget%40sunsite.dk/) but there is no answer
to the mail until now.

-- 
Noèl Köthe <noel debian.org>
Debian GNU/Linux, www.debian.org
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Noèl Köthe <noel@debian.org>:
Bug#261755; Package wget. Full text and rfc822 format available.

Acknowledgement sent to Noèl Köthe <noel@debian.org>:
Extra info received and forwarded to list. Copy sent to Noèl Köthe <noel@debian.org>. Full text and rfc822 format available.

Message #20 received at 261755@bugs.debian.org (full text, mbox):

From: Noèl Köthe <noel@debian.org>
To: Florian Weimer <fw@deneb.enyo.de>, 261755@bugs.debian.org
Cc: Jan Minar <jjminar@fastmail.fm>
Subject: Re: Bug#261755: Patch review
Date: Wed, 11 Aug 2004 13:08:24 +0200
[Message part 1 (text/plain, inline)]
Am Fr, den 30.07.2004 schrieb Florian Weimer um 20:25:

Hello,

fullquote because Jan asked for CC: and the previous mail wasn't CC: to
him.

> +	/* We encode each byte using at most 4 bytes, + trailing '\0'. */
> +	buf = xmalloc (4 * strlen (reason_phrase_ptr) + 1);
> 
> Where is this buffer freed?  Or is this compatible with the existing
> approach to memory management in wget?
> 
> -	  logprintf (LOG_NOTQUIET, _("%s ERROR %d: %s.\n"),
> +	  /*
> +	   * XXX Let's not allow the attacker pretend it's us speaking.
> +	   *
> +	   * It's important to:
> +	   * (1) Explain who created the message
> +	   * (2) Mark very visibly the beginning & end of the message
> +	   * (3) Make clear we have no connection whatsoever with this message
> +	   */
> +	  /* logprintf (LOG_NOTQUIET, _("%s ERROR %d: %s.\n"), */
> +	  logprintf (LOG_NOTQUIET,
> +			_("%s ERROR: Remote server said: >>> %d %s <<<.\n"),
> 
> I suppose that it would be better to use C-style quoting (with "")
> instead of yet another ad-hoc string literal syntax.  To increase
> backwards compatibility, it's probably best to add the quotes only if
> potentially harmful characters are actually contained in the server
> response.
> 
> Note that you'd also have to change escape_reason_phrase().
> 
> -	  logprintf (LOG_NOTQUIET, "%d %s\n\n", hstat.statcode, hstat.error);
> +	  logprintf (LOG_NOTQUIET, _(">>> %d %s <<<\n\n"),
> +			  hstat.statcode, hstat.error);
> 
> Same here.
> 
> What's the status of this bug with respect to upstream?  Has it been
> sent in for review?

Still no answer from upstream to Jans patch/bug.

-- 
Noèl Köthe <noel debian.org>
Debian GNU/Linux, www.debian.org
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Noèl Köthe <noel@debian.org>:
Bug#261755; Package wget. Full text and rfc822 format available.

Acknowledgement sent to Jan Minar <jjminar@fastmail.fm>:
Extra info received and forwarded to list. Copy sent to Noèl Köthe <noel@debian.org>. Full text and rfc822 format available.

Message #25 received at 261755@bugs.debian.org (full text, mbox):

From: Jan Minar <jjminar@fastmail.fm>
To: Noel Köthe <noel@debian.org>
Cc: Florian Weimer <fw@deneb.enyo.de>, 261755@bugs.debian.org
Subject: Re: Bug#261755: Patch review
Date: Fri, 13 Aug 2004 03:22:40 +0200
[Message part 1 (text/plain, inline)]
On Wed, Aug 11, 2004 at 01:08:24PM +0200, Noel Köthe wrote:
> Am Fr, den 30.07.2004 schrieb Florian Weimer um 20:25:

> fullquote because Jan asked for CC: and the previous mail wasn't CC: to
> him.

Thanks.  Note that when you send a mail to <number>@bugs.debian.org, the
original submitter is *not* sent a copy; you have to CC: the submitter
explicitly.

> > +	/* We encode each byte using at most 4 bytes, + trailing '\0'. */
> > +	buf = xmalloc (4 * strlen (reason_phrase_ptr) + 1);
> > 
> > Where is this buffer freed?  Or is this compatible with the existing
> > approach to memory management in wget?

It isn't.  Did I mention I can't code in C?...

> > -	  logprintf (LOG_NOTQUIET, _("%s ERROR %d: %s.\n"),
> > +	  /*
> > +	   * XXX Let's not allow the attacker pretend it's us speaking.
> > +	   *
> > +	   * It's important to:
> > +	   * (1) Explain who created the message
> > +	   * (2) Mark very visibly the beginning & end of the message
> > +	   * (3) Make clear we have no connection whatsoever with this message
> > +	   */
> > +	  /* logprintf (LOG_NOTQUIET, _("%s ERROR %d: %s.\n"), */
> > +	  logprintf (LOG_NOTQUIET,
> > +			_("%s ERROR: Remote server said: >>> %d %s <<<.\n"),
> > 
> > I suppose that it would be better to use C-style quoting (with "")
> > instead of yet another ad-hoc string literal syntax.

Let's split this effort in four consequential steps:

(I) Filtering the control characters (including escape-sequences).

This is easy, if it weren't for so many places in the code that have to
be changed, and the massive difference between the woody & sarge
version.  Just set the correct locale, do isprint(), and escape
appropriately.  This can and should be adopted without a delay.

The following steps deal primarily with the freeform server-response:

(II) Making it possible to determine what the server-response is

You have to ensure the beginning & ending delimiters are not spoofable.
With Unicode, where similar glyphs are not so uncommon, and '\n' being
supplied by the terminal by the virtue of wrapping, this soon gets
tricky.

The begin-delimiter is ``Remote server said: BEGIN_QUOT'', the
end-delimiter is ``END_QUOT\n''.  The begin-delimiter will work good,
regardless of the BEGIN_QUOT value.  The only problem is we can't really
tell whether it was the *remote server*, or some third party (attacker),
who originated the message.  If someone could come up with a more
appropriate phrase, I'd be pleased.  The end-delimiter and any similar
glyphs (locale-dependent) will be escaped in the server-response, so
that it can't be spoofed.  As we will never know which characters look
similar in a given font/locale combination, therefore we can never be
100% confident we are secure against spoofing.  This, too, can be
implemented right ahead.

I chose ">>>"/"<<<" (and not e.g. '"') for BEGIN_QUOT/END_QUOT precisely
because it is not used anywhere in wget, and it looks strange, so to
pinpoint the message is not from us, but from some strange untrusted
source.  ">>>" BTW is the python shell prompt.

(III) Marking the server-responses in an obvious and intuitive way

Hard if not impossible.  Who cares about missing end-delimiter?  When a
text starts in column 0, it looks like coming from the running program,
no matter what.  You'd have to either turn the wrapping off, or you have
to know the width of the display.  Or you can draw a border around the
whole message (horrible, and space-wasting).

We could collapse the end-delimiter just to ``\n'', and to split the
server-response in among multiple lines, prepending the begin-delimiter
and the (possibly different) begin-delimiter-continuation, before every
one.  Then, we could leave out BEGIN_QUOT, too.  This is likely to break
some existing software.  The tricky part is to get the display width
*reliably*.  We can't just default to 80, as this would present a
problem for terminals with the actual width <80.  We could simply output
an error message and print *no* server-response.  We could have our own
built-in dictionary of standard error number interpretations.

(IV) Making it impossible to fool a casual user

This is impossible.  There will always people that would be vulnerable
because of bad luck, stupidity, poor language knowledge, etc.

> >                                                       To increase
> > backwards compatibility, it's probably best to add the quotes only if
> > potentially harmful characters are actually contained in the server
> > response.

Three points here:

(a) The user should get used to the format; this would improve
his/her confidence that what s/he sees is what s/he think it is.

(b) Any message above the numeric code is potentially dangerous; we are
talking social engineering here: we must make clear the message is *not
from us*.

(c) You are right that the original patch would break existing software,
so the new suggestion is to quote the free-form part of the server
response, and let the numeric code as it is.

	_("%s ERROR %d: Remote server said: >>> %s <<<.\n"),
	           ^^^
Please keep me CC'd.

Jan.

-- 
   "To me, clowns aren't funny. In fact, they're kind of scary. I've wondered
 where this started and I think it goes back to the time I went to the circus,
			  and a clown killed my dad."
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Noèl Köthe <noel@debian.org>:
Bug#261755; Package wget. Full text and rfc822 format available.

Acknowledgement sent to Thomas Hood <jdthood@aglu.demon.nl>:
Extra info received and forwarded to list. Copy sent to Noèl Köthe <noel@debian.org>. Full text and rfc822 format available.

Message #30 received at 261755@bugs.debian.org (full text, mbox):

From: Thomas Hood <jdthood@aglu.demon.nl>
To: 261755-submitter@bugs.debian.org, 261755@bugs.debian.org
Cc: Florian Weimer <fw@deneb.enyo.de>
Subject: Can this be fixed in time for sarge?
Date: Sun, 22 Aug 2004 11:39:07 +0200
The changes contemplated look very invasive.  How quickly can this
bug be fixed?
--
Thomas Hood




Message sent on to Jan Minar <jjminar@fastmail.fm>:
Bug#261755. Full text and rfc822 format available.

Information stored:
Bug#261755; Package wget. Full text and rfc822 format available.

Acknowledgement sent to Jan Minar <jjminar@fastmail.fm>:
Extra info received and filed, but not forwarded. Full text and rfc822 format available.

Message #38 received at 261755-quiet@bugs.debian.org (full text, mbox):

From: Jan Minar <jjminar@fastmail.fm>
To: Thomas Hood <jdthood@aglu.demon.nl>, 261755-quiet@bugs.debian.org
Subject: Re: Bug#261755: Can this be fixed in time for sarge?
Date: Sun, 22 Aug 2004 13:12:43 +0200
[Message part 1 (text/plain, inline)]
On Sun, Aug 22, 2004 at 11:39:07AM +0200, Thomas Hood wrote:
> The changes contemplated look very invasive.  How quickly can this
> bug be fixed?

It looks like we'd have to go thru the whole code, sanitizing all calls
to logprintf() where a tainted variable is involved.  This is tedious.

I'm leaning towards solving the control-chars injection by a wrapper
that would filter these.  I can't think of no such workaround for the
spoofing vulnerability.

J.

-- 
   "To me, clowns aren't funny. In fact, they're kind of scary. I've wondered
 where this started and I think it goes back to the time I went to the circus,
			  and a clown killed my dad."
[Message part 2 (application/pgp-signature, inline)]

Information stored:
Bug#261755; Package wget. Full text and rfc822 format available.

Acknowledgement sent to Jan Minar <jjminar@fastmail.fm>:
Extra info received and filed, but not forwarded. Full text and rfc822 format available.

Message #43 received at 261755-quiet@bugs.debian.org (full text, mbox):

From: Jan Minar <jjminar@fastmail.fm>
To: Thomas Hood <jdthood@aglu.demon.nl>, 261755-quiet@bugs.debian.org
Subject: Re: Bug#261755: Can this be fixed in time for sarge?
Date: Sun, 22 Aug 2004 13:32:12 +0200
[Message part 1 (text/plain, inline)]
On Sun, Aug 22, 2004 at 01:12:43PM +0200, Jan Minar wrote:
> I'm leaning towards solving the control-chars injection by a wrapper
> that would filter these.  I can't think of no such workaround for the
> spoofing vulnerability.

Here's the script:

--- /dev/null	Wed Dec 10 03:42:57 2003
+++ /home/jan/bin/wget	Sun Aug 22 13:18:19 2004
@@ -0,0 +1,6 @@
+#!/bin/sh
+# ~jan/bin/wget -- wget wrapper that'll get rid of the escape sequences
+
+WGET=/usr/bin/wget
+
+"$WGET" -o /dev/fd/1 "$@" | filter-controls


Here's the filter-controls source:

--- /dev/null	Wed Dec 10 03:42:57 2003
+++ /home/jan/code/filter-controls/filter-controls.c	Tue Aug 17 01:50:28 2004
@@ -0,0 +1,43 @@
+#include <stdio.h>
+#include <ctype.h>
+#include <stdlib.h>
+
+void my_putchar(char);
+
+/* my_putchar(char) error-checking putchar() wrapper */
+/* DNW: Somehow echo hello | ./filter-controls > /dev/full returns 0. */
+inline void
+my_putchar (char c) {
+	if (putchar (c) == EOF) {
+		perror ("Error writing to stdout");
+		exit (1);
+	}
+}
+
+int
+main (void)
+{
+	int c;
+	int last_was_space = 0;
+
+	setbuf (stdout, NULL);
+
+	while ((c = getchar()) != EOF) {
+		if (isgraph(c) || c == '\n') {
+			my_putchar (c);
+			last_was_space = 0;
+		} else if (isspace (c)) {
+			if (last_was_space == 0)
+				my_putchar (' ');
+			last_was_space = 1;
+		} else  {
+			my_putchar ('\\');
+			my_putchar ('0' + ((c & 0xff) >> 6));
+			my_putchar ('0' + ((c & 0x3f) >> 3));
+			my_putchar ('0' + (c & 7));
+
+			last_was_space = 0;
+		}
+	}
+	return 0;
+}


Of course the script is not necessary; I only didn't want to learn
setting up pipes in C.

The problem here is, we lose the nice progress bar, getting the tedious
dot-progress interface instead.  Nobody will like this.  So maybe
hooking/rewriting the logprintf() function will be an option, although
I don't like it.

Jan.

-- 
   "To me, clowns aren't funny. In fact, they're kind of scary. I've wondered
 where this started and I think it goes back to the time I went to the circus,
			  and a clown killed my dad."
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Noèl Köthe <noel@debian.org>:
Bug#261755; Package wget. Full text and rfc822 format available.

Acknowledgement sent to Jan Minar <jjminar@fastmail.fm>:
Extra info received and forwarded to list. Copy sent to Noèl Köthe <noel@debian.org>. Full text and rfc822 format available.

Message #48 received at 261755@bugs.debian.org (full text, mbox):

From: Jan Minar <jjminar@fastmail.fm>
To: Thomas Hood <jdthood@aglu.demon.nl>, 261755@bugs.debian.org
Cc: control@bugs.debian.org, bug-wget@gnu.org
Subject: Re: Bug#261755: Control sequences injection patch
Date: Sun, 22 Aug 2004 20:02:54 +0200
[Message part 1 (text/plain, inline)]
tags 261755 +patch
thanks

On Sun, Aug 22, 2004 at 11:39:07AM +0200, Thomas Hood wrote:
> The changes contemplated look very invasive.  How quickly can this
> bug be fixed?

Here we go:  Hacky, non-portable, but pretty slick & non-invasive,
whatever that means.  Now I'm going to check whether it is going to
catch all the cases where malicious characters could be possibly
injected.

This patch (hopefully) solves the problem of remote attacker (server or
otherwise) injects malicious control sequences in the HTTP headers.  It
by no mean solves the spoofing bug, which is by nature tricky to address
well.

Cheers,
Jan.

-- 
   "To me, clowns aren't funny. In fact, they're kind of scary. I've wondered
 where this started and I think it goes back to the time I went to the circus,
			  and a clown killed my dad."
[wget-filter-controls.patch (text/plain, attachment)]
[Message part 3 (application/pgp-signature, inline)]

Tags added: patch Request was from Jan Minar <jjminar@fastmail.fm> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Noèl Köthe <noel@debian.org>:
Bug#261755; Package wget. Full text and rfc822 format available.

Acknowledgement sent to Jan Minar <jjminar@fastmail.fm>:
Extra info received and forwarded to list. Copy sent to Noèl Köthe <noel@debian.org>. Full text and rfc822 format available.

Message #55 received at 261755@bugs.debian.org (full text, mbox):

From: Jan Minar <jjminar@fastmail.fm>
To: Thomas Hood <jdthood@aglu.demon.nl>, 261755@bugs.debian.org, bug-wget@gnu.org
Subject: Re: Bug#261755: Control sequences injection patch
Date: Tue, 24 Aug 2004 03:11:28 +0200
[Message part 1 (text/plain, inline)]
On Sun, Aug 22, 2004 at 08:02:54PM +0200, Jan Minar wrote:
> +/* vasprintf() requires _GNU_SOURCE.  Which is OK with Debian. */
> +#ifndef _GNU_SOURCE
> +#define _GNU_SOURCE

This must be done before stdio.h is included.

> +#endif
> +#include <ctype.h>
> +
>  #ifndef errno
>  extern int errno;
>  #endif
> @@ -345,7 +351,49 @@
>    int expected_size;
>    int allocated;
>  };
> +
> +/* XXX Where does the declaration belong?? */
> +void escape_buffer (char **src);
>  
> +/*
> + * escape_untrusted  -- escape using '\NNN'.  To be used wherever we want to
> + * print untrusted data.
> + *
> + * Syntax: escape_buffer (&buf-to-escape);
> + */
> +void escape_buffer (char **src)
> +{
> +	char *dest;
> +	int i, j;
> +
> +	/* We encode each byte using at most 4 bytes, + trailing '\0'. */
> +	dest = xmalloc (4 * strlen (*src) + 1);
> +
> +	for (i = j = 0; (*src)[i] != '\0'; ++i) {
> +		/*
> +		 * We allow any non-control character, because LINE TABULATION
> +		 * & friends can't do more harm than SPACE.  And someone
> +		 * somewhere might be using these, so unless we actually can't
> +		 * protect against spoofing attacks, we don't pretend we can.
> +		 *
> +		 * Note that '\n' is included both in the isspace() *and*
> +		 * iscntrl() range.
> +		 */
> +		if (isprint((*src)[i]) || isspace((*src)[i])) {

This lets '\r' thru, not good.  BTW, (*src)[i] is quite a cypher.

> +			dest[j++] = (*src)[i];
> +		} else {
> +			dest[j++] = '\\';
> +			dest[j++] = '0' + (((*src)[i] & 0xff) >> 6);
> +			dest[j++] = '0' + (((*src)[i] & 0x3f) >> 3);
> +			dest[j++] = '0' + ((*src)[i] & 7);
> +		}
> +	}
> +	dest[j] = '\0';
> +
> +	xfree (*src);
> +	*src = dest;
> +}


Attached is version 2, which solves these problems.

Please keep me CC'd.

Jan.

-- 
   "To me, clowns aren't funny. In fact, they're kind of scary. I've wondered
 where this started and I think it goes back to the time I went to the circus,
			  and a clown killed my dad."
[wget-filter-controls.patch.v2 (text/plain, attachment)]
[Message part 3 (application/pgp-signature, inline)]

Reply sent to Noèl Köthe <noel@debian.org>:
You have taken responsibility. Full text and rfc822 format available.

Notification sent to Jan Minar <jjminar@fastmail.fm>:
Bug acknowledged by developer. Full text and rfc822 format available.

Message #60 received at 261755-close@bugs.debian.org (full text, mbox):

From: Noèl Köthe <noel@debian.org>
To: 261755-close@bugs.debian.org
Subject: Bug#261755: fixed in wget 1.9.1-5
Date: Mon, 13 Sep 2004 17:32:08 -0400
Source: wget
Source-Version: 1.9.1-5

We believe that the bug you reported is fixed in the latest version of
wget, which is due to be installed in the Debian FTP archive:

wget_1.9.1-5.diff.gz
  to pool/main/w/wget/wget_1.9.1-5.diff.gz
wget_1.9.1-5.dsc
  to pool/main/w/wget/wget_1.9.1-5.dsc
wget_1.9.1-5_i386.deb
  to pool/main/w/wget/wget_1.9.1-5_i386.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 261755@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Noèl Köthe <noel@debian.org> (supplier of updated wget package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


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

Format: 1.7
Date: Mon, 13 Sep 2004 22:55:58 +0200
Source: wget
Binary: wget
Architecture: source i386
Version: 1.9.1-5
Distribution: unstable
Urgency: high
Maintainer: Noèl Köthe <noel@debian.org>
Changed-By: Noèl Köthe <noel@debian.org>
Description: 
 wget       - retrieves files from the web
Closes: 197916 261755
Changes: 
 wget (1.9.1-5) unstable; urgency=high
 .
   * added patch from Jan Minar <jjminar fastmail.fm> which corrects
     the parsing/filtering of answer from servers
     (Thanks alot for your help Jan!)
     (closes: Bug#261755)
   * documenting incompatibility of -k and -O
     (closes: Bug#197916)
Files: 
 4543b701997bcb32529c78606b8e4081 596 web optional wget_1.9.1-5.dsc
 2d9081bcbe108e443be4ed8f9c465537 11752 web optional wget_1.9.1-5.diff.gz
 beb626e0a77a3eb9ed85bfdd89a1d800 424634 web optional wget_1.9.1-5_i386.deb

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

iD8DBQFBRgnL9/DnDzB9Vu0RAgE9AJ4nVAzUfQiHJrur2Eo1K4F8AFu3TACeMkpk
hMpSnjKIKfMR7TrYcRVns6o=
=hWNT
-----END PGP SIGNATURE-----




Information forwarded to debian-bugs-dist@lists.debian.org, Noèl Köthe <noel@debian.org>:
Bug#261755; Package wget. Full text and rfc822 format available.

Acknowledgement sent to Tomas Pospisek <tpo@sourcepole.ch>:
Extra info received and forwarded to list. Copy sent to Noèl Köthe <noel@debian.org>. Full text and rfc822 format available.

Message #65 received at 261755@bugs.debian.org (full text, mbox):

From: Tomas Pospisek <tpo@sourcepole.ch>
To: 261755@bugs.debian.org
Cc: jjminar@fastmail.fm
Subject: wget sid->sarge
Date: Sun, 26 Sep 2004 00:26:48 +0200 (CEST)
I'm going through the list of packages that are pending to transition from 
sid->sarge in order to tag them for manual propagation [1]. I've seen that 
wget in sid fixes a security issue [2] (no sanitizing of server 
responses). Question:

* I don't really understand the bug's security implications. Should
  sid's fixed wget be propagated to sarge?
* Does fix all the issues present in the code?

*t

[1] http://www.wolffelaar.nl/~sarge/
[2] http://bugs.debian.org/261755

--
--------------------------------------------------------
  Tomas Pospisek
  http://sourcepole.com -  Linux & Open Source Solutions
--------------------------------------------------------



Information forwarded to debian-bugs-dist@lists.debian.org, Noèl Köthe <noel@debian.org>:
Bug#261755; Package wget. Full text and rfc822 format available.

Acknowledgement sent to Noèl Köthe <noel@debian.org>:
Extra info received and forwarded to list. Copy sent to Noèl Köthe <noel@debian.org>. Full text and rfc822 format available.

Message #70 received at 261755@bugs.debian.org (full text, mbox):

From: Noèl Köthe <noel@debian.org>
To: Tomas Pospisek <tpo@sourcepole.ch>, 261755@bugs.debian.org
Cc: jjminar@fastmail.fm
Subject: Re: Bug#261755: wget sid->sarge
Date: Mon, 27 Sep 2004 16:29:02 +0200
[Message part 1 (text/plain, inline)]
Am Sonntag, den 26.09.2004, 00:26 +0200 schrieb Tomas Pospisek:
> I'm going through the list of packages that are pending to transition from 
> sid->sarge in order to tag them for manual propagation [1]. I've seen that 
> wget in sid fixes a security issue [2] (no sanitizing of server 
> responses). Question:
> 
> * I don't really understand the bug's security implications. Should
>    sid's fixed wget be propagated to sarge?
> * Does fix all the issues present in the code?

it opens this problem: #271931
Thats the reason why I didn't asked for moving it from sid to sarge.
sadly upstream is not available since some weeks to discuss this
problem.:(

-- 
Noèl Köthe <noel debian.org>
Debian GNU/Linux, www.debian.org
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Noèl Köthe <noel@debian.org>:
Bug#261755; Package wget. Full text and rfc822 format available.

Acknowledgement sent to Tomas Pospisek <tpo_deb2@sourcepole.ch>:
Extra info received and forwarded to list. Copy sent to Noèl Köthe <noel@debian.org>. Full text and rfc822 format available.

Message #75 received at 261755@bugs.debian.org (full text, mbox):

From: Tomas Pospisek <tpo_deb2@sourcepole.ch>
To: 261755@bugs.debian.org
Cc: jjminar@fastmail.fm, 271931@bugs.debian.org
Subject: Re: Bug#261755: wget sid->sarge
Date: Mon, 27 Sep 2004 17:19:27 +0200 (CEST)
[Message part 1 (text/plain, inline)]
On Mon, 27 Sep 2004, Noèl Köthe wrote:

> Am Sonntag, den 26.09.2004, 00:26 +0200 schrieb Tomas Pospisek:
>> I'm going through the list of packages that are pending to transition from
>> sid->sarge in order to tag them for manual propagation [1]. I've seen that
>> wget in sid fixes a security issue [2] (no sanitizing of server
>> responses). Question:
>>
>> * I don't really understand the bug's security implications. Should
>>    sid's fixed wget be propagated to sarge?
>> * Does fix all the issues present in the code?
>
> it opens this problem: #271931
> Thats the reason why I didn't asked for moving it from sid to sarge.
> sadly upstream is not available since some weeks to discuss this
> problem.:(

OK, I've put that info into the release helping system [1]. Please update 
it when the problem is fixed or let me know.
*t

[1] I don't know if the following link will work:
    http://www.wolffelaar.nl/~sarge/?PHPSESSID=f957b02aa24b1a4ab9237ae4e80df6a9&package=wget&maint=&outofsync=&frozen=&status=
    Otherwise just visit http://www.wolffelaar.nl/~sarge/,
    enter wget in the first field and press return.

--
--------------------------------------------------------
  Tomas Pospisek
  http://sourcepole.com -  Linux & Open Source Solutions
--------------------------------------------------------

Information forwarded to debian-bugs-dist@lists.debian.org, Noèl Köthe <noel@debian.org>:
Bug#261755; Package wget. Full text and rfc822 format available.

Acknowledgement sent to Jan Minar <jjminar@fastmail.fm>:
Extra info received and forwarded to list. Copy sent to Noèl Köthe <noel@debian.org>. Full text and rfc822 format available.

Message #80 received at 261755@bugs.debian.org (full text, mbox):

From: Jan Minar <jjminar@fastmail.fm>
To: 261755@bugs.debian.org
Cc: 261755-submitter@bugs.debian.org, ismail donmez <kde@myrealbox.com>
Subject: wget: Indiscriminate escaping in multibyte locales patch -- review required
Date: Tue, 28 Sep 2004 21:41:54 +0200
[Message part 1 (text/plain, inline)]
Hi all!

Sorry for not making the patch right the first (or was it second?) time.
And thank Ambrose and Ismail for reporting the bug and commenting upon
it.

I rewrote the patch to be multibyte-aware, please test it and/or review
it.  When I say please review it, I mean it, because the wchar API is
really not my cup of tea, and I probably made silly mistakes and
introduced new and interesting problems.

This new patch introduces no difference in what is printed when ``wget
localhost'' is run, at least under cs_CZ.UTF-8, zh_CN.gb18030,
zh_CN.gb2312, zh_CN.gbk, and ja_JP.eucjp locales.

BTW: Does anybody know why is upstream completely ignoring this issue?

Cheers,
-- 
Jan
[wget-filter-controls.patch.v3--multibyte-aware (text/plain, attachment)]
[Message part 3 (application/pgp-signature, inline)]

Message sent on to Jan Minar <jjminar@fastmail.fm>:
Bug#261755. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Noèl Köthe <noel@debian.org>:
Bug#261755; Package wget. Full text and rfc822 format available.

Acknowledgement sent to Ismail Donmez <kde@myrealbox.com>:
Extra info received and forwarded to list. Copy sent to Noèl Köthe <noel@debian.org>. Full text and rfc822 format available.

Message #88 received at 261755@bugs.debian.org (full text, mbox):

From: Ismail Donmez <kde@myrealbox.com>
To: Jan Minar <jjminar@fastmail.fm>
Cc: 261755@bugs.debian.org, 261755-submitter@bugs.debian.org
Subject: Re: wget: Indiscriminate escaping in multibyte locales patch -- review required
Date: Wed, 29 Sep 2004 19:02:09 +0300
On Tuesday 28 September 2004 22:41, Jan Minar wrote:
> Hi all!
>
> Sorry for not making the patch right the first (or was it second?) time.
> And thank Ambrose and Ismail for reporting the bug and commenting upon
> it.
>
> I rewrote the patch to be multibyte-aware, please test it and/or review
> it.  When I say please review it, I mean it, because the wchar API is
> really not my cup of tea, and I probably made silly mistakes and
> introduced new and interesting problems.
>
> This new patch introduces no difference in what is printed when ``wget
> localhost'' is run, at least under cs_CZ.UTF-8, zh_CN.gb18030,
> zh_CN.gb2312, zh_CN.gbk, and ja_JP.eucjp locales.
>
> BTW: Does anybody know why is upstream completely ignoring this issue?


Tested with LC_ALL=tr_TR.UTF-8 and works fine for me. Thanks for the fix!

Regards,
ismail



Message sent on to Jan Minar <jjminar@fastmail.fm>:
Bug#261755. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Noèl Köthe <noel@debian.org>:
Bug#261755; Package wget. Full text and rfc822 format available.

Acknowledgement sent to Andreas Barth <aba@not.so.argh.org>:
Extra info received and forwarded to list. Copy sent to Noèl Köthe <noel@debian.org>. Full text and rfc822 format available.

Message #96 received at 261755@bugs.debian.org (full text, mbox):

From: Andreas Barth <aba@not.so.argh.org>
To: 284875@bugs.debian.org, 261755@bugs.debian.org
Subject: wget - solving strategies
Date: Tue, 4 Jan 2005 22:03:27 +0100
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



Bug reopened, originator not changed. Request was from Andreas Barth <aba@not.so.argh.org> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Noèl Köthe <noel@debian.org>:
Bug#261755; Package wget. Full text and rfc822 format available.

Acknowledgement sent to Hrvoje Niksic <hniksic@xemacs.org>:
Extra info received and forwarded to list. Copy sent to Noèl Köthe <noel@debian.org>. Full text and rfc822 format available.

Message #103 received at 261755@bugs.debian.org (full text, mbox):

From: Hrvoje Niksic <hniksic@xemacs.org>
To: 261755@bugs.debian.org
Subject: wget: Server responses &c written to the tty verbatim (escape sequences, control characters, ...)
Date: Thu, 05 May 2005 16:04:03 +0200
This bug has been fixed in CVS.  Wget filters escape sequences when
printing untrusted strings (those coming from the remote server).

Newlines and TABs are escaped, which makes it much harder to mimic
Wget's output, at least without knowing the exact width of the
terminal.



Reply sent to Noèl Köthe <noel@debian.org>:
You have taken responsibility. Full text and rfc822 format available.

Notification sent to Jan Minar <jjminar@fastmail.fm>:
Bug acknowledged by developer. Full text and rfc822 format available.

Message #108 received at 261755-close@bugs.debian.org (full text, mbox):

From: Noèl Köthe <noel@debian.org>
To: 261755-close@bugs.debian.org
Subject: Bug#261755: fixed in wget 1.9.1-11
Date: Thu, 05 May 2005 17:03:19 -0400
Source: wget
Source-Version: 1.9.1-11

We believe that the bug you reported is fixed in the latest version of
wget, which is due to be installed in the Debian FTP archive:

wget_1.9.1-11.diff.gz
  to pool/main/w/wget/wget_1.9.1-11.diff.gz
wget_1.9.1-11.dsc
  to pool/main/w/wget/wget_1.9.1-11.dsc
wget_1.9.1-11_i386.deb
  to pool/main/w/wget/wget_1.9.1-11_i386.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 261755@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Noèl Köthe <noel@debian.org> (supplier of updated wget package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


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

Format: 1.7
Date: Thu, 05 May 2005 22:58:58 +0200
Source: wget
Binary: wget
Architecture: source i386
Version: 1.9.1-11
Distribution: unstable
Urgency: high
Maintainer: Noèl Köthe <noel@debian.org>
Changed-By: Noèl Köthe <noel@debian.org>
Description: 
 wget       - retrieves files from the web
Closes: 261755 284875 305425
Changes: 
 wget (1.9.1-11) unstable; urgency=high
 .
   * going back to -8 status to have minimal changes to current
     sarge version
   * backported fixes from Hrvoje Niksic/upstream from wget 1.10
     cvs version (thanks alot Hrvoje Niksic!):
     - adds the filtering of control chars
       (closes: Bug#261755)
     - prevents hosts named ".." from writing to ../. and
       prevents "%00" truncating C strings that hold URLs
       (closes: Bug#284875)
   * removed unneeded texi2html build-dep
     (closes: Bug#305425)
Files: 
 ba4c07b0f2a9981892537cafd67db973 587 web optional wget_1.9.1-11.dsc
 1421b183f36da51ee3d39377cfae5db5 17197 web optional wget_1.9.1-11.diff.gz
 f200df94d7cb8dc369bcd973d0576ae8 425918 web optional wget_1.9.1-11_i386.deb

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

iD8DBQFCeoQl9/DnDzB9Vu0RAgNiAJ4w+fXh7GnvM9l6ofVryTol22RyTQCeJjGc
ulkXZX2xdW1kUlublPyy0sg=
=868g
-----END PGP SIGNATURE-----




Bug reopened, originator not changed. Request was from Frank Lichtenheld <djpig@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Tags added: sarge Request was from Frank Lichtenheld <djpig@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Bug closed, send any further explanations to Jan Minar <jjminar@fastmail.fm> Request was from Frank Lichtenheld <djpig@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Tags removed: sarge Request was from Frank Lichtenheld <djpig@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Fri Apr 25 09:27:41 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.