Impact
First of all the issue found and reported by Felix Dörre all credits belongs to him.
The issue is that STUN/TURN response buffer is not initialized properly. CWE 665
This is a leak of information between different client connections. One client (an attacker) could use their connection to intelligently query coturn to get interesting bytes in the padding bytes from the connection of another client.
All coturn and so WebRTC community is impacted by this issue.
Patches
It is fixed in version 4.5.1.3.
Initializing to zero properly the stun buffer, in both case if it is newly allocated or if it is reused.
Workarounds
There is no known workaround.
References
When a turn answer requires padding, coturn does not set the padding explicitly to zero bytes, but sends the data that was previously in the send buffer.
This happens for example here, when the length is just adjusted and the previous contents are left untouched:
|
newlen=newlen+(4-newlenrem4); |
The buffers seem to get shared between clients/connections using this mechanism:
|
stun_buffer_list_elem *ret = get_elem_from_buffer_list(&(e->bufs)); |
|
add_elem_to_buffer_list(&(e->bufs), buf_elem); |
For more information
If you have any questions or comments about this advisory:
felixdoerre Analyst
Impact
First of all the issue found and reported by Felix Dörre all credits belongs to him.
The issue is that STUN/TURN response buffer is not initialized properly. CWE 665
This is a leak of information between different client connections. One client (an attacker) could use their connection to intelligently query coturn to get interesting bytes in the padding bytes from the connection of another client.
All coturn and so WebRTC community is impacted by this issue.
Patches
It is fixed in version 4.5.1.3.
Initializing to zero properly the stun buffer, in both case if it is newly allocated or if it is reused.
Workarounds
There is no known workaround.
References
When a turn answer requires padding, coturn does not set the padding explicitly to zero bytes, but sends the data that was previously in the send buffer.
This happens for example here, when the length is just adjusted and the previous contents are left untouched:
coturn/src/client/ns_turn_msg.c
Line 1448 in 113f138
coturn/src/client/ns_turn_msg.c
Line 1457 in 113f138
The buffers seem to get shared between clients/connections using this mechanism:
coturn/src/apps/relay/ns_ioalib_engine_impl.c
Line 292 in db68c76
coturn/src/apps/relay/ns_ioalib_engine_impl.c
Line 328 in db68c76
For more information
If you have any questions or comments about this advisory: