[prev in list] [next in list] [prev in thread] [next in thread] 

List:       websecurity
Subject:    Re: [WEB SECURITY] Fwd: VRT Certified Rules Update: 2005-06-29
From:       Barry Gould <mailinglists () pennysaverusa ! net>
Date:       2005-07-01 17:34:45
Message-ID: 6.2.1.2.2.20050701103747.02897d30 () mail ! pennysaverusa ! net
[Download RAW message or body]

I don't know if you've already seen this, but there's a discussion of the 
Snort phpBB rules at the SANS ISC here:
http://isc.sans.org/diary.php?date=2005-06-30

Barry
At 01:49 PM 6/29/2005, Ryan Barnett wrote:
> Are there any Snort subscribers who have access to the latest ruleset?
>  I am interested to see how the Snort rules are addressing the proxy
> cache poisoning issues.
> I am assuming that this is based on the HTTP Request
> Splitting/Smuggling whitepaper that Amit Klein, Ory Segal and Co put
> out - http://www.watchfire.com/resources/HTTP-Request-Smuggling.pdf
> There were many different mechanisms for possibly smuggling a request
> and I am wondering what Snort sigs they created for this.
> Thanks,
> --
> Ryan C. Barnett
> Web Application Security Consortium (WASC) Member
> CIS Apache Benchmark Project Lead
> SANS Instructor: Securing Apache
> GCIA, GCFA, GCIH, GSNA, GCUX, GSEC
> ---------- Forwarded message ----------
> From: jennifer.steffens@xxxxxxxxxxxxxx <jennifer.steffens@xxxxxxxxxxxxxx>
> Date: Jun 29, 2005 4:22 PM
> Subject: VRT Certified Rules Update: 2005-06-29
> To: RCBarnett@xxxxxxxxx
> The Sourcefire Vulnerability Research Team (VRT) has learned of
> serious vulnerabilities affecting IBM Websphere and Squid HTTP proxy
> server.
>  Details:
> A Squid proxy server can cache resources to make access to them more
> efficient.  A malformed request sent to a Squid proxy server may be
> interpreted and processed differently than the actual responding web
> server.  A particular malformed request that contains two
> "Content-Length" header fields can be used to try to poison the cache
> by causing the Squid proxy server and an upstream server to process
> the contents differently.
> A rule to detect attacks against this vulnerability is included in
> this rule pack and is identified as sid 3694.
> IBM WebSphere may use form-based authentication to permit access to
> applications.  The CGI variables j_username and j_password are used
> for this authentication process.  Overly long values passed to these
> variables can cause a buffer overflow and the subsequent execution of
> arbitrary code on the vulnerable server. This is due to a failure in
> the code to accommodate wide-character expansion for the receiving
> buffer.
> Advisory:
> A detailed advisory as well as a complete list of modified and deleted
> rules is available at
> http://www.snort.org/rules/advisories/vrt-rules-2005-06-29.html
> Download Rules:
> These rules will be available to subscribers only until July 4th,
> 2005. Subscribers can download the rules at
> http://www.snort.org/pub-bin/downloads.cgi. If you would like to
> purchase a subscription, please visit
> http://www.snort.org/rules/why_subscribe.html or contact Jennifer
> Steffens at 410.423.1930 or jennifer.steffens@xxxxxxxxxxxxxxx
> 
> To Unsubscribe:
> Sourcefire does not condone or support unsolicited email. You are
> receiving this e-mail because you are subscribed on snort.org to
> receive updates about Sourcefire VRT Subscriptions. To be removed from
> this list, visit https://www.snort.org/reg-bin/userprefs.cgi and click
> unsubscribe for the appropriate list.
> ---------------------------------------------------------------------
> The Web Security Mailing List
> http://www.webappsec.org/lists/websecurity/
> The Web Security Mailing List Archives
> http://www.webappsec.org/lists/websecurity/archive/

---------------------------------------------------------------------
The Web Security Mailing List
http://www.webappsec.org/lists/websecurity/
The Web Security Mailing List Archives
http://www.webappsec.org/lists/websecurity/archive/


[prev in list] [next in list] [prev in thread] [next in thread]