I guess it got lost in the dissertation, eh?
This fix will require only installation - there are no custom settings to
apply.
ISA will use the RFC-defined action; it will ignore the conteont-length
header and instead use the chunked data to perform quantitative validation.
--
Jim Harrison (ISA SE)
Read the help / books / articles / blogs!
This is posting is provided "as is" with no warranties, and confers no rights.
"ZVR" wrote:
> Thanks for the update Jim! One question though. How is the hotfix handling
> the sites that are not RFC-2616 compliant? Once we apply the hotfix, do we
> get a new setting/tab/view etc somewhere in the ISA console that allows us
> to define "exceptions" to the http smuggling processing? Or is that just
> turned off globally by the hotfix.
>
> Thanks again,
> Virgil
>
>
>
> "Jim Harrison (MSFT)" < XXXX@XXXXX.COM > wrote in message
> news: XXXX@XXXXX.COM ...
> > ** ACTION **
> > 1. Call PSS
> > 2. Tell them I sent you
> > 3. Ask for the fix for ISA SE 34978
> >
> > ** NOTE **
> > This fix is still undergoing internal testing. If you are not willing to
> > participate in this hotfix testing, then please wait for
> > the official fix.
> >
> > ** DISCUSSION (kinda involved, so you can skip it if you like) **
> > ISA responds to a request with "Error Code: 502 Proxy Error. The HTTP
> > request includes a non-supported header. Contact your ISA
> > Server administrator. (12156)".
> > The likely reason for the behavior you're seeing in this case is that new
> > logic that was added in ISA 2004 SP2 to mitigate HTTP
> > request smuggling. The process for this attack is a bit involved and a
> > whitepaper on the subject is available here:
> > https://www.watchfire.com/securearea/whitepapers.aspx
> >
> > RFC-2616 defines two headers; "content-length" and "transfer-encoding:
> > chunked" for the same purpose; that of providing quantitative
> > content validation for the receiver and states *very clearly* that the
> > server MUST NOT combine them in the same response. If the
> > server is configured such that it does violate this edict, RFC-2616 then
> > requires the receiving entity to ignore the content-length
> > value and instead use the chunked-encoding technique to validate the
> > length of the HTTP body. This places a processing burden on the
> > receiving entity (ISA, in this case), since a chunked-encoded transfer
> > can't be quantitatively validated until the transfer is
> > completed. In the case of a proxy, additional processing is imposed due to
> > caching behavior that may be dependent on content-size.
> >
> > The reason those sites are either failing outright (www.delta.com) or
> > rendering poorly (www.sun.com) is because we chose to reject
> > those responses entirely. Since RFC-2616 clearly states "don't combine
> > those headers" and doing so is a demonstrably malicious act,
> > it seemed unlikely that ISA would cause problems for any other than
> > malicious sites, and in fact, our testing validated this belief.
> > As it turns out, there are quite a few legitimate sites out there that
> > violate this part of RFC-2616 and so we have had to rethink
> > our answer to this problem.
> > --
> > --
> > Jim Harrison [ISA SE]
> > Read the help, books and articles!
> > This posting is provided "AS IS" with no warranties, and confers no
> > rights.
> >
> >
>
>
>