[17127] in bugtraq
Re: Security Advisory : eXtropia WebStore (web_store.cgi)
daemon@ATHENA.MIT.EDU (Gunther Birznieks)
Tue Oct 10 12:14:20 2000
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-Id: <5.0.0.25.2.20001010102114.00a8a348@mail.clark.net>
Date: Tue, 10 Oct 2000 10:36:32 +0800
Reply-To: Gunther Birznieks <gunther@EXTROPIA.COM>
From: Gunther Birznieks <gunther@EXTROPIA.COM>
X-To: f0bic@deadprotocol.org
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <00100903470700.03249@ninja>
I have to say that I am a bit upset about this post for several reasons.
1) I do not believe this is a vulnerability in our current web store
release and hasn't been for quite a long time.
eg the subroutine you cite as having a problem: error_check_form_data() is
actually called AFTER I've gone through an untainting procedure on the page
which explicitly only allows
word chars (\w), -, =, +, / plus one and only one period followed by one or
more word characters (\w+). Then $page is reassigned to $1.$2, so that if
any null byte existed afterwards, then this would be stripped out of the $page.
In other words, I find it difficult to believe this is a currently problem
based on the information you posted. At best you can only say that this was
a problem maybe 2 years ago. Old news -- we already posted to all our users
that we put security fixes for this back then.
2) Even if this is a vulnerability, you did not notify eXtropia before
posting this!
If you search the past posts here, you will see that it is irresponsible
for you to be posting vulnerabilties without notifying the vendor first.
a) You risk spreading misinformation and causing extra work for people
checking vulnerabilities where none exist. As stated in #1, I believe this
is the case here.
b) You don't know the script very well. The vendor does. If you have a
security vulnerability report to make, you should ask the vendor whether
your fix is actually valid.
I don't care if you are a genius IQ, nobody but the person who coded the
script tends to know it best. Just because you find a vulnerability does
not mean that you know how to solve it in the best and most efficient way
possible nor that you know the side effects such a fix might make to the
rest of the programs operation.
c) You are informing hackers of a vulnerability in a product way before the
users of that product! That's irresponsible. You need to give the vendor
the chance (if only a DAY!!!) to fix the problem and notify all their users.
Most users of free CGI scripts are normal business people and part-time
webmasters -- they don't subscribe to lists such as these because they are
way too technical and contain too much traffic for them to decipher.
All you succeed in doing here is telling the intellectuals who read this
list (many of whom may be hackers themselves) how to hack into someone
else's system. Only the vendor has the customer list of who is using their
scripts or applications, so only the vendor can really notify the users.
Anyway, I am really glad that there are people like you who take the time
to figure out security vulnerabilities. But please temper your special gift
with some responsibility for the community at large.
:)
Thanks,
Gunther
At 03:45 AM 10/9/2000 -0400, f0bic wrote:
>[ October 9, 2000 ]
>
>
>Security Advisory (web_store.cgi.ad-1.00-10) : eXtropia WebStore
>(web_store.cgi) Directory Traversal Vulnerability
>
>
>
>
>Affected Product/Version:
>
> * eXtropia WebStore (web_store.cgi/html_web_store.cgi)
>
>
>Affected Platforms:
>
> * Unix
> * Windows
>
>
>Overview:
>
> The Web Store is a shopping cart product by eXtropia. This script
> merges Selena Sol's Electronic Outlet HTML
> and Database shopping cart apps and adds all new routines for
> error handling, order processing, encrypted mailing,
> frames, Javascript and VBscript.
>
>
>Description:
>
> The Web Store is made up of a variety of scripts, of which one is
> the main routine, web_store.cgi. The $page variable,
> lets you display product/shopping html files. web_store.cgi
> checks for the file extension of the $page input, it has
> to be ended by a .html extension. In other words,
> http://example.com/cgi-bin/Web_Store/web_store.cgi?page=page.html,
> would open page.html in the browser. It checks for the .html
> extension like so:
>
> sub error_check_form_data
> {
> foreach $file_extension
> (@acceptable_file_extensions_to_display)
> {
> if ($page =~ /$file_extension/ || $page eq "")
> {
> $valid_extension = "yes";
> }
> }
>
> The open() call is displayed here:
>
> sub display_page
> {
> local ($page, $routine, $file, $line) = @_;
>
> # the subroutine begins by opening the requested file for
> # reading, exiting with file_open_error if there is a
> # problem as usual.
>
> open (PAGE, "<$page") ||
> &file_open_error("$page", "$routine", $file, $line);
>
>
> Taking this information into account, if you would want to open
> the /etc/inetd.conf file, a request for
>
>http://example.com/cgi-bin/Web_Store/web_store.cgi??page=../../../../../../../../etc/inetd.conf
>would fail since it
> does not fullfill the $file_extension check. This problem can be
> bypassed by using a NULL (%00) character that by
> perl is seen as a character, but by the underlaying language is
> interpreted as a \0 escape sequence character.
> All the characters following the %00 will be ignored and so the
> file can be opened in the following manner:
>
>http://example.com/cgi-bin/Web_store/web_store.cgi?page=../../../../../../../../etc/inetd.conf%00.html
> This will result in opening the /etc/inetd.conf file. In this
> manner, arbitrary files could be read.
>
>
>Solution:
>
> By the use of regex you could add better input validation
> checking that prevents double dot strings from being passed
> through the open() call.
>
>
>Resources & References:
>
> * eXtropia's Webpage: http://www.extropia.com
>
>
>---------------------------------
>by f0bic (f0bic@deadprotocol.org)
>zSh - http://zsh.interniq.org
__________________________________________________
Gunther Birznieks (gunther.birznieks@extropia.com)
eXtropia - The Web Technology Company
http://www.extropia.com/
