dxbjavid opened a new pull request, #854: URL: https://github.com/apache/httpcomponents-client/pull/854
readFrame accumulates the 127-form extended payload length into a signed long, but never checks that the most significant bit is clear the way RFC 6455 section 5.2 requires. A masked client frame declaring a length of 0xFFFFFFFF00000000 leaves len negative, so both the Integer.MAX_VALUE and the maxFramePayloadSize guards pass, and the value is then narrowed with a cast when the payload array is allocated. The reader hands back a frame whose payload length has nothing to do with the declared one, and carries on parsing the bytes that follow as the next frame header, so a peer can desynchronise the frame stream; 0xFFFFFFFFFFFFFFFF narrows to -1 and throws NegativeArraySizeException instead. The client-side WebSocketFrameDecoder already rejects a negative extended length in this spot, so this is really just the same guard missing on the server-side reader, placed before the narrowing rather than after it. Added a test that feeds the reader such a header; it passes on the current code because nothing is thrown. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
