[Interchange-announce] Interchange security releases: 5.7.2, 5.6.2, 5.4.4

[Jon Jensen]

Today we are releasing three new versions of Interchange:

* Interchange 5.7.2 is the latest development version representing 10 
months of improvements and an impressive list of new features to improve 
developer efficiency and fix bugs.

* Interchange 5.6.2 is the latest stable version which includes the most 
important changes backported to provide the most stability possible for 
those upgrading from versions 5.6.0 or 5.6.1.

* Interchange 5.4.4 is an update of the previous stable series of releases 
provided only to fix a serious security problem.

All three releases provide a new security feature to close a serious 
security vulnerability which we will describe here in detail:

A remotely exploitable security vulnerability has been discovered where
any table configured within Interchange could be viewed remotely by an
unauthenticated user, by using a specially crafted search request.

This vulnerability affects all previous versions of Interchange. Even
without using the search structure provided in the default install, your
catalog could still be vulnerable.

To protect against exploits, we strongly recommend all public Interchange 
sites upgrade and use the new configuration directive AllowRemoteSearch.

AllowRemoteSearch limits what database tables are remotely searchable and 
should be specified in each catalog configuration. It defaults 
to:

     AllowRemoteSearch products variants options

Any table specified in this option will be remotely searchable, and you 
should not permit any table with sensitive information to be searched in 
this way. You should carefully consider the implications of adding any 
further tables to this configuration option.

Remote searches may have been used by your existing catalog. These should 
continue working without any changes as long as they only search tables 
that are permitted by the AllowRemoteSearch directive. You should 
carefully examine your catalog for uses of the search form action, or 
pages which submit a form to a page called search or scan. If they specify 
a search file other than products, variants, or options, you should 
consider rewriting that page to just accept the search terms via CGI 
parameters, and not the entire search. Please consult the documentation on 
in-page searches:

http://www.icdevgroup.org/doc/icdatabase.html#In-Page%20Searches

If your catalog makes use of ActionMaps that perform searches, these 
should continue to work as intended as long as they search a table allowed 
by AllowRemoteSearch. However, you should consider updating them to use 
the new "search" tag. For example, an existing ActionMap that performs a 
search like this:

     ActionMap old_cat <<EOR
     sub {
          my ($action, $class) = split('/', shift);

          $class =~ s/_/ /g;

          # Originally, search parameters were placed in the CGI hash.
          $CGI->{co} = 1;
          $CGI->{fi} = 'products';
          $CGI->{st} = 'db';
          $CGI->{sf} = 'category';
          $CGI->{se} = "$class";
          $CGI->{sp} = 'results';
          $CGI->{tf} = 'category,description:f';
          $CGI->{op} = 'eq';

          $CGI->{mv_todo} = 'search';
          $CGI->{mv_nextpage} = 'results';
          # And the "update" tag was called to re-evaluate the page with
          # the provided search parameters.
          $Tag->update('process');
          return 1;
     }
     EOR

Would be updated to instead look like this:

     ActionMap new_cat <<EOR
     sub {
          my ($action, $class) = split('/', shift);

          $class =~ s/_/ /g;

          # Now, you must create a hash to hold the search parameters.
          my $search;
          $search->{co} = 1;
          $search->{fi} = 'products';
          $search->{st} = 'db';
          $search->{sf} = 'category';
          $search->{se} = "$class";
          $search->{sp} = 'results';
          $search->{tf} = 'category,description:f';
          $search->{op} = "eq";

          $CGI->{mv_nextpage} = 'results';
          # And call the new search tag, which isn't subject to the
          # AllowRemoteSearch restrictions.
          $Tag->search({ search => $search });

          return 1;
     }
     EOR

If you are using a modern version of the standard catalog as the basis
for your catalog, there is a special subroutine that provides friendly
URLs for product categories, but is not a traditional ActionMap. Similar
to the example above, you will need to alter your catalog.cfg, replacing
the entire Sub ncheck_category with:

Sub ncheck_category <<EOS
sub {
     my ($name) = @_;
     return unless $name =~ m{^[A-Z]};
     $name =~ s,_, ,g;
     my ($prod_group, $category) = split m{/}, $name;

     my $search;
     $search->{co} = 1;
     $search->{fi} = 'products';
     $search->{st} = 'db';
     $search->{sf} = join "\0", 'prod_group', 'category';
     $search->{op} = join "\0", 'eq', 'eq';
     $search->{se} = join "\0", $prod_group, $category;
     $search->{sp} = 'results';
     $search->{mv_todo} = 'search';
     $Tag->search({ search => $search });
     if (($o = $Search->{''}) && @{$o->{mv_results}}) {
         return (1,  $Config->{Special}->{results});
     }

     return;
}
EOS

In the standard and foundation catalogs, the "lost password" feature makes
use of the remote search feature to be able to retrieve lost passwords. We
recommend that you delete catalog/pages/query/get_password.html from your
catalog, and replace catalog/pages/query/lost_password.html with an
updated version from one of these new releases. As an alternative, you may
apply the following patch to your existing file:

--- a/dist/standard/pages/query/get_password.html
+++ b/dist/standard/pages/query/get_password.html
@@ -32,8 +32,10 @@ ui_template_name: leftonly
         if( $Scratch->{tried_pw_retrieve}++ > 10 ) {
                 return "No way, Jos&eacute;. Too many times.";
         }
      $CGI->{mv_todo} = 'search';
         $Config->{NoSearch} = '';
+       push(@{$Config->{AllowRemoteSearch}},'userdb');
+       return;
  [/perl]
  [update process]
  [search-region]

This is not a recommended solution, and is only a workaround until you can
consider the changes in the updated lost password page.

We thank Mark Lipscombe for finding and fixing this vulnerability and for 
his other contributions to these releases.

The software and more detailed change logs are available here:

http://ftp.icdevgroup.org/interchange/

SHA1 hashes of the release files:

4975ab7779d52347aba571681e0238c3ef923136  interchange-5.7.2.tar.bz2
dd5c46e3047f6c57495263b265615c0814d0416d  interchange-5.7.2.tar.gz

e64cdb2317c6c7d5cfe01cddcda0c6a4c9e070d2  interchange-5.6.2.tar.bz2
ced5a8b8c6821456cef76ca0d45e635853fc1757  interchange-5.6.2.tar.gz

49fb93c90e7b9705b7484f6e64f443600956dbf8  interchange-5.4.4.tar.bz2
bc0978607242db6685d12bb6f2227054f072d707  interchange-5.4.4.tar.gz

Detached PGP signatures signed by my key (id DCCAC084) are alongside
each file for download and verification.

Further information and links to documentation and the user discussion
mailing list are at:

http://www.icdevgroup.org/

Jon Jensen
Interchange Development Group