[ic] Interchange security releases: 5.7.2, 5.6.2, 5.4.4

[Grant]

> 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

I hope replying here is alright.  I'm trying to figure out if I'm
vulnerable to this.  I don't use [search-region] or ActionMap at all.
Does that exclude me?

- Grant