0day.today - Biggest Exploit Database in the World.
- We use one main domain: http://0day.today
- Most of the materials is completely FREE
- If you want to purchase the exploit / get V.I.P. access or pay for any other service,
you need to buy or earn
GOLD
Administration of this site uses the official contacts. Beware of impostors!
We DO NOT use Telegram or any messengers / social networks!Please, beware of scammers!
- Read the [ agreement ]
- Read the [ Submit ] rules
- Visit the [ faq ] page
- [ Register ] profile
- Get [ GOLD ]
- If you want to [ sell ]
- If you want to [ buy ]
- If you lost [ Account ]
- Any questions [ admin@0day.today ]
- Authorisation page
- Registration page
- Restore account page
- FAQ page
- Contacts page
- Publishing rules
- Agreement page
Mail:
Facebook:
Twitter:
Telegram:
We DO NOT use Telegram or any messengers / social networks!
Contact us
You can contact us by:
Mail:
Facebook:
Twitter:
Telegram:
We DO NOT use Telegram or any messengers / social networks!
WebRTC - VP9 Frame Processing Out-of-Bounds Memory Access Exploit
Author
Risk
[Security Risk Medium
]0day-ID
Category
Date add
CVE
Platform
There is a missing check in VP9 frame processing that could lead to memory corruption.
In the file video_coding/rtp_frame_reference_finder.cc, the function RtpFrameReferenceFinder::ManageFrameVp9 fetches the GofInfo based on a pic_idx parsed from the incoming packet header. If the incoming frame is of type kVideoFrameKey, find is called on an iterator and the result is used without checking whether the it succeeds.
if (frame->frame_type() == kVideoFrameKey) {
...
GofInfo info = gof_info_.find(codec_header.tl0_pic_idx)->second;
FrameReceivedVp9(frame->id.picture_id, &info);
UnwrapPictureIds(frame);
return kHandOff;
}
This can cause a pointer to memory outside the gof_info_ map to be passed to FrameReceivedVp9. This function both reads and writes the info structure.
This issue does not crash reliably, so I recommend reproducing it using an asan build of Chrome. To reproduce the issue:
1) unzip the attached webrtc-from-chat.zip on a local webserver
2) fetch the webrtc source (https://webrtc.org/native-code/development/), and replace src/modules/rtp_rtcp/source/rtp_format_vp9.cc with the version attached to the code
3) build webrtc, including the examples
4) run the attached webrtcserver.py with python 3.6 or higher
5) start the peerconnection_client sample in the webrtc examples. Connect to the recommended server, and then select test2 as the peer to connect to
6) visit http://127.0.0.1/webrtc-from-chat/index.html in chrome
7) Enter any username and hit "Log in"
8) Type anything into the chat window at the bottom and hit send
Chrome should crash in a few seconds.
Though the attached PoC requires user interaction, it is not necessary to exercise this issue in a browser.
This issue affects any browser that supports VP9, and can be reached by loading a single webpage (though some browsers will prompt for permissions). It also affects native clients (such as mobile applications) that use webrtc and support VP9, though the user has to place or answer a video call for their client to be in the state where this issue is reachable.
I recommend fixing this by changing the above code to:
auto gof_info_it = gof_info_.find(codec_header.tl0_pic_idx);
if (gof_info_it == gof_info_.end())
return kDrop;
GofInfo info = gof_info_it->second;
FrameReceivedVp9(frame->id.picture_id, &info);
I have verified that this fix would prevent the crash.
Proof of Concept:
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/bin-sploits/44862.zip
# 0day.today [2024-12-25] #