An oversight in BCB handling of reboot reason that allows for persistent code execution

_Published December 5, 2023_

The Chromecast Security Bulletin contains details of security vulnerabilities affecting supported Chromecast with Google TV devices (Chromecast devices). For Chromecast devices, security patch levels of 2023-10-01 or later address all applicable issues in the October 2023 Android Security Bulletin and all issues in this bulletin. To learn how to check a device's security patch level, see Chromecast firmware versions & release notes.

All supported Chromecast devices will receive an update to the 2023-10-01 patch level. We encourage all customers to accept these updates to their devices.

**Announcements**

*   In addition to the security vulnerabilities described in the October 2023 Android Security Bulletin, Chromecast devices also contain patches for the security vulnerabilities described below.

**Security patches**

Vulnerabilities are grouped under the component that they affect. There is a description of the issue and a table with the CVE, associated references, type of vulnerability, severity, and updated Android Open Source Project (AOSP) versions (where applicable). When available, we link the public change that addressed the issue to the bug ID, like the AOSP change list. When multiple changes relate to a single bug, additional references are linked to numbers following the bug ID.

**AMLogic**

    

CVE

References

Severity

Subcomponent

CVE-2023-48425  

A-291138519

High

U-Boot

CVE-2023-48424  

A-286458481

High

U-Boot

CVE-2023-6181  

A-291138116

Moderate

U-Boot

**System**

    

CVE

References

Severity

Subcomponent

CVE-2023-48417  

A-288311233

Moderate

KeyChain

**Functional patches**

For details on the new bug fixes and functional patches included in this release, refer to the Chromecast firmware versions & release notes.

**Acknowledgements**

Researchers

CVEs

Nolen Johnson, DirectDefense and Jan Altensen, Ray Volpe

CVE-2023-6181, CVE-2023-48425,

Lennert Wouters, rqu, Thomas Roth aka stacksmashing

CVE-2023-48424

Rocco Calvi (TecR0c), SickCodes

CVE-2023-48417

**Common questions and answers**

This section answers common questions that may occur after reading this bulletin.

**1\. How do I determine if my device is updated to address these issues?**

Security patch levels of 2023-10-01 or later address all issues associated with the 2023-10-01 security patch level and all previous patch levels. To learn how to check a device's security patch level, read the instructions on the Chromecast firmware versions & release notes.

**2\. Why are security vulnerabilities split between this bulletin and the Android Security Bulletins?**

Security vulnerabilities that are documented in the Android Security Bulletins are required to declare the latest security patch level on Android devices. Additional security vulnerabilities, such as those documented in this bulletin are not required for declaring a security patch level.

**3\. What do the entries in the _Type_ column mean?**

Entries in the _Type_ column of the vulnerability details table reference the classification of the security vulnerability.

 

Abbreviation

Definition

RCE

Remote code execution

EoP

Elevation of privilege

ID

Information disclosure

DoS

Denial of service

N/A

Classification not available

**4\. What do the entries in the _References_ column mean?**

Entries under the _References_ column of the vulnerability details table may contain a prefix identifying the organization to which the reference value belongs.

 

Prefix

Reference

A-

Android bug ID

**5\. What does an \* next to the Android bug ID in the _References_ column mean?**

Issues that are not publicly available have an \* next to the Android bug ID in the _References_ column.

**Versions**

  

Version

Date

Notes

1.0

December 5, 2023

CVE-2023-6181: Chromecast Security Bulletin—December 2023

SyncTrayzor 1.1.29 enables CEF (Chromium Embedded Framework) remote debugging, allowing a local attacker to control the application.

**Have a question about this project?** Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Pick a username

Email Address

Password

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CVE-2021-46899: Remove RemoteDebuggingPort for release builds · Issue #666 · canton7/SyncTrayzor

By Waqas
Another day, another Bluetooth vulnerability impacting billions of devices worldwide!
This is a post from HackRead.com Read the original post: Bluetooth Vulnerability Enables Keystroke Injection on Android, Linux, macOS, iOS

Keystroke injection is a method wherein malicious commands or keystrokes are remotely injected into a system to compromise or manipulate its functionality, often exploited for unauthorized access or control.

A critical vulnerability in Bluetooth allows attackers to take control of Android, Linux, macOS, and iOS devices, including devices in Lockdown Mode. This vulnerability is tracked as **CVE-2023-45866** and disclosed by security researcher Marc Newlin. 

It enables attackers to connect to vulnerable devices without user confirmation and inject keystrokes, potentially allowing them to install malicious apps, run arbitrary commands, and perform other unauthorized actions (except those requiring password/biometric authentication). The software vendors were notified about the flaw in August 2023.

This vulnerability was first identified in 2016 in non-Bluetooth wireless mice and keyboards. Back then, it was assumed that Bluetooth was secure and promoted as a better alternative to vulnerable custom protocols.

In 2023, a challenge forced Newlin to focus on Apple’s Magic Keyboard due to its **reliance on Bluetooth** and Apple’s security reputation. Initial research revealed limited information about Bluetooth, macOS, and iOS, necessitating extensive learning. 

Later, unauthenticated Bluetooth keystroke injection vulnerabilities in macOS and iOS were discovered, which were exploitable even when **Lockdown Mode** was enabled. Similar flaws were identified in Linux and Android, suggesting a broader issue beyond individual implementations. The Bluetooth HID specification analysis revealed a combination of protocol design and implementation bugs.

Newlin explained in his **post on GitHub** that multiple Bluetooth stacks had authentication bypass vulnerabilities. The attack exploits an “unauthenticated pairing mechanism” defined within the Bluetooth specification, tricking the target device into accepting a fake keyboard.

This deception allows an attacker in close proximity to connect and inject keystrokes, potentially enabling them to install apps and execute arbitrary commands. It is worth noting that unpatched devices are vulnerable under specific conditions, such as:

*   Android: Bluetooth must be enabled.
*   Linux/BlueZ: Bluetooth must be discoverable/connectable.
*   iOS/macOS: Bluetooth must be enabled, and a Magic Keyboard must be paired with the device.

These vulnerabilities can be exploited with a standard Bluetooth adapter on a Linux computer. Notably, some vulnerabilities predate “**MouseJack**“, affecting Android devices as far back as version 4.2.2 (released in 2012). 

In a comment to Hackread.com, Ken Dunham, Director of Cyber Threat at Qualys said “The two new Bluetooth vulnerabilities that exist for Android, Linux, MacOS, and iOS enable unauthorized attackers to perform an “unauthenticated pairing”, then possibly enable execution of code and to run arbitrary commands.”

“Bluetooth attacks are limited to close physical proximity. As a workaround, users of vulnerable systems can limit their attack surface and risk until patched by disabling Bluetooth,” Dunham advised.

While a fix for the Linux vulnerability existed since 2020 (**CVE-2020-0556**), it was surprisingly left disabled by default. Despite announcements by major Linux distributions, only ChromeOS is known to have implemented the fix. The latest BlueZ patch for CVE-2023-45866 finally enables this crucial fix by default.

It is a serious vulnerability impacting a vast array of devices, exposing potential security risks inherent to Bluetooth technology. However, according to Google, “fixes for these issues that affect Android 11 through 14 are available to impacted OEMs. All currently-supported Pixel devices will receive this fix via December OTA updates.”

1.  **BlueRepli attack bypasses Bluetooth authentication on Android**
2.  **BleedingTooth Bluetooth vulnerability allows RCE in Linux devices**
3.  **Update your devices: New Bluetooth flaw lets attackers monitor traffic**
4.  **BlueBorne Bluetooth Flaw Affects Millions of Smartphones, IoT and PCs**
5.  **Hackers can crash Google’s Nest Dropcams by exploiting Bluetooth flaws**

Bluetooth Vulnerability Enables Keystroke Injection on Android, Linux, macOS, iOS

The North Korean threat actor known as Kimsuky has been observed targeting research institutes in South Korea as part of a spear-phishing campaign with the ultimate goal of distributing backdoors on compromised systems.
"The threat actor ultimately uses a backdoor to steal information and execute commands," the AhnLab Security Emergency Response Center (ASEC) said in an

Cyber Espionage / Cryptocurrency

The North Korean threat actor known as **Kimsuky** has been observed targeting research institutes in South Korea as part of a spear-phishing campaign with the ultimate goal of distributing backdoors on compromised systems.

"The threat actor ultimately uses a backdoor to steal information and execute commands," the AhnLab Security Emergency Response Center (ASEC) said in an analysis posted last week.

The attack chains commence with an import declaration lure that's actually a malicious JSE file containing an obfuscated PowerShell script, a Base64-encoded payload, and a decoy PDF document.

The next stage entails opening the PDF file as a diversionary tactic, while the PowerShell script is executed in the background to launch the backdoor.

The malware, for its part, is configured to collect network information and other relevant data (i.e., host name, user name, and operating system version) and transmit the encoded details to a remote server.

It's also capable of running commands, executing additional payloads, and terminating itself, turning it into a backdoor for remote access to the infected host.

UPCOMING WEBINAR

Cracking the Code: Learn How Cyber Attackers Exploit Human Psychology

Ever wondered why social engineering is so effective? Dive deep into the psychology of cyber attackers in our upcoming webinar.

Join Now

Kimsuky, active since at least 2012, started off targeting South Korean government entities, think tanks, and individuals identified as experts in various fields, before expanding its victimology footprint to encompass Europe, Russia, and the U.S.

Earlier this month, the U.S. Treasury Department sanctioned Kimsuky for gathering intelligence to support North Korea's strategic objectives, including geopolitical events, foreign policy, and diplomatic efforts.

"Kimsuky has focused its intelligence collection activities on foreign policy and national security issues related to the Korean peninsula, nuclear policy, and sanctions," cybersecurity firm ThreatMon noted in a recent report.

The state-sponsored group has also been observed leveraging booby-trapped URLs that, when clicked, download a bogus ZIP archive masquerading as an update for the Chrome browser to deploy a malicious VBScript from Google Drive that employs the cloud storage as a conduit for data exfiltration and command-and-control (C2).

**Lazarus Group Goes Phishing on Telegram**

The development comes as blockchain security company SlowMist implicated the notorious North Korea-backed outfit called the Lazarus Group in a widespread phishing campaign on Telegram targeting the cryptocurrency sector.

"More recently, these hackers have escalated their tactics by posing as reputable investment institutions to execute phishing scams against various cryptocurrency project teams," the Singapore-based firm said.

After establishing rapport, the targets are deceived into downloading a malicious script under the guise of sharing an online meeting link that facilitates crypto theft.

It also follows a report from the Seoul Metropolitan Police Agency (SMPA) that accused the Lazarus sub-cluster codenamed Andariel of stealing technical information about anti-aircraft weapon systems from domestic defense companies and laundering ransomware proceeds back to North Korea.

It is estimated that more than 250 files amounting to 1.2 terabytes have been stolen in the attacks. To cover up the tracks, the adversary is said to have used servers from a local company that "rents servers to subscribers with unclear identities" as an entry point.

In addition, the group extorted 470 million won ($356,000) worth of bitcoin from three South Korean firms in ransomware attacks and laundered them through virtual asset exchanges such as Bithumb and Binance. It's worth noting that Andariel has been linked to the deployment of Maui ransomware in the past.

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

N. Korean Kimsuky Targeting South Korean Research Institutes with Backdoor Attacks

Microsoft Edge (Chromium-based) Elevation of Privilege Vulnerability

CVE-2023-35618

Microsoft Edge (Chromium-based) Information Disclosure Vulnerability

CVE-2023-38174

CVE-2023-36880

libheif v1.17.5 was discovered to contain a segmentation violation via the component /libheif/exif.cc.

**Description**

SEGV libheif/libheif/exif.cc:55 in read16

**Version**

     heif-convert  libheif version: 1.17.5
    -------------------------------------------
    Usage: heif-convert [options]  <input-image> [output-image]
    
    The program determines the output file format from the output filename suffix.
    These suffixes are recognized: jpg, jpeg, png, y4m. If no output filename is specified, 'jpg' is used.
    
    Options:
      -h, --help                     show help
      -v, --version                  show version
      -q, --quality                  quality (for JPEG output)
      -o, --output FILENAME          write output to FILENAME (optional)
      -d, --decoder ID               use a specific decoder (see --list-decoders)
          --with-aux                 also write auxiliary images (e.g. depth images)
          --with-xmp                 write XMP metadata to file (output filename with .xmp suffix)
          --with-exif                write EXIF metadata to file (output filename with .exif suffix)
          --skip-exif-offset         skip EXIF metadata offset bytes
          --no-colons                replace ':' characters in auxiliary image filenames with '_'
          --list-decoders            list all available decoders (built-in and plugins)
          --quiet                    do not output status messages to console
      -C, --chroma-upsampling ALGO   Force chroma upsampling algorithm (nn = nearest-neighbor / bilinear)
          --png-compression-level #  Set to integer between 0 (fastest) and 9 (best). Use -1 for default.
    

**Replay**

    cd libheif
    mkdir build && cd build
    CC="gcc -fsanitize=address" CXX="g++ -fsanitize=address" cmake --preset=release ..
    make -j
    ./examples/heif-convert ./poc test.png
    

**ASAN**

    ==1926429==ERROR: AddressSanitizer: SEGV on unknown address 0x60b080000729 (pc 0x55abe2b1012c bp 0x000000000000 sp 0x7ffe0b2df5a0 T0)
    ==1926429==The signal is caused by a READ memory access.
        #0 0x55abe2b1012c in read16 /eva/put/libheif/libheif/exif.cc:55
        #1 0x55abe2b1012c in find_exif_tag /eva/put/libheif/libheif/exif.cc:103
        #2 0x55abe2b1136b in modify_exif_tag_if_it_exists(unsigned char*, int, unsigned short, unsigned short) /eva/put/libheif/libheif/exif.cc:124
        #3 0x55abe2b1136b in modify_exif_orientation_tag_if_it_exists(unsigned char*, int, unsigned short) /eva/put/libheif/libheif/exif.cc:140
        #4 0x55abe2b16c75 in PngEncoder::Encode(heif_image_handle const*, heif_image const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) /eva/put/libheif/examples/encoder_png.cc:126
        #5 0x55abe2b00c99 in main /eva/put/libheif/examples/heif_convert.cc:509
        #6 0x7fb15dc29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
        #7 0x7fb15dc29e3f in __libc_start_main_impl ../csu/libc-start.c:392
        #8 0x55abe2b09254 in _start (/eva/asan-bin/NestFuzz/libheif/heif-convert+0x15254)
    
    AddressSanitizer can not provide additional info.
    SUMMARY: AddressSanitizer: SEGV /eva/put/libheif/libheif/exif.cc:55 in read16
    ==1926429==ABORTING
    

**POC**

poc

**Environment**

    Description:	Ubuntu 22.04.2 LTS
    gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
    

**Credit**

Yuchuan Meng (Fudan University)

CVE-2023-49462: SEGV libheif/libheif/exif.cc:55 in read16 · Issue #1043 · strukturag/libheif

libheif v1.17.5 was discovered to contain a segmentation violation via the function UncompressedImageCodec::get_luma_bits_per_pixel_from_configuration_unci.

**Description**

heap-use-after-free/SEGV/heap-buffer-overflow libheif/libheif/uncompressed_image.cc:537 in UncompressedImageCodec::get_luma_bits_per_pixel_from_configuration_unci

**Version**

    commit: 64ece913266609789f5dc70fe7de9eb759badd7f
    
    heif-convert  libheif version: 1.17.5
    -------------------------------------------
    Usage: heif-convert [options]  <input-image> [output-image]
    
    The program determines the output file format from the output filename suffix.
    These suffixes are recognized: jpg, jpeg, png, y4m. If no output filename is specified, 'jpg' is used.
    
    Options:
      -h, --help                     show help
      -v, --version                  show version
      -q, --quality                  quality (for JPEG output)
      -o, --output FILENAME          write output to FILENAME (optional)
      -d, --decoder ID               use a specific decoder (see --list-decoders)
          --with-aux                 also write auxiliary images (e.g. depth images)
          --with-xmp                 write XMP metadata to file (output filename with .xmp suffix)
          --with-exif                write EXIF metadata to file (output filename with .exif suffix)
          --skip-exif-offset         skip EXIF metadata offset bytes
          --no-colons                replace ':' characters in auxiliary image filenames with '_'
          --list-decoders            list all available decoders (built-in and plugins)
          --quiet                    do not output status messages to console
      -C, --chroma-upsampling ALGO   Force chroma upsampling algorithm (nn = nearest-neighbor / bilinear)
          --png-compression-level #  Set to integer between 0 (fastest) and 9 (best). Use -1 for default.
    

**Replay**

    cd libheif
    mkdir build && cd build
    CC="gcc -fsanitize=address" CXX="g++ -fsanitize=address" cmake -DCMAKE_BUILD_TYPE=Debug -DWITH_UNCOMPRESSED_CODEC=ON ..
    make -j
    ./examples/heif-convert ./poc test.png
    

**ASAN**

> I just show the uaf case, you can use my poc to reproduce the others.

    ==88148==ERROR: AddressSanitizer: heap-use-after-free on address 0x60e000000910 at pc 0x7f7a88d9ab47 bp 0x7ffef17996e0 sp 0x7ffef17996d0
    READ of size 2 at 0x60e000000910 thread T0
        #0 0x7f7a88d9ab46 in UncompressedImageCodec::get_luma_bits_per_pixel_from_configuration_unci(HeifFile const&, unsigned int) libheif/libheif/uncompressed_image.cc:537
        #1 0x7f7a88c96f95 in HeifFile::get_luma_bits_per_pixel_from_configuration(unsigned int) const libheif/libheif/file.cc:609
        #2 0x7f7a88c58d54 in HeifContext::Image::get_luma_bits_per_pixel() const libheif/libheif/context.cc:1225
        #3 0x7f7a88c1abf7 in heif_image_handle_get_luma_bits_per_pixel libheif/libheif/heif.cc:846
        #4 0x55fa40c34835 in main libheif/examples/heif_convert.cc:475
        #5 0x7f7a88694082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082)
        #6 0x55fa40c2fadd in _start (libheif/build/examples/heif-convert+0xbadd)
    
    0x60e000000910 is located 16 bytes inside of 160-byte region [0x60e000000900,0x60e0000009a0)
    freed by thread T0 here:
        #0 0x7f7a88f6c0d0 in operator delete(void*) (/lib/x86_64-linux-gnu/libasan.so.4+0xe20d0)
        #1 0x7f7a88c038d9 in __gnu_cxx::new_allocator<std::_Sp_counted_ptr_inplace<Box_hdlr, std::allocator<Box_hdlr>, (__gnu_cxx::_Lock_policy)2> >::deallocate(std::_Sp_counted_ptr_inplace<Box_hdlr, std::allocator<Box_hdlr>, (__gnu_cxx::_Lock_policy)2>*, unsigned long) /usr/include/c++/7/ext/new_allocator.h:125
        #2 0x7f7a88bfef61 in std::allocator_traits<std::allocator<std::_Sp_counted_ptr_inplace<Box_hdlr, std::allocator<Box_hdlr>, (__gnu_cxx::_Lock_policy)2> > >::deallocate(std::allocator<std::_Sp_counted_ptr_inplace<Box_hdlr, std::allocator<Box_hdlr>, (__gnu_cxx::_Lock_policy)2> >&, std::_Sp_counted_ptr_inplace<Box_hdlr, std::allocator<Box_hdlr>, (__gnu_cxx::_Lock_policy)2>*, unsigned long) /usr/include/c++/7/bits/alloc_traits.h:462
        #3 0x7f7a88bf4553 in std::__allocated_ptr<std::allocator<std::_Sp_counted_ptr_inplace<Box_hdlr, std::allocator<Box_hdlr>, (__gnu_cxx::_Lock_policy)2> > >::~__allocated_ptr() /usr/include/c++/7/bits/allocated_ptr.h:73
        #4 0x7f7a88c1019d in std::_Sp_counted_ptr_inplace<Box_hdlr, std::allocator<Box_hdlr>, (__gnu_cxx::_Lock_policy)2>::_M_destroy() /usr/include/c++/7/bits/shared_ptr_base.h:543
        #5 0x7f7a88b94163 in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() /usr/include/c++/7/bits/shared_ptr_base.h:170
        #6 0x7f7a88b938c3 in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count() /usr/include/c++/7/bits/shared_ptr_base.h:684
        #7 0x7f7a88bc23e3 in std::__shared_ptr<Box, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr() /usr/include/c++/7/bits/shared_ptr_base.h:1123
        #8 0x7f7a88bc24a3 in std::shared_ptr<Box>::~shared_ptr() /usr/include/c++/7/bits/shared_ptr.h:93
        #9 0x7f7a88be9854 in void std::_Destroy<std::shared_ptr<Box> >(std::shared_ptr<Box>*) /usr/include/c++/7/bits/stl_construct.h:98
        #10 0x7f7a88be4eb8 in void std::_Destroy_aux<false>::__destroy<std::shared_ptr<Box>*>(std::shared_ptr<Box>*, std::shared_ptr<Box>*) /usr/include/c++/7/bits/stl_construct.h:108
        #11 0x7f7a88bdafef in void std::_Destroy<std::shared_ptr<Box>*>(std::shared_ptr<Box>*, std::shared_ptr<Box>*) /usr/include/c++/7/bits/stl_construct.h:137
        #12 0x7f7a88bce3b8 in void std::_Destroy<std::shared_ptr<Box>*, std::shared_ptr<Box> >(std::shared_ptr<Box>*, std::shared_ptr<Box>*, std::allocator<std::shared_ptr<Box> >&) /usr/include/c++/7/bits/stl_construct.h:206
        #13 0x7f7a88bc3acf in std::vector<std::shared_ptr<Box>, std::allocator<std::shared_ptr<Box> > >::~vector() /usr/include/c++/7/bits/stl_vector.h:434
        #14 0x7f7a88bc02f8 in Box::~Box() (libheif/build/libheif/libheif.so.1+0xa22f8)
        #15 0x7f7a88bc053e in FullBox::~FullBox() (libheif/build/libheif/libheif.so.1+0xa253e)
        #16 0x7f7a88c09a8c in Box_meta::~Box_meta() (libheif/build/libheif/libheif.so.1+0xeba8c)
        #17 0x7f7a88c12579 in void __gnu_cxx::new_allocator<Box_meta>::destroy<Box_meta>(Box_meta*) /usr/include/c++/7/ext/new_allocator.h:140
        #18 0x7f7a88c111de in void std::allocator_traits<std::allocator<Box_meta> >::destroy<Box_meta>(std::allocator<Box_meta>&, Box_meta*) /usr/include/c++/7/bits/alloc_traits.h:487
        #19 0x7f7a88c10310 in std::_Sp_counted_ptr_inplace<Box_meta, std::allocator<Box_meta>, (__gnu_cxx::_Lock_policy)2>::_M_dispose() /usr/include/c++/7/bits/shared_ptr_base.h:535
        #20 0x7f7a88b940ec in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() /usr/include/c++/7/bits/shared_ptr_base.h:154
        #21 0x7f7a88b938c3 in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count() /usr/include/c++/7/bits/shared_ptr_base.h:684
        #22 0x7f7a88bc23e3 in std::__shared_ptr<Box, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr() /usr/include/c++/7/bits/shared_ptr_base.h:1123
        #23 0x7f7a88bc24a3 in std::shared_ptr<Box>::~shared_ptr() /usr/include/c++/7/bits/shared_ptr.h:93
        #24 0x7f7a88b9d8b5 in Box::read(BitstreamRange&, std::shared_ptr<Box>*) libheif/libheif/box.cc:436
        #25 0x7f7a88b9edac in Box::read_children(BitstreamRange&, int) libheif/libheif/box.cc:749
        #26 0x7f7a88bab707 in Box_iprp::parse(BitstreamRange&) libheif/libheif/box.cc:1731
        #27 0x7f7a88b9d7eb in Box::read(BitstreamRange&, std::shared_ptr<Box>*) libheif/libheif/box.cc:672
        #28 0x7f7a88b9edac in Box::read_children(BitstreamRange&, int) libheif/libheif/box.cc:749
        #29 0x7f7a88ba14a0 in Box_meta::parse(BitstreamRange&) libheif/libheif/box.cc:920
    
    previously allocated by thread T0 here:
        #0 0x7f7a88f6b258 in operator new(unsigned long) (/lib/x86_64-linux-gnu/libasan.so.4+0xe1258)
        #1 0x7f7a88c038a8 in __gnu_cxx::new_allocator<std::_Sp_counted_ptr_inplace<Box_hdlr, std::allocator<Box_hdlr>, (__gnu_cxx::_Lock_policy)2> >::allocate(unsigned long, void const*) /usr/include/c++/7/ext/new_allocator.h:111
        #2 0x7f7a88bfeeb4 in std::allocator_traits<std::allocator<std::_Sp_counted_ptr_inplace<Box_hdlr, std::allocator<Box_hdlr>, (__gnu_cxx::_Lock_policy)2> > >::allocate(std::allocator<std::_Sp_counted_ptr_inplace<Box_hdlr, std::allocator<Box_hdlr>, (__gnu_cxx::_Lock_policy)2> >&, unsigned long) /usr/include/c++/7/bits/alloc_traits.h:436
        #3 0x7f7a88bf44b9 in std::__allocated_ptr<std::allocator<std::_Sp_counted_ptr_inplace<Box_hdlr, std::allocator<Box_hdlr>, (__gnu_cxx::_Lock_policy)2> > > std::__allocate_guarded<std::allocator<std::_Sp_counted_ptr_inplace<Box_hdlr, std::allocator<Box_hdlr>, (__gnu_cxx::_Lock_policy)2> > >(std::allocator<std::_Sp_counted_ptr_inplace<Box_hdlr, std::allocator<Box_hdlr>, (__gnu_cxx::_Lock_policy)2> >&) /usr/include/c++/7/bits/allocated_ptr.h:104
        #4 0x7f7a88bea393 in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::__shared_count<Box_hdlr, std::allocator<Box_hdlr>>(std::_Sp_make_shared_tag, Box_hdlr*, std::allocator<Box_hdlr> const&) /usr/include/c++/7/bits/shared_ptr_base.h:635
        #5 0x7f7a88be5955 in std::__shared_ptr<Box_hdlr, (__gnu_cxx::_Lock_policy)2>::__shared_ptr<std::allocator<Box_hdlr>>(std::_Sp_make_shared_tag, std::allocator<Box_hdlr> const&) /usr/include/c++/7/bits/shared_ptr_base.h:1295
        #6 0x7f7a88bdc441 in std::shared_ptr<Box_hdlr>::shared_ptr<std::allocator<Box_hdlr>>(std::_Sp_make_shared_tag, std::allocator<Box_hdlr> const&) /usr/include/c++/7/bits/shared_ptr.h:344
        #7 0x7f7a88bcf8a2 in std::shared_ptr<Box_hdlr> std::allocate_shared<Box_hdlr, std::allocator<Box_hdlr>>(std::allocator<Box_hdlr> const&) /usr/include/c++/7/bits/shared_ptr.h:691
        #8 0x7f7a88bc4768 in std::shared_ptr<Box_hdlr> std::make_shared<Box_hdlr>() /usr/include/c++/7/bits/shared_ptr.h:707
        #9 0x7f7a88b9bcf3 in Box::read(BitstreamRange&, std::shared_ptr<Box>*) libheif/libheif/box.cc:448
        #10 0x7f7a88b9edac in Box::read_children(BitstreamRange&, int) libheif/libheif/box.cc:749
        #11 0x7f7a88ba14a0 in Box_meta::parse(BitstreamRange&) libheif/libheif/box.cc:920
        #12 0x7f7a88b9d7eb in Box::read(BitstreamRange&, std::shared_ptr<Box>*) libheif/libheif/box.cc:672
        #13 0x7f7a88b9edac in Box::read_children(BitstreamRange&, int) libheif/libheif/box.cc:749
        #14 0x7f7a88bab707 in Box_iprp::parse(BitstreamRange&) libheif/libheif/box.cc:1731
        #15 0x7f7a88b9d7eb in Box::read(BitstreamRange&, std::shared_ptr<Box>*) libheif/libheif/box.cc:672
        #16 0x7f7a88b9edac in Box::read_children(BitstreamRange&, int) libheif/libheif/box.cc:749
        #17 0x7f7a88ba14a0 in Box_meta::parse(BitstreamRange&) libheif/libheif/box.cc:920
        #18 0x7f7a88b9d7eb in Box::read(BitstreamRange&, std::shared_ptr<Box>*) libheif/libheif/box.cc:672
        #19 0x7f7a88b9edac in Box::read_children(BitstreamRange&, int) libheif/libheif/box.cc:749
        #20 0x7f7a88ba14a0 in Box_meta::parse(BitstreamRange&) libheif/libheif/box.cc:920
        #21 0x7f7a88b9d7eb in Box::read(BitstreamRange&, std::shared_ptr<Box>*) libheif/libheif/box.cc:672
        #22 0x7f7a88c9217e in HeifFile::parse_heif_file(BitstreamRange&) libheif/libheif/file.cc:254
        #23 0x7f7a88c8ffc6 in HeifFile::read(std::shared_ptr<StreamReader> const&) libheif/libheif/file.cc:107
        #24 0x7f7a88c8f8c6 in HeifFile::read_from_file(char const*) libheif/libheif/file.cc:88
        #25 0x7f7a88c4b3d7 in HeifContext::read_from_file(char const*) libheif/libheif/context.cc:429
        #26 0x7f7a88c163ff in heif_context_read_from_file libheif/libheif/heif.cc:451
        #27 0x55fa40c33e68 in main libheif/examples/heif_convert.cc:410
        #28 0x7f7a88694082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082)
    
    SUMMARY: AddressSanitizer: heap-use-after-free libheif/libheif/uncompressed_image.cc:537 in UncompressedImageCodec::get_luma_bits_per_pixel_from_configuration_unci(HeifFile const&, unsigned int)
    Shadow bytes around the buggy address:
      0x0c1c7fff80d0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
      0x0c1c7fff80e0: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd
      0x0c1c7fff80f0: fd fd fd fd fd fd fd fd fd fd fd fd fa fa fa fa
      0x0c1c7fff8100: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fd
      0x0c1c7fff8110: fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa fa
    =>0x0c1c7fff8120: fd fd[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd
      0x0c1c7fff8130: fd fd fd fd fa fa fa fa fa fa fa fa fd fd fd fd
      0x0c1c7fff8140: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fa
      0x0c1c7fff8150: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd
      0x0c1c7fff8160: fd fd fd fd fd fd fd fd fd fd fd fd fa fa fa fa
      0x0c1c7fff8170: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fd
    Shadow byte legend (one shadow byte represents 8 application bytes):
      Addressable:           00
      Partially addressable: 01 02 03 04 05 06 07
      Heap left redzone:       fa
      Freed heap region:       fd
      Stack left redzone:      f1
      Stack mid redzone:       f2
      Stack right redzone:     f3
      Stack after return:      f5
      Stack use after scope:   f8
      Global redzone:          f9
      Global init order:       f6
      Poisoned by user:        f7
      Container overflow:      fc
      Array cookie:            ac
      Intra object redzone:    bb
      ASan internal:           fe
      Left alloca redzone:     ca
      Right alloca redzone:    cb
    ==88148==ABORTING
    

**POC**

*   poc-heap-overflow
*   poc-heap-uaf
*   poc-segv

**Environment**

    Description:	Ubuntu 22.04.2 LTS
    gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
    

**Credit**

Yuchuan Meng (Fudan University)

CVE-2023-49464: heap-use-after-free/SEGV/heap-buffer-overflow in UncompressedImageCodec::get_luma_bits_per_pixel_from_configuration_unci · Issue #1044 · strukturag/libheif

libheif v1.17.5 was discovered to contain a segmentation violation via the function find_exif_tag at /libheif/exif.cc.

**Description**

SEGV libheif/libheif/exif.cc:88 in find_exif_tag

**Version**

     heif-convert  libheif version: 1.17.5
    -------------------------------------------
    Usage: heif-convert [options]  <input-image> [output-image]
    
    The program determines the output file format from the output filename suffix.
    These suffixes are recognized: jpg, jpeg, png, y4m. If no output filename is specified, 'jpg' is used.
    
    Options:
      -h, --help                     show help
      -v, --version                  show version
      -q, --quality                  quality (for JPEG output)
      -o, --output FILENAME          write output to FILENAME (optional)
      -d, --decoder ID               use a specific decoder (see --list-decoders)
          --with-aux                 also write auxiliary images (e.g. depth images)
          --with-xmp                 write XMP metadata to file (output filename with .xmp suffix)
          --with-exif                write EXIF metadata to file (output filename with .exif suffix)
          --skip-exif-offset         skip EXIF metadata offset bytes
          --no-colons                replace ':' characters in auxiliary image filenames with '_'
          --list-decoders            list all available decoders (built-in and plugins)
          --quiet                    do not output status messages to console
      -C, --chroma-upsampling ALGO   Force chroma upsampling algorithm (nn = nearest-neighbor / bilinear)
          --png-compression-level #  Set to integer between 0 (fastest) and 9 (best). Use -1 for default.
    

**Replay**

    cd libheif
    mkdir build && cd build
    CC="gcc -fsanitize=address" CXX="g++ -fsanitize=address" cmake --preset=release ..
    make -j
    ./examples/heif-convert ./poc test.png
    

**ASAN**

    =================================================================
    ==216883==ERROR: AddressSanitizer: SEGV on unknown address 0x60b0b184d2bc (pc 0x55f4628c3ca8 bp 0x00004e7b34c8 sp 0x7ffe414d49b0 T0)
    ==216883==The signal is caused by a READ memory access.
        #0 0x55f4628c3ca8 in find_exif_tag eva/put/libheif/libheif/exif.cc:88
        #1 0x55f4628c536b in modify_exif_tag_if_it_exists(unsigned char*, int, unsigned short, unsigned short) eva/put/libheif/libheif/exif.cc:124
        #2 0x55f4628c536b in modify_exif_orientation_tag_if_it_exists(unsigned char*, int, unsigned short) eva/put/libheif/libheif/exif.cc:140
        #3 0x55f4628cac75 in PngEncoder::Encode(heif_image_handle const*, heif_image const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) eva/put/libheif/examples/encoder_png.cc:126
        #4 0x55f4628b4c99 in main eva/put/libheif/examples/heif_convert.cc:509
        #5 0x7fb342a29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
        #6 0x7fb342a29e3f in __libc_start_main_impl ../csu/libc-start.c:392
        #7 0x55f4628bd254 in _start (eva/put/libheif/build/examples/heif-convert+0x15254)
    
    AddressSanitizer can not provide additional info.
    SUMMARY: AddressSanitizer: SEGV eva/put/libheif/libheif/exif.cc:88 in find_exif_tag
    ==216883==ABORTING
    

**POC**

poc

**Environment**

    Description:	Ubuntu 22.04.2 LTS
    gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
    

**Credit**

Yuchuan Meng (Fudan University)

Tag

#chrome