ic_support at mnwebdesign
Sep 20, 2009, 9:58 AM
Post #8 of 25
(2724 views)
Permalink
|
|
Re: Interchange security releases: 5.7.2, 5.6.2, 5.4.4
[In reply to]
|
|
I apologize for that outburst, it was meant to be a test reply to another
email.
Curt
> -----Original Message-----
> From: interchange-users-bounces [at] icdevgroup
> [mailto:interchange-users-bounces [at] icdevgroup]On Behalf Of Curt Hauge
> Sent: Sunday, September 20, 2009 10:46 AM
> To: interchange-users [at] icdevgroup
> Subject: Re: [ic] Interchange security releases: 5.7.2, 5.6.2, 5.4.4
>
>
> hello
>
>
> > -----Original Message-----
> > From: interchange-users-bounces [at] icdevgroup
> > [mailto:interchange-users-bounces [at] icdevgroup]On Behalf Of Jon Jensen
> > Sent: Thursday, September 17, 2009 5:02 PM
> > To: interchange-announce [at] icdevgroup;
> > interchange-users [at] icdevgroup
> > Subject: [ic] Interchange security releases: 5.7.2, 5.6.2, 5.4.4
> >
> >
> > 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é. 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
> >
> > _______________________________________________
> > interchange-users mailing list
> > interchange-users [at] icdevgroup
> > http://www.icdevgroup.org/mailman/listinfo/interchange-users
>
>
> _______________________________________________
> interchange-users mailing list
> interchange-users [at] icdevgroup
> http://www.icdevgroup.org/mailman/listinfo/interchange-users
_______________________________________________
interchange-users mailing list
interchange-users [at] icdevgroup
http://www.icdevgroup.org/mailman/listinfo/interchange-users
|
