Mark HuntLooking for some help, my company might not be able to fully patch CVE-2023-4863 aka BLASTPASS for a few days. Does anyone know a way of detecting exploitation of this through Splunk? Can you see it in web server logs? Next-gen firewall? WAF? Iām not seeing much info online about how to detect the exploitation.
KetumbraMS claim #cve20234863 is patched in Teams 1.6.00.26474 but still with Electron 19.1.8. Does anyone know if this means it's only patched in 'new' mode (Webview2) or always?
#libwebp #msteams
#libwebp #msteams
IAintShootinMisHere's a non-exhaustive list of all the stuff I've seen people doing to mitigate #cve20234863 #libwebp
https://www.justinmcafee.com/2023/09/libwebp-cve-2023-4683.html
MrTechGadgetI did some digging and thought I would share for those who use MS Teams
Newest version released yesterday is 1.6.00.26463(macOS), 1.6.00.26474(Windows).
It uses Electron Version 19.1.8 (ancient and out of support for almost a year!!!)
Electron 19.1.8 uses Chromium 102.0.5005.167
Chromium 102.0.5005.167 uses libwebp 1.2.2
libwebp 1.2.2 is vulnerable to the lilbwebp 0-day, #CVE20234863
Be careful who you let in a Teams meeting...
Newest version released yesterday is 1.6.00.26463(macOS), 1.6.00.26474(Windows).
It uses Electron Version 19.1.8 (ancient and out of support for almost a year!!!)
Electron 19.1.8 uses Chromium 102.0.5005.167
Chromium 102.0.5005.167 uses libwebp 1.2.2
libwebp 1.2.2 is vulnerable to the lilbwebp 0-day, #CVE20234863
Be careful who you let in a Teams meeting...
Thijs KromhoutThe #CVE-2023-5129 has been withdrawn. Now it is only the initial #CVE20234863 that is still valid, although with a somewhat lower rating (8.8).
d0pp3l6ang3r 
Good Morning, story so far on the next log4j level #vulnerability #CVE20234863 #CVE20235129
#0day #Chrome #iOS
- libwebp library is vulnerable to heap overflow and can lead to RCE.
- Apple assigned #CVE202341064 and #CVE202341061. Also actively exploited by #blastpass
- #Google assigned #CVE20235129 for Chrome 0day and also exploited
- Millions of apps and software use this library. See list sofar in š§µ
- #CVE20235129 was rejected by NVD earlier due to all this confusion of several vendors assigning CVEs affecting their products
- This will lead to vulnerability scanners not being able to correctly identify if your assets are affected with libwebp. #infosec #sectoot
š” 
āAnalysis of WebP Zero-Day Vulnerability (CVE-2023-4863)
Introduction:
- The WebP zero-day vulnerability, identified as CVE-2023-4863, was discovered by Apple's Security Engineering and Architecture (SEAR) team and was reported to Google. The vulnerability was a heap buffer overflow in the WebP image library, which was being exploited in the wild.
Technical Analysis:
- The vulnerability resided in the "lossless compression" support for WebP, also known as VP8L. The issue was within the Huffman coding algorithm used by WebP for lossless compression.
- The vulnerable code was found to overflow the Huffman table when decoding an untrusted image due to incorrect memory allocations based on pre-calculated buffer sizes from a fixed table.
- The patch fixed the issue by performing a "first pass" construction to calculate the total size required for the Huffman table before actual construction, thereby preventing the overflow.
Exploit Analysis:
- A proof-of-concept (PoC) was developed to replicate the bug, demonstrating a heap-buffer-overflow. The PoC utilized crafted Huffman coding data to trigger the overflow.
- The exploitation required constructing a sequence of four valid Huffman tables followed by a specific type of invalid Huffman table to trigger the overflow.
- The overflow could lead to out-of-bounds write, which was deemed exploitable.
Mitigation:
- The patch provided by Google addressed the issue by denying the inputs that would cause a heap overflow, effectively mitigating the vulnerability.
Fuzzing Challenges:
- Post mitigation, a discussion arose regarding the effectiveness of fuzzing in discovering such vulnerabilities. The complexity and fragility of the format made it a challenging task for fuzzers to identify this specific vulnerability.
- A new fuzzer was released by Google specifically for the Huffman routines in WebP to enhance the fuzzing process.
Conclusion:
- The WebP 0day (CVE-2023-4863) showcased the intricacies and challenges in identifying and mitigating vulnerabilities in complex file format libraries. The analysis also highlighted the importance of effective fuzzing techniques to uncover such vulnerabilities in the future.
The WebP 0day
Early last week, Google released a new stable update for Chrome. The update included a single security fix that was reported by Apple's Security Engineering and Architecture (SEAR) team. The issue, CVE-2023-4863, was a heap buffer overflow in the WebP image library, and it had a familiar warning attached: "Google
Royce Williams@campuscodi This article claims that it is a new CVE for the same vulnerability, to clarify scope?
https://stackdiary.com/heap-buffer-overflow-in-libwebp-cve-2023-5129/
But this seclists thread seems to say that CVE-2023-5129 is associated with libwebp commits that are different from the fixes associated with CVE-2023-4863 [Edit: but these are described by the issuer as cleanups]:
https://seclists.org/oss-sec/2023/q3/230
The seclists poster is reaching out to double-check whether it's new. Solar Designer's assessment is that it's probably the same (but that the cleanups in the code should be examined anyway):
https://seclists.org/oss-sec/2023/q3/236
#CVE20235129 #CVE20234863 #CVE_2023_4863 ##CVE_2023_5129 #libwebp
HostvixGoogle assigns a CVE for libwebp and gives it a 10.0 score
https://stackdiary.com/heap-buffer-overflow-in-libwebp-cve-2023-5129/
Mark Gardner@Perl Here is a find + #Perl command for #macOS that will check which installed #Electron-based applications have not yet been updated against this month's #libwebp #CVE20234863 #security vulnerability: https://social.sdf.org/@mjgardner/111126922716051872
Other apps may be vulnerable, this just checks the Electron ones!
It uses the built-in https://perldoc.perl.org/version API for parsing and comparing version numbers.
Mark Gardner ā:sdf: (@[email protected])
@[email protected] I've expanded @[email protected]ās command to check apps against #Electron releases with fixed #libwebp find /Applications -type f -name '*Electron Framework*' -exec \ perl -Mversion=0.77 -nE \ '@safe = map version->parse($_), qw(22.3.24 24.8.3 25.8.1 26.2.1); next unless m{Chrome/[0-9.]+ Electron/([0-9.]+)}; $ver = version->parse($1); if ($ver < (grep int $_->numify == int $ver->numify, @safe)[0]) { say "vulnerable Electron $ver found in $ARGV"; next }' {} \;