Google Web Accelerator -- Much ado about caching

Google's new Web Accelerator beta is raising a surprising number of
concerns in, and around, the security community. For example, reader
Matthew S. writes in with the following reccomendation that he has made
to his boss regarding this new tool:

        "I think the security and privacy concerns with this software are

huge, and our users should not install it.



        "It caches your cookies with Google servers. People using the

Accelerator are reporting that when they access a user-specific web site

they sometimes appear logged in as another user, in other words, Google is

accessing the site with someone else's cookie. Anything you access over http

(not https) is fair game to be cached either in your browser or Google's

servers.



        "The pre-fetching is indiscriminate - a link on the page you're

visiting that says "delete", for example, is fair game. This can cause

havoc with poorly-written web apps (most web apps, in other words),

because it's not an anonymous spider clicking links, it's a session

with an authorized cookie.



        "Use of this browser plug-in in its current state could increase

the risk of information disclosure through our public web apps. It's not

clear at this time if the tool will also share pre-fetched information

from internal web sites with Google, but that is a possibility."

Some of the concerns being raised are, in my opinion, premature. Certainly,
the ability to access the session of another user is troubling, but it is
also nothing new. These problems have plauged sites with proxy-caches for
years, but the affected community was much smaller. These are simple bugs
in caching systems, and will undoubtably be fixed by Google like those
before them.



Link prefetching causing destructive behavior on "poorly-written web apps"
is likely to be a much harder nut to crack for Google, but I don't expect
that this will be a wide-spread disaster either; there are many hidden
cues within most html documents that suggest links that are part of a
menuing system.



However, I am personally concerned about the longer term effects of
Google having access to every users' entire browsing session, as well as
the effects it will have on site administrators in terms of access control
and statistics gathering, and discussions have already been started on
how to combat this global proxy, mostly by blocking IP ranges.




http://www.searchenginejournal.com/index.php?p=1676
http://fantomaster.com/fantomNews/archives/2005/05/06/banning-google-web-accelerator-text-and-graphics/




IP blocking is a rather crude answer to this issue, and I'd be very
interested to see if there were a more elegant solution based upon
identifying characteristics in the proxied requests, as one cannot
expect the IP ranges to stay constant if this becomes a popular service.




Furthermore, there are a number of potentially troublesome issues
involved in having a giant global proxy-cache service available.
In the short term, GWA is likely to be useful in breaking through
restrictive corporate filtering proxies, which I expect to see
solved quickly. However, if GWA happens to become a popular
service, we can expect to see it used as a "poor-man's Akamai",
which has a number of worrying implications for phishing scams
and malware distribution being even more decoupled from the
end node; resulting in a very busy abuse desk at Google.




From a users perspective, some folks have gone as far as classifying
GWA as spyware, which has a very slight, if highly sarcastic, ring of truth
to it. While GWA is not sneakily installed on your system without your
knowledge, it does have the potential for collecting a vast array of
information that end users may not wish to allow Google to have, regardless
of their motives.




Users will have to ask themselves what they're trading in exchange for a
global web caching solution, and decide if it is worth it or not.
Of course, users have already had to make similar privacy vs. functionality
decisions with gmail and the google toolbar.




For more coverage of this topic:

http://google.blognewschannel.com/index.php/archives/2005/05/05/much-controversy-over-googles-accelerator/

ClamAV integration with Snort

William Metcalf and Victor Julien have written a preprocessor for Snort
that integrates the ClamAV antivirus package with existing IDS or IPS
functionality in Snort. This could become a very happy marriage of
software, and definately worth checking out!

http://www.bleedingsnort.com/article.php?story=20050506162938514

RSA SecurID WebAgent Heap Overflow

SEC-1 Ltd., has released a notification of a heap overflow in the RSA SecurID
WebAgent version 5.0 through 5.3. A proof-of-concept tool is not currently
available, but the published details are sufficient to indicate where to
begin searching for the bug. This flaw results in an unauthenticated
attacker being able to execute code within the LocalSystem context.
Patches have been made available to anyone with a current RSA maintenance
login at https://knowledge.rsasecurity.com