Mantis - Resin
|
|||||
Viewing Issue Advanced Details | |||||
|
|||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
6460 | minor | always | 01-26-22 11:02 | 02-01-23 15:03 | |
|
|||||
Reporter: | knut_forkalsrud | Platform: | |||
Assigned To: | ferg | OS: | |||
Priority: | normal | OS Version: | |||
Status: | closed | Product Version: | 4.0.64 | ||
Product Build: | Resolution: | fixed | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | 4.0.67 | ||
|
|||||
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". | ||||
Relationships | |||||
Attached Files: |
There are no notes attached to this issue. |