Skip to content

Commit bad068c

Browse files
CVPN-2035: Fix using correct struct for validating length
Existing code had used `he_msg_auth_hdr_t` instead of `he_msg_auth_buf_t` or `he_msg_auth_token_t` struct. The difference between the structs `he_msg_auth_buf_t` and `he_msg_auth_hdr_t` is 2. This causes memory bounding logic to fail, allowing malicious requests with additional 2 bytes in length to continue. (ex: actual buf: 2 bytes, buf_length: 4) But since we use local stack buffer which is reseted on every packet, the bytes sent to the callback could only be having 0 values. https://github.com/expressvpn/lightway-core/blob/d51702d8f8bd37874e5e70da434bf22930a6b48a/src/he/flow.c#L464 Fix this by using the correct struct in bound checking. Tests which were added in previous commit will pass now.
1 parent d09897c commit bad068c

File tree

1 file changed

+2
-2
lines changed

1 file changed

+2
-2
lines changed

src/he/msg_handlers.c

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -279,7 +279,7 @@ he_return_code_t he_handle_msg_auth(he_conn_t *conn, uint8_t *packet, int length
279279

280280
// Check the auth token length
281281
uint16_t auth_token_length = ntohs(msg_token->token_length);
282-
if(auth_token_length > (length - sizeof(he_msg_auth_hdr_t))) {
282+
if(auth_token_length > (length - sizeof(he_msg_auth_token_t))) {
283283
return HE_ERR_PACKET_TOO_SMALL;
284284
}
285285
auth_state = conn->auth_token_cb(conn, msg_token->token, auth_token_length, conn->data);
@@ -298,7 +298,7 @@ he_return_code_t he_handle_msg_auth(he_conn_t *conn, uint8_t *packet, int length
298298

299299
// Check the auth buffer length
300300
uint16_t auth_buf_length = ntohs(msg_buf->buffer_length);
301-
if(auth_buf_length > (length - sizeof(he_msg_auth_hdr_t))) {
301+
if(auth_buf_length > (length - sizeof(he_msg_auth_buf_t))) {
302302
return HE_ERR_PACKET_TOO_SMALL;
303303
}
304304
auth_state = conn->auth_buf_cb(conn, msg_buf->header.auth_type, msg_buf->buffer,

0 commit comments

Comments
 (0)