0006460: Some (arguably broken) HTTP headers cause unhandled errors

Viewing Issue Advanced Details [ Jump to Notes ]

[ View Simple ] [ Issue History ] [ Print ]

Category

Severity

Reproducibility

Date Submitted

Last Update

0006460

[Resin]

minor

always

01-26-22 11:02

02-01-23 15:03

Reporter

knut_forkalsrud

View Status

public

Assigned To

ferg

Priority

normal

Resolution

fixed

Platform

Status

closed

Projection

none

OS Version

ETA

none

Fixed in Version

4.0.67

Product Version

4.0.64

Product Build

Summary

0006460: Some (arguably broken) HTTP headers cause unhandled errors

Description

We get requests with headers including things like this:

Upgrade: websocket
Connection: upgrade
Sec-WebSocket-Key: /&65414;k-\x01,XH&65429;\x08&65430;eth0:
Sec-WebSocket-Protocol: ovrc-protocol
Sec-WebSocket-Version: 13
Origin: D4:6A:91:37:EB:F3

In particular I think the "Sec-WebSocket-Key" header's value is the problem. It is seemingly random bytes, usually different from one request to another.

When we try to enumerate the request headers using (HttpServletRequest) getHeaderNames() and getHeader(name) on each of them, we run into an ArrayIndexOutOfBounds exception. The stack trace being something like this

java.lang.ArrayIndexOutOfBoundsException: 65477
    at com.caucho.server.http.HttpRequest.matchNextHeader(HttpRequest.java:545)
    at com.caucho.server.http.HttpRequest.getHeaderBuffer(HttpRequest.java:468)
    at com.caucho.server.http.HttpRequest.getHeader(HttpRequest.java:385)
    at com.caucho.server.http.HttpServletRequestImpl.getHeader(HttpServletRequestImpl.java:865)
...

Not sure how important this is. As far as I've been able to work out, it doesn't cause any security issue or other bad side effects. But it does fill up our error logs.
In an ideal world, Resin would reject the request and respond with code 400.

Steps To Reproduce

Additional Information

"ovrc-protocol" seems to be related to IoT or home automation. OVRC, SnapAV, Control4 is all the same company (https://snapone.com/our-story/). [^] Most likely there are stale DNS caches somewhere, causing their devices to contact EC2 IP addresses formerly associate with their "mothership".

Attached Files

Relationships

There are no notes attached to this issue.

Issue History
Date Modified	Username	Field	Change
01-26-22 11:02	knut_forkalsrud	New Issue
02-01-23 15:03	ferg	Assigned To	=> ferg
02-01-23 15:03	ferg	Status	new => closed
02-01-23 15:03	ferg	Resolution	open => fixed
02-01-23 15:03	ferg	Fixed in Version	=> 4.0.67

Mantis 1.0.0rc3[^]

30 total queries executed.
28 unique queries executed.