Re: CGI: Selena Sol's WebBanner ( Random Banner Generator ) Vulnerability

[gunther () EXTROPIA COM (Gunther Birznieks)]

Ron,

I appreciate you doublechecking it.

I just want to confirm that there was a version of Random Banner that did
not have the particular snippet of code that you list for stopping the
problem. Those people should download the new version -- it is definitely a
security problem.

It occurred as we had a mixup on the versions we had put out to the public.

Although our polls indicate very few people actually use random_banner,
after the bugtraq list mailing, we have also taken action to send a short
and sweet email about it to the thousands on our general scripts mailing
list to make sure that they are aware and should check their versions so
that they may download them immediately should they have a broken one.

I have to say that it would have been a bit easier if someone had emailed
us first about the intent to post on this mailing list so that the effort
to squash this security problem could have been a bit more coordinated. But
there's always next time (not that I am wishing for one). :)

I could only see 2 issues with the fix that Johanne posted:

1) The parsing of the form variables is redundant because cgi-lib.pl does
it already.
2) Although it is useful to catch a pipe meta character within the regex to
catch someone trying something funky, I prefer to fix the root of the
problem which is to change the open statements from

open (FILE, "$file"); to open (FILE, "<$file"); When the < is in front,
perl ignores any | so even if a pipe got through for whatever reason, Perl
would still ignore it.

3) I think your comment about the CgiDie() is warranted to some degree.

If a black hat has the capability of redirecting then they'll surely have
to redirect with the javascript code inside the redirect signal itself.

And if they have that capability, they could have printed out the screwy
HTML themselves.

I am not saying that it is not something to fix, but I am curious about the
extent of the issue. In the case of traditional CSS problem, I thought that
the biggest security problem lies when one user can post HTML to a script
and have that malicious posting maintain persistence when another,
innocent, user goes to read the message.

--

BTW, I am a bit disturbed that, again, if there was a feeling that there is
a problem you would like fixed in RandomBanner then why did you not email
us DIRECTLY first or in parallel to the BUGTRAQ list.

The fact is, if there is something that is a serious exploit, I DO want it
posted to this list! But I think it is not efficient to post it to this
list ahead of giving us even one day to produce a fix for anything you feel
is a problem.

Note that I am not for hiding problems -- I still would definitely include
a bugtraq mailing as part of the solution. HOWEVER, telling the vendor
FIRST is better for the users.

This is better for the users because it allows us to fix the problem
properly (You can talk to us about the problem as a dialogue) when your fix
may be based on speculation of what the quickest LOCAL fix is in the code.
And second, telling us first additionally allows us to warn our users on
our mailing list in PARALLEL to bugtraq rather than AFTER bugtraq.

The reality is that VERY few people who really are USERS of scripts such as
RandomBanner are on this mailing list because the audience here is techie.

By posting to a list of users who are less likely to be the actual users of
the product, you are alerting the entire world to an exploit that we have a
greater duty to target a parallel email to the people that actually USE
this stuff -- not the people where a small percentage may say "Oh cool, let
me try hacking XYZ site that I think is using ABC product".

The reason I bring this up is that I find it odd that both you and Johannes
felt the urge to post issues with our products immediately to this list
first before attempting to email us.

I am not saying it is wrong to post to this list. But I think if your
intent is to help the real users who use this stuff, it is not the most
prudent thing to post to this list as the first course of events. Of
course, if the vendor is unresponsive, I can understand posting here anyway.

But I am speaking as a vendor that does respond to our emails and
especially we take security alerts extremely seriously. So we'd like to be
given the chance to respond in the best way possible. :)

At 03:00 PM 6/16/00 -0500, Ron Parker wrote:
> At 08:55 AM 6/13/2000 +0200, Johannes Westerink wrote:
> >        Application Name: WebBanner (Random Banner Generator)
> >     Application Authors: Eric Tachibana (Selena Sol) and Gunther Birznieks
> >                 Version: 4.0
> >           Last Modified: 17NOV98
> >                    Site: http://www.extropia.com
>
> [...]
>
> There's code in the script that's supposed to stop this exploit.  It'd
> probably
> be better to fix that instead, assuming it's actually broken.  Did you
> actually
> test this exploit against a running installation, or is this advisory based
> solely on static analysis?
>
> ------- snippet from earlier in the WebBanner script ----------
>     # If they try to go outside the directory kill the program
>     if ($form_data{'html_file'} =~ /\.\\?\./ ||
>         $form_data{'html_file'} !~ /\.htm.?$/i) {
>         $form_data{'html_file'} = "";
>         exit(0);
>     }
> ------- end snippet ---------
>
>
> >                       &CgiDie ( "I'm sorry, but I was unable to open
> the requested
> >       HTML file in the Insert Random Banner Into Page routine.  The
> >        value I have is $html_file.  Would you please check the path and
> >        the permissions for the file." );
>
> This isn't safe, and it's also in the original WebBanner script.  Note that
> CgiDie
> outputs the error message *to the user*.  Imagine what happens when some
> black hat
> redirects their users to your script with suitable javascript in place of
> html_file
> (making sure to avoid the .. or .\. sequence of characters, and to end it
> with .htm.)
> See http://www.cert.org/advisories/CA-2000-02.html for more details on this
> common
> problem.  Also note that this does not appear to be the only instance of
> this problem
> in the WebBanner script.
>
> --
> Ron Parker
> GW Micro, Inc.
> Voice 219-489-3671
> Fax 219-489-2608