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