Vulnerability

    web_store.cgi

Affected

    eXtropia WebStore (web_store.cgi)

Description

    'f0bic' found following.  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.

    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.

    Author of  program does  not believe  this is  a vulnerability  in
    their 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  You'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.