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

Curt Hauge ic_support at mnwebdesign.com
Sun Sep 20 15:45:34 UTC 2009


hello

Curt Hauge
Office 763-689-4984
Cell   612-598-5530
www.IWantAConsultant.com
www.MNWebDesign.com

> -----Original Message-----
> From: interchange-users-bounces at icdevgroup.org
> [mailto:interchange-users-bounces at icdevgroup.org]On Behalf Of Jon Jensen
> Sent: Thursday, September 17, 2009 5:02 PM
> To: interchange-announce at icdevgroup.org;
> interchange-users at icdevgroup.org
> 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&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
>
> _______________________________________________
> interchange-users mailing list
> interchange-users at icdevgroup.org
> http://www.icdevgroup.org/mailman/listinfo/interchange-users




More information about the interchange-users mailing list