Bug#281655: info2www: Cross-site scripting vulnerability

2005-01-30 Thread Uwe Hermann 
Hi,

On Sun, Jan 23, 2005 at 08:28:47PM -0500, Justin Pryzby wrote:
 On Sun, Jan 23, 2005 at 05:42:04PM -0500, pryzbyj wrote:
  tags 281655 patch
  thanks
  
  I've included a 2-line patch which implements some output
  sanitization.  I can't find any other instance where this is a
  problem, but don't take my word for it; I haven't followed the code
  *that* closely.
  
  Since info filenames/titles can be named anything (which is a Good
  Thing), the way to handle this is to escape '' (and '' while we're
  at it).  This prevents anyone from sticking any html anywhere.
  
  I would also like to see this code use perl -T (for testing, as well
  as for installation, I think).  I will probably play with this later
  tonight.
  
  I've never used perl -T before and it may very well break this program
  horribly.
 It broke it, but not horribly.  The only complain (check apache's
 error log) is about $ENV{'PATH'}.  The Debian fix is to just set
 $ENV{'PATH'}=/bin:/usr/bin (or even just leave it untouched, maybe).
 
 So, in addition to the previous patch, I suggest that the script runs
 with #!/usr/bin/perl -T, and that the ENV variable is either set
 absolutely, or not changed at all.

Thanks Justin for all the help and patches.

I implemented most of your suggestions and some additional ones in a new
patch (attached to this mail).
Unfortunately, I don't think escaping '' and '' will suffice. IIRC
there exist XSS exploits which don't use special characters at all, so
it's quite hard to filter...

But IMHO what we have now is a first good step. I'm CC'ing the security
team (this was long overdue), maybe they have some more suggestions.

If noone objects I'll upload a new info2www package with the attached
patch to unstable. The security announce and uploads to stable will be
handled by the security team, right?


Thanks, Uwe.
-- 
Uwe Hermann [EMAIL PROTECTED]
http://www.hermann-uwe.de | http://www.crazy-hacks.org
http://www.it-services-uh.de  | http://www.phpmeat.org
http://www.unmaintained-free-software.org | http://www.holsham-traders.de
--- info2www2005-01-30 21:06:37.0 +0100
+++ info2www.new2005-01-31 05:02:03.0 +0100
@@ -1,4 +1,4 @@
-#!/usr/bin/perl
+#!/usr/bin/perl -T
 #
 # info2www - Gateway between GNU Info nodes and WWW
 $id = '$Id: info2www,v 1.2.2.9 1996/07/02 08:44:12 lmdrsm Exp $ ';
@@ -82,8 +82,11 @@
 # Set the PATH so that the ZCAT and GZCAT programs can be found
 #
 
-$ENV{'PATH'} =~ s!:$!!;
-$ENV{'PATH'} .= :/bin:/usr/bin;
+#$ENV{'PATH'} =~ s!:$!!;
+#$ENV{'PATH'} .= :/bin:/usr/bin;
+
+# Security: Hardcoded paths, so malicious tampering with PATH is not possible.
+$ENV{'PATH'} = /bin:/usr/bin;
 
 #
 # ZCAT is the program to use for reading compressed files (*.Z)
@@ -1138,6 +1141,15 @@
 # Print an HTML error message
 sub Error {
 local($reason) = @_;
+
+# Security checks to prevent at least _some_ forms of XSS attacks.
+# TODO: This is far from complete, more checks need to be done!
+$reason =~ s//lt;/gs;
+$reason =~ s//gt;/gs;
+$reason =~ s//amp;/gs;
+$reason =~ s//quot;/gs;
+$reason =~ s/#//gs;
+
 print STRONGSorry! - $reason/STRONG\nP\n;
 return(0);
 }

Bug#281655: info2www: Cross-site scripting vulnerability

2005-01-23 Thread Uwe Hermann 
Hi,

sorry, the mail about this bug somehow got lost in my inbox...

(CC to debian-devel, any help with this issue is welcome)


On Wed, Nov 17, 2004 at 03:45:55AM +0100, Nicolas Gregoire wrote:
 Package: info2www
 Version: 1.2.2.9-22
 Severity: normal
 Tags: security
 
 There's a XSS vulnerabilty in the info2www CGI.
 
 The following URL will display the document location using Javascript :
 /cgi-bin/info2www?(coreutils)scriptalert(document.location)script

Hm, seems like I can't reproduce this. If I enter the above URL in a
browser (I tried Galeon and Firefox) I get:

Sorry! - Couldn't find target: alert(document.location) in file
coreutils.

No document location is revealed and the rest of the page is shown as
usual... Can you provide another example and/or tell me what I did wrong?

Also, I checked not only my local install but also some info2www
installations on the internet (found using Google), they reveal the same
behaviour.


 Every user-supplied parameter should be sanitized before use.

ACK, I'll try to check the code, but it won't be easy I guess. The code
is from 1996, unmaintained and quite surely contains lots more security
issues.

Any help and/or patches are really welcome!

Uwe.
-- 
Uwe Hermann [EMAIL PROTECTED]
http://www.hermann-uwe.de | http://www.crazy-hacks.org
http://www.it-services-uh.de  | http://www.phpmeat.org
http://www.unmaintained-free-software.org | http://www.holsham-traders.de


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#281655: info2www: Cross-site scripting vulnerability

2005-01-23 Thread Justin Pryzby 
On Sun, Jan 23, 2005 at 05:12:15PM +0100, Uwe Hermann wrote:
 Hi,
 
 sorry, the mail about this bug somehow got lost in my inbox...
 
 (CC to debian-devel, any help with this issue is welcome)
 
 
 On Wed, Nov 17, 2004 at 03:45:55AM +0100, Nicolas Gregoire wrote:
  Package: info2www
  Version: 1.2.2.9-22
  Severity: normal
  Tags: security
  
  There's a XSS vulnerabilty in the info2www CGI.
  
  The following URL will display the document location using Javascript :
  /cgi-bin/info2www?(coreutils)scriptalert(document.location)script
 
I anticipate that its supposed to be /script

I'm not sure I understand the problem, though; what's wrong with
displaying the document location (though its a bug and should be
fixed, I don't see why its a security issue.  Isn't the document
location the thing that's already going to be in the address bar?)

  Every user-supplied parameter should be sanitized before use.
 
 ACK, I'll try to check the code, but it won't be easy I guess. The code
 is from 1996, unmaintained and quite surely contains lots more security
 issues.
 
 Any help and/or patches are really welcome!
I can try to help, but I guess I have to undertand the problem first:)

Justin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#281655: info2www: Cross-site scripting vulnerability

2005-01-23 Thread Justin Pryzby 
tags 281655 patch
thanks

I've included a 2-line patch which implements some output
sanitization.  I can't find any other instance where this is a
problem, but don't take my word for it; I haven't followed the code
*that* closely.

Since info filenames/titles can be named anything (which is a Good
Thing), the way to handle this is to escape '' (and '' while we're
at it).  This prevents anyone from sticking any html anywhere.

I would also like to see this code use perl -T (for testing, as well
as for installation, I think).  I will probably play with this later
tonight.

I've never used perl -T before and it may very well break this program
horribly.

Justin

On Sun, Jan 23, 2005 at 11:56:50AM -0500, pryzbyj wrote:
 On Sun, Jan 23, 2005 at 05:12:15PM +0100, Uwe Hermann wrote:
  Hi,
  
  sorry, the mail about this bug somehow got lost in my inbox...
  
  (CC to debian-devel, any help with this issue is welcome)
  
  
  On Wed, Nov 17, 2004 at 03:45:55AM +0100, Nicolas Gregoire wrote:
   Package: info2www
   Version: 1.2.2.9-22
   Severity: normal
   Tags: security
   
   There's a XSS vulnerabilty in the info2www CGI.
   
   The following URL will display the document location using Javascript :
   /cgi-bin/info2www?(coreutils)scriptalert(document.location)script
  
  Hm, seems like I can't reproduce this. If I enter the above URL in a
  browser (I tried Galeon and Firefox) I get:
 If I change it to /script then I can reproduce the alleged problem.  I
 guess I don't understand XSS vulnerabilities...  The whole point is
 that mallicious Mallory can post a link to nonmallicious site
 nice.com/cgi-bin/info2wwwscriptalert(Boo!)/script?  That still
 seems like a nonissue, because Mallory could just as easily have put
 an alert() on his own page (okay, maybe if mallory's page is in a
 mallicious list, and nice.com is in a trusted list it makes
 sense).
 
   Every user-supplied parameter should be sanitized before use.
  
  ACK, I'll try to check the code, but it won't be easy I guess. The code
  is from 1996, unmaintained and quite surely contains lots more security
  issues.
 This shouldn't be difficult, really.  The only user input comes from
 the URL, and it should probably be restricted to certain character
 ranges [a-z0-9-] or something.
--- info2www2005-01-23 17:38:28.0 -0500
+++ /tmp/info2www.patch 2005-01-23 17:39:52.0 -0500
@@ -1138,8 +1138,6 @@
 # Print an HTML error message
 sub Error {
 local($reason) = @_;
-$reason=~s//lt;/gs;
-$reason=~s//gt;/gs;
 print STRONGSorry! - $reason/STRONG\nP\n;
 return(0);
 }

Bug#281655: info2www: Cross-site scripting vulnerability

2005-01-23 Thread Justin Pryzby 
On Sun, Jan 23, 2005 at 05:42:04PM -0500, pryzbyj wrote:
 tags 281655 patch
 thanks
 
 I've included a 2-line patch which implements some output
 sanitization.  I can't find any other instance where this is a
 problem, but don't take my word for it; I haven't followed the code
 *that* closely.
 
 Since info filenames/titles can be named anything (which is a Good
 Thing), the way to handle this is to escape '' (and '' while we're
 at it).  This prevents anyone from sticking any html anywhere.
 
 I would also like to see this code use perl -T (for testing, as well
 as for installation, I think).  I will probably play with this later
 tonight.
 
 I've never used perl -T before and it may very well break this program
 horribly.
It broke it, but not horribly.  The only complain (check apache's
error log) is about $ENV{'PATH'}.  The Debian fix is to just set
$ENV{'PATH'}=/bin:/usr/bin (or even just leave it untouched, maybe).

So, in addition to the previous patch, I suggest that the script runs
with #!/usr/bin/perl -T, and that the ENV variable is either set
absolutely, or not changed at all.

 Justin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]