Malformed HTTP Request 5769.0

[m-hansson]

Should this signature trigger for:

GET /\r\n

I thought it should trigger for something like:

GET /\rHTTP/1.1\r\n\r\n

[jlimbo]

It will trigger on both, as you do not normally see the \r\n in the actual stream but as a terminating character of the request. The first example looks like it has \r\n before you see HTTP version, hence you would assume that the \r\n is premature in the stream.

I hope that helps.

-jonathan

[m-hansson]

Thanks.

No this is actually the entire request. Should not trigger in my opinion. Let me guess, you will tell me that is does not follow RFC standards? ;-)

[wsulym]

HTTP clients *should* send http version information with the exception of HTTP/0.9, which did not include version numbers. RFC 2145 further clarifies the http specification author's intents. HTTP clients adhering to the robusteness principle and RFC 2145, and that are not http/0.9 clients should really have the version information there. I'll agree, it's not a *must*, but its normally there.

Adding a carriage return prior to the http version was also a way to evade Snort's uricontent rules.

I would consider a CR before the http version non standard, you might not, maybe we just agree to disagree on that point. In any case, I'll update the benign triggers section of the alert.

[m-hansson]

Thanks Walter.

Once again I want to push for splitting this kind of signature into one that deals with the vulnerability and one with protocol abnormalies.

I'd really like to have this signature enabled because of the snort issue, but with the current amoumt of FP it is not an option.