exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

WebRTC usrsctp Incorrect Call

WebRTC usrsctp Incorrect Call
Posted Jul 31, 2020
Authored by Google Security Research

When usrsctp is used with a custom transport, an address must be provided to usrsctp_conninput be used as the source and destination address of the incoming packet. WebRTC uses the address of the SctpTransport instance for this value. Unfortunately, this value is often transmitted to the peer, for example to validate signing of the cookie. This could allow an attacker access to the location in memory of the SctpTransport of a peer, bypassing ASLR.

tags | advisory
advisories | CVE-2020-6514
SHA-256 | fd1aa95a1ad503592aea4e4e119465c590188163980b90ddc3e033c6ee7c80ec

WebRTC usrsctp Incorrect Call

Change Mirror Download
WebRTC: usrsctp is called with pointer as network address

When usrsctp is used with a custom transport, an address must be provided to usrsctp_conninput be used as the source and destination address of the incoming packet. WebRTC uses the address of the SctpTransport instance for this value. Unfortunately, this value is often transmitted to the peer, for example to validate signing of the cookie. This could allow an attacker access to the location in memory of the SctpTransport of a peer, bypassing ASLR.

To reproduce, place the following code on line 9529 of sctp_output.c. This will output the peer's address to the log:

struct sctp_state_cookie cookie2;
struct sctp_state_cookie* cookie3;
cookie3 = sctp_get_next_param(cookie, 4, &cookie2, sizeof(struct sctp_state_cookie));


LOGE(\"COOKIE INITACK ADDRESS %llx laddress %llx\", *((long long*)cookie3->address), *((long long*)cookie3->address));

Or, view the SCTP packets sent by WebRTC before they are sent to the encryption layer. They are full of pointers.

This bug is subject to a 90 day disclosure deadline. After 90 days elapse,
the bug report will become visible to the public. The scheduled disclosure
date is 2020-Jul-28. Disclosure at an earlier date is possible if
agreed upon by all parties.


Related CVE Numbers: CVE-2020-6514.



Found by: deadbeef@chromium.org

Login or Register to add favorites

File Archive:

May 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    May 1st
    44 Files
  • 2
    May 2nd
    5 Files
  • 3
    May 3rd
    11 Files
  • 4
    May 4th
    0 Files
  • 5
    May 5th
    0 Files
  • 6
    May 6th
    28 Files
  • 7
    May 7th
    3 Files
  • 8
    May 8th
    4 Files
  • 9
    May 9th
    54 Files
  • 10
    May 10th
    12 Files
  • 11
    May 11th
    0 Files
  • 12
    May 12th
    0 Files
  • 13
    May 13th
    18 Files
  • 14
    May 14th
    11 Files
  • 15
    May 15th
    17 Files
  • 16
    May 16th
    13 Files
  • 17
    May 17th
    22 Files
  • 18
    May 18th
    0 Files
  • 19
    May 19th
    0 Files
  • 20
    May 20th
    17 Files
  • 21
    May 21st
    18 Files
  • 22
    May 22nd
    7 Files
  • 23
    May 23rd
    111 Files
  • 24
    May 24th
    27 Files
  • 25
    May 25th
    0 Files
  • 26
    May 26th
    0 Files
  • 27
    May 27th
    6 Files
  • 28
    May 28th
    12 Files
  • 29
    May 29th
    31 Files
  • 30
    May 30th
    0 Files
  • 31
    May 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close