More on: WSE0020001 illegal header format detected: Illegal start line in request

[ulynch]

HTTP gurus, please chime in!

Client makes a connection across Checkpoint R61 on Nokia to an HTTP service running on Server. SmartDefense rejects the connection:

Attack: Malformed HTTP
Attack Information: WSE0020001 illegal header format detected: Illegal start line in request
Reason: 1B4

Packet capture shows three-way handshake, then Client issues an HTTP POST with "Transfer-encoding: chunked", and "Expect: 100-continue" headers. Server replies with "100-continue", which Client does. The next packet is from Client, it has no HTTP headers, 443 bytes of data, and the first bytes following the TCP header read "1B4", followed by CR LF CR LF.

If I read HTTP 1.1 RFC 2616, sec. 3.6 correctly, 1B4 should refer to the length of the following data in octets. Convert 1B4 from hex to decimal, you get 436. Adding the seven octets 1b4 CR LF CR LF, makes exactly 443 octets.

Checkpoint support responds:
> Pertaining to that SK, he said that your customer is using 'Chunk'
> HTTP transfer encoding, and that the 'Content-Length'
> field is not included in the HTTP header.
> Because of this, we don't know the length of the Content Header, and
> so we don't know where the content header stops and the data portion
> of the packet starts. The Content-Length field in the header should
> have been included by the developers.

I think they're mistaken. From my reading of RFC 2616, "Content-Length" does not specify the length of a header, but the length of the message body being transferred. Also, it's illegal to have both:

4.4 Message Length
<snip>
Messages MUST NOT include both a Content-Length header field and a
non-identity transfer-coding. If the message does include a non-
identity transfer-coding, the Content-Length MUST be ignored.

Chunking is specifically intended to be used when you don't know how much data will be transferred. That is, when you *can't* calculate the "Content-length" header. It seems the app is perfectly compliant with the RFC.

Further, Checkpoint's recommended fix is to "enable Active TCP Streaming...by...checking 'ASCII Only Response Headers' ". This did resolve the issue.

Ironically though, while passive TCP streaming complains when chunked HTTP does *not* include a Content-length header, apparently the active TCP streaming feature complains when both are present. The fix when that happens is to use passive TCP streaming by unchecking "ASCII Only Response Headers".

See, for example:
RE: [fw1-gurus] duplicated header 'content-length' in response
SilaGe

When I pointed this out to Checkpoint support, their response was "this is a limitation of our passive streaming engine...As far as whether or not this limitation is compliant with the RFC's, we would not be the proper channel for that discussion, as I'm afraid we don't make those kinds of determinations. For that, you would need to submit an RFE".

I did.

As this is not the only issue I have with it, I'm beginning to think I'm better off eliminating SmartDefense completely. (Though it appears even that is problematic.) SmartDefense, it would seem to me, is apparently neither.

Dan Lynch, CISSP
Information Technology Analyst
County of Placer
Auburn, CA

[melipla]

Very nice write up of the problem, its unfortunate that support cannot address these issues in a meaningful way. Obviously you've documented a flaw which would impact everyone, having them suggest that you submit an RFE which isn't [AFAIK] trackable or accountable to anyone is absurd.

Most of my SMDF is in Monitor Only and the majority [by far] of the alerts I receive are "WSE0020001 illegal header format detected" subset of errors. About a quarter of them are they type you've written up, but given the frequency of the alerts I've always suspected that they're false. I'm wondering if that whole class of alerts is suspect?

As a side note I've heard that SMDF is being completely rewritten. Whether or not that's indeed the case I can't say, but it could explain why they weren't interested in patching the issue.

[Thorpuse]

Hi Dan,

Piece of advice, the "submit an RFE" answer means it goes in the bit bucket. I'd suggest finding your local Check Point SE (ring the CA office, they should be able to tell you) and get them to raise it directly with Product Management. If you have no joy, PM me and I'll see if I still have the details of the SmartDefense Product Manager.