Closed Bug 665518 Opened 10 years ago Closed 10 years ago
Websocket Data Framing crash [@mozilla::net::ns
Web Socket Handler::Apply Mask]
Received connection: ('127.0.0.1', 61673) HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: x6X5fx2b1lAIM7QZxYAlCH7GW6c= Sending: b'\t\xff\xfe\x81\x05Hello'
section 4.2 says that the most-significant-bit of a 64 bit length must be 0.. (0xfe is the MSB of the length field above) and we are missing a check to enforce that.. failing to do so led to a quantity going negative and then various length checks failing.
Assignee: nobody → mcmanus
Status: NEW → ASSIGNED
Attachment #540471 - Flags: review?(cbiesinger)
10 years ago
Attachment #540471 - Flags: review?(cbiesinger) → review+
is there a particular reason that PRInt64 payloadLength is signed ?
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Attachment #540471 - Flags: approval-mozilla-aurora?
for the aurora review: this bug is found as part of websockets fuzz testing as part of the security review. yea for fuzz testing!
Comment on attachment 540471 [details] [diff] [review] 63 bit lengths v1 Approved for releases/mozilla-aurora
Attachment #540471 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
assuming worst-case sg:critical since it looks like we can overwrite heap data in ApplyMask() if we don't die reading out of bounds first.
Target Milestone: --- → mozilla7
You need to log in before you can comment on or make changes to this bug.