As Chinese automakers prepare to launch in the US, the White House is investigating whether cars made in China could pose a national security threat.

The US government has launched an investigation into the national security risks posed by foreign-made vehicles with internet connectivity—especially those made in China. At a briefing on Wednesday, Secretary of Commerce Gina Raimondo even raised the specter of Beijing remotely triggering mayhem on US highways.

“Imagine if there were thousands or hundreds of thousands of Chinese connected vehicles on American roads that could be immediately and simultaneously disabled by somebody in Beijing,” Raimondo said.

The new US government fears about Chinese autos come as automakers such as BYD and Geely have become major global players in car manufacturing—and particularly electric vehicles. They also build on evidence that as cars have become increasingly computerized, and connected to the internet, vehicles have become vulnerable to new security threats. Hackers have shown it is possible to disable internet-connected vehicles from afar. Automated driving systems and internet connectivity have added cameras and other sensors to vehicles, and can also make them mobile repositories of personal information.

Raimondo said that the Bureau of Industry and Security, a division of the Commerce Department that handles national security issues related to advanced technology, would explore how sensor-laden, internet-connected vehicles could be used to commit espionage, collect data on US citizens, or commit sabotage on US roads.

The alarm sounded about Chinese autos adds to a recent history of US government concern about China’s technology ambitions under President Joe Biden and under President Trump before him. Trump imposed sanctions on Chinese telecoms equipment maker Huawei and other 5G companies working on 5G wireless technology and targeted Chinese AI firms with similar controls. The Biden administration has aggressively restricted the flow of advanced chips into China. Concerns over sensitive US data passing back to China has led to a TikTok ban for most federal government devices.

The move comes as US automakers miss targets for EV sales, and as Chinese automakers such as BYD tout record global sales and build new factories. Many Chinese manufacturers are producing cars, and particularly EVs, more efficiently and profitably than their US counterparts, with billions in assistance from the central government.

In January, BYD overtook Tesla as the world’s leading manufacturer of EVs, according to figures released by the two companies. Last year, China became the world’s biggest car exporter.

“China is determined to dominate the future of the auto market, including by using unfair practices,” reads a statement from Biden released by the White House. “China’s policies could flood our market with its vehicles, posing risks to our national security. I’m not going to let that happen on my watch.”

Rising Power

China’s automakers are expected to soon begin a direct assault on the US market. Recent news reports suggest that Chinese automakers including BYD, MG, and Chery plan to manufacture their lower-cost electric vehicles in Mexico, enabling them to take advantage of North American trade treaties and evade US tariffs of 27.5 percent on imported Chinese autos.

The Alliance for American Manufacturing, a trade group, earlier this month called China a “significant” threat to US car manufacturers. It urged US policymakers to “adopt a proactive and evolving strategy to stymie the CCP’s penetration.”

Speaking at the briefing Wednesday, Lael Brainard, national economic adviser to the White House, described US automakers being on a competitive playing field that appears to be rapidly tilting in favor of Chinese automakers. “For years China has employed an array of subsidies and protections to build massive capacity in EV production,” Brainard said. “Chinese automakers are now flooding foreign markets with their autos.”

The security risks posed by vehicles have grown as they’ve become more computerized, more sensor-filled, and more connected. Anne Neuberger, the Biden administration’s deputy national security adviser for cyber, recently told WIRED that the US is working with allies to develop standards for autonomous vehicles that would address the risks they pose. Neurberger said the administration is concerned about Chinese autonomous vehicles that have been approved for testing on US roads.

Administration officials say that the investigation would extend to Chinese-made components and other technologies. This could include the lidar systems that use lasers to map roads and spot obstacles, a market in which Chinese companies are major players.

Officials note that China has imposed restrictions on connected vehicles from US companies. Tesla cars are reportedly restricted from driving in military- and government-affiliated areas, including meeting halls and exhibition centers, for instance.

The move will risk ratcheting up tension between the US and China. If the action leads to trade restrictions, it could be met with counter restrictions from Beijing. “We'll have to wait to see what China's retaliation might be,” a senior administration official said.

The White House Warns Cars Made in China Could Unleash Chaos on US Highways

Anne Neuberger, the Biden administration’s deputy national security adviser for cyber, tells WIRED about emerging cybersecurity threats—and what the US plans to do about them.

Anne Neuberger, a Top White House Cyber Official, Sees the 'Promise and Peril' in AI

A Huawei data communication product has a command injection vulnerability. Successful exploitation of this vulnerability may allow attackers to gain higher privileges.

CVE-2022-48616: Huawei NetEngine AR617VW Authenticated Root RaCE

A collection of security flaws in the firmware implementation of 5G mobile network modems from major chipset vendors such as MediaTek and Qualcomm impact USB and IoT modems as well as hundreds of smartphone models running Android and iOS.
Of the 14 flaws – collectively called 5Ghoul (a combination of "5G" and "Ghoul") – 10 affect 5G modems from the two companies, out of which three

Vulnerability / Mobile Network

A collection of security flaws in the firmware implementation of 5G mobile network modems from major chipset vendors such as MediaTek and Qualcomm impact USB and IoT modems as well as hundreds of smartphone models running Android and iOS.

Of the 14 flaws – collectively called **5Ghoul** (a combination of "5G" and "Ghoul") – 10 affect 5G modems from the two companies, out of which three have been classified as high-severity vulnerabilities.

"5Ghoul vulnerabilities may be exploited to continuously launch attacks to drop the connections, freeze the connection that involve manual reboot or downgrade the 5G connectivity to 4G," the researchers said in a study published today.

As many as 714 smartphones from 24 brands are impacted, including those from Vivo, Xiaomi, OPPO, Samsung, Honor, Motorola, realme, OnePlus, Huawei, ZTE, Asus, Sony, Meizu, Nokia, Apple, and Google.

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

The vulnerabilities were disclosed by a team of researchers from the ASSET (Automated Systems SEcuriTy) Research Group at the Singapore University of Technology and Design (SUTD), who also previously disclosed BrakTooth in September 2021 and SweynTooth in February 2020.

The attacks, in a nutshell, attempt to deceive a smartphone or a 5G-enabled device to connect a rogue base station (gNB), resulting in unintended consequences.

"The attacker does not need to be aware of any secret information of the target UE e.g., UE's SIM card details, to complete the NAS network registration," the researchers explained. "The attacker only needs to impersonate the legitimate gNB using the known Cell Tower connection parameters."

A threat actor can accomplish this by using apps like Cellular-Pro to determine the Relative Signal Strength Indicator (RSSI) readings and trick the user equipment to connect to the adversarial station (i.e., a software-defined radio) as well as an inexpensive mini PC.

Notable among the 14 flaws is CVE-2023-33042, which can permit an attacker within radio range to trigger a 5G connectivity downgrade or a denial-of-service (DoS) within Qualcomm's X55/X60 modem firmware by sending malformed Radio Resource Control (RRC) frame to the target 5G device from a nearby malicious gNB.

Successful exploitation of the other DoS vulnerabilities could require a manual reboot of the device to restore 5G connectivity.

Patches have been released by both MediaTek and Qualcomm for 12 of the 14 flaws. Details of the two other vulnerabilities have been withheld due to confidentiality reasons and are expected to be disclosed in the future.

"Finding issues in the implementation of the 5G modem vendor heavily impacts product vendors downstream," the researchers said, adding that "it can often take six or more months for 5G security patches to finally reach the end-user via an OTA update."

"This is because the software dependency of product vendors on the Modem / Chipset Vendor adds complexity and hence delays to the process of producing and distributing patches to the end-user."

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

New 5G Modems Flaws Affect iOS Devices and Android Models from Major Brands

Permission management vulnerability in the module for disabling Sound Booster. Successful exploitation of this vulnerability may cause features to perform abnormally.

HUAWEI is releasing monthly security updates for flagship models. This security update includes HUAWEI and third-party library patches:

This security update includes the following third-party library patches:

This security update includes the CVE announced in the November 2023 Android security bulletin:

Critical: none

High: CVE-2023-40104, CVE-2023-40111, CVE-2023-40112, CVE-2023-40110, CVE-2023-40114, CVE-2023-40105, CVE-2023-40106, CVE-2023-40109, CVE-2023-40115, CVE-2023-40100, CVE-2023-33031, CVE-2023-33055, CVE-2023-33059

Medium: CVE-2023-28572, CVE-2023-28553

Low: none

Already included in previous updates: CVE-2022-29824, CVE-2023-21253, CVE-2021-44828, CVE-2022-28348, CVE-2023-33200, CVE-2023-4211, CVE-2023-21237, CVE-2022-20264, CVE-2022-27404, CVE-2023-21295, CVE-2023-21308, CVE-2023-21311, CVE-2023-21319, CVE-2023-21320, CVE-2023-21326, CVE-2023-21331, CVE-2023-21344, CVE-2023-21346, CVE-2023-21348, CVE-2023-21349, CVE-2023-21355, CVE-2023-21369, CVE-2023-21372, CVE-2023-21374, CVE-2023-21388

※ For more information on security patches, please refer to the Android security bulletins (https://source.android.com/security/bulletin).

This security update includes the following HUAWEI patches:

CVE-2023-44099: Vulnerability of data verification errors in the kernel module

Severity: Medium

Affected versions: EMUI 12.0.0

Impact: Successful exploitation of this vulnerability may cause WLAN interruption.

CVE-2023-44113: Vulnerability of missing permission verification for APIs in the Designed for Reliability (DFR) module

Severity: Medium

Affected versions: EMUI 13.0.0

Impact: Successful exploitation of this vulnerability may affect service confidentiality.

CVE-2023-46773: Permission management vulnerability in the PMS module

Severity: High

Affected versions: EMUI 13.0.0

Impact: Successful exploitation of this vulnerability may cause privilege escalation.

CVE-2023-49239: Unauthorized access vulnerability in the card management module

Severity: Medium

Affected versions: EMUI 13.0.0, EMUI 12.0.0, EMUI 11.0.1

Impact: Successful exploitation of this vulnerability may affect service confidentiality.

CVE-2023-49240: Unauthorized access vulnerability in the launcher module

Severity: Medium

Affected versions: EMUI 13.0.0, EMUI 12.0.0, EMUI 11.0.1

Impact: Successful exploitation of this vulnerability may affect service confidentiality.

CVE-2023-49241: API permission control vulnerability in the network management module

Severity: Medium

Affected versions: EMUI 13.0.0, EMUI 12.0.0, EMUI 11.0.1

Impact: Successful exploitation of this vulnerability may affect service confidentiality.

CVE-2023-49242: Free broadcast vulnerability in the running management module

Severity: Medium

Affected versions: EMUI 13.0.0, EMUI 12.0.0, EMUI 11.0.1

Impact: Successful exploitation of this vulnerability may affect service confidentiality.

CVE-2023-49243: Vulnerability of unauthorized access to email attachments in the email module

Severity: Medium

Affected versions: EMUI 13.0.0, EMUI 12.0.0, EMUI 11.0.1

Impact: Successful exploitation of this vulnerability may affect service confidentiality.

CVE-2023-49244: Permission management vulnerability in the multi-user module

Severity: Medium

Affected versions: EMUI 13.0.0

Impact: Successful exploitation of this vulnerability may affect service confidentiality.

CVE-2023-49245: Unauthorized access vulnerability in the HUAWEI Share module

Severity: Medium

Affected versions: EMUI 13.0.0, EMUI 12.0.0, EMUI 11.0.1

Impact: Successful exploitation of this vulnerability may affect service confidentiality.

CVE-2023-49246: Unauthorized access vulnerability in the card management module

Severity: Medium

Affected versions: EMUI 13.0.0, EMUI 12.0.0, EMUI 11.0.1

Impact: Successful exploitation of this vulnerability may affect service confidentiality.

CVE-2023-49247: Permission verification vulnerability in distributed scenarios

Severity: High

Affected versions: EMUI 13.0.0, EMUI 12.0.0

Impact: Successful exploitation of this vulnerability may affect service confidentiality.

CVE-2023-49248: Vulnerability of unauthorized file access in the Settings app

Severity: High

Affected versions: EMUI 13.0.0, EMUI 12.0.0, EMUI 11.0.1

Impact: Successful exploitation of this vulnerability may cause unauthorized file access.

CVE-2023-6273: Permission management vulnerability in the module for disabling Sound Booster

Severity: Medium

Affected versions: EMUI 13.0.0, EMUI 12.0.0, EMUI 11.0.1

Impact: Successful exploitation of this vulnerability may cause features to perform abnormally.

CVE-2023-6273: December


The Bluetooth module of some Huawei Smart Screen products has an identity authentication bypass vulnerability. Successful exploitation of this vulnerability may allow attackers to access restricted functions. 

Successful exploitation of this vulnerability may allow attackers to access restricted functions.



The Bluetooth module of some Huawei Smart Screen products has an identity authentication bypass vulnerability. Successful exploitation of this vulnerability may allow attackers to access restricted functions.(Vulnerability ID:HWPSIRT-2023-82635)

This vulnerability has been assigned a (CVE) ID: CVE-2023-6514

Affected Product

Affected Version

Repair Version

AJMD-370S

AJMD-370S 103.1.0.110(SP12C00E2R1P2)

AJMD-370S 103.1.0.110(SP9C00E2R1P2)

  

HWPSIRT-2023-82635:

Successful exploitation of this vulnerability may allow attackers to access restricted functions.

Vulnerabilities are scored base on the CVSS v3.1 scoring system. For details please refer to: https://www.first.org/cvss/specification-document.

HWPSIRT-2023-82635:

Base Score: 8.8

Temporal Score: 8.8

Environmental Score: NA

CVSS v3.1 Vector: AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H/E:X/RL:X/RC:X

HWPSIRT-2023-82635:

This vulnerability can be exploited only when the following conditions are present:

The attacker successfully paired with the target device using Bluetooth.

Technical details:

Some Huawei Smart Screen products have an identity authentication bypass vulnerability. An attacker without any permission can pair the target device through Bluetooth. Successful exploitation of this vulnerability may allow the attacker to access restricted functions.

The product that supports automatic update will receive a system update prompt. You can install the update to fix the vulnerability.

HWPSIRT-2023-82635:

This vulnerability was discovered by Huawei internal tester.

2023-12-06 V1.0 is initially released.

Huawei adheres to protecting the ultimate interests of users with best efforts and the principle of responsible disclosure and deal with product security issues through our response mechanism.

To enjoy Huawei PSIRT services and obtain Huawei product vulnerability information, please visit http://www.huawei.com/en/psirt.

To report a security vulnerability in Huawei products and solutions, please send it to PSIRT@huawei.com. For details, please visit http://www.huawei.com/en/psirt/report-vulnerabilities.

This document is provided on an "AS IS" basis and does not imply any kind of guarantee or warranty, either express or implied, including the warranties of merchantability or fitness for a particular purpose. In no event shall Huawei or any of its directly or indirectly controlled subsidiaries or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages. Your use of the document, by whatsoever means, will be totally at your own risk. Huawei is entitled to amend or update this document from time to time.

CVE-2023-6514: Security Advisory - Identity Bypass Vulnerability in Some Huawei Smart Screen Products

In parse_gap_data of utils.cc, there is a possible out of bounds read due to a missing bounds check. This could lead to local information disclosure with User execution privileges needed. User interaction is not needed for exploitation.

_Published December 4, 2023_

The Android Security Bulletin contains details of security vulnerabilities affecting Android devices. Security patch levels of 2023-12-05 or later address all of these issues. To learn how to check a device's security patch level, see Check and update your Android version.

Android partners are notified of all issues at least a month before publication. Source code patches for these issues will be released to the Android Open Source Project (AOSP) repository in the next 48 hours. We will revise this bulletin with the AOSP links when they are available.

The most severe of these issues is a critical security vulnerability in the System component that could lead to remote (proximal/adjacent) code execution with no additional execution privileges needed. User interaction is not needed for exploitation. The severity assessment is based on the effect that exploiting the vulnerability would possibly have on an affected device, assuming the platform and service mitigations are turned off for development purposes or if successfully bypassed.

Refer to the Android and Google Play Protect mitigations section for details on the Android security platform protections and Google Play Protect, which improve the security of the Android platform.

**Android and Google service mitigations**

This is a summary of the mitigations provided by the Android security platform and service protections such as Google Play Protect. These capabilities reduce the likelihood that security vulnerabilities could be successfully exploited on Android.

*   Exploitation for many issues on Android is made more difficult by enhancements in newer versions of the Android platform. We encourage all users to update to the latest version of Android where possible.
*   The Android security team actively monitors for abuse through Google Play Protect and warns users about Potentially Harmful Applications. Google Play Protect is enabled by default on devices with Google Mobile Services, and is especially important for users who install apps from outside of Google Play.

**2023-12-01 security patch level vulnerability details**

In the sections below, we provide details for each of the security vulnerabilities that apply to the 2023-12-01 patch level. Vulnerabilities are grouped under the component they affect. Issues are described in the tables below and include CVE ID, associated references, type of vulnerability, severity, and updated 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. Devices with Android 10 and later may receive security updates as well as Google Play system updates.

**Framework**

The most severe vulnerability in this section could lead to remote escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

    

CVE

References

Type

Severity

Updated AOSP versions

CVE-2023-40077

A-298057702

EoP

Critical

11, 12, 12L, 13, 14

CVE-2023-40076

A-303835719

ID

Critical

14

CVE-2023-40079

A-278722815

EoP

High

14

CVE-2023-40089

A-294228721

EoP

High

14

CVE-2023-40091

A-283699145

EoP

High

11, 12, 12L, 13, 14

CVE-2023-40094

A-288896339

EoP

High

11, 12, 12L, 13, 14

CVE-2023-40095

A-273729172

EoP

High

11, 12, 12L, 13, 14

CVE-2023-40096

A-268724205

EoP

High

11, 12, 12L, 13, 14

CVE-2023-40103

A-197260547

EoP

High

14

CVE-2023-45774

A-288113797

EoP

High

11, 12, 12L, 13, 14

CVE-2023-45777

A-299930871

EoP

High

13, 14

CVE-2023-21267

A-218495634

ID

High

11, 12, 12L, 13, 14

CVE-2023-40073

A-287640400

ID

High

11, 12, 12L, 13, 14

CVE-2023-40081

A-284297452

ID

High

11, 12, 12L, 13, 14

CVE-2023-40092

A-288110451

ID

High

11, 12, 12L, 13, 14

CVE-2023-40074

A-247513680

DoS

High

11, 12, 12L, 13

CVE-2023-40075

A-281061287

DoS

High

11, 12, 12L, 13, 14

**System**

The most severe vulnerability in this section could lead to remote (proximal/adjacent) code execution with no additional execution privileges needed. User interaction is not needed for exploitation.

    

CVE

References

Type

Severity

Updated AOSP versions

CVE-2023-40088

A-291500341

RCE

Critical

11, 12, 12L, 13, 14

CVE-2023-40078

A-275626001

EoP

High

14

CVE-2023-40080

A-275057843

EoP

High

13, 14

CVE-2023-40082

A-290909089

EoP

High

14

CVE-2023-40084

A-272382770

EoP

High

11, 12, 12L, 13, 14

CVE-2023-40087

A-275895309

EoP

High

11, 12, 12L, 13, 14

CVE-2023-40090

A-274478807

EoP

High

11, 12, 12L, 13, 14

CVE-2023-40097

A-295334906

EoP

High

11, 12, 12L, 13

CVE-2023-45773

A-275057847

EoP

High

13, 14

CVE-2023-45775

A-275340684

EoP

High

14

CVE-2023-45776

A-282234870

EoP

High

14

CVE-2023-21394

A-296915211

ID

High

11, 12, 12L, 13

CVE-2023-35668

A-283962802

ID

High

11, 12, 12L, 13

CVE-2023-40083

A-277590580

ID

High

12, 12L, 13, 14

CVE-2023-40098

A-288896269

ID

High

12, 12L, 13, 14

CVE-2023-45781

A-275553827

ID

High

12, 12L, 13, 14

**Google Play system updates**

There are no security issues addressed in Google Play system updates (Project Mainline) this month.

**2023-12-05 security patch level vulnerability details**

In the sections below, we provide details for each of the security vulnerabilities that apply to the 2023-12-05 patch level. Vulnerabilities are grouped under the component they affect. Issues are described in the tables below and include CVE ID, associated references, type of vulnerability, severity, and updated 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.

**System**

The vulnerability in this section could lead to remote (proximal/adjacent) escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

    

CVE

References

Type

Severity

Updated AOSP versions

CVE-2023-45866

A-294854926

EoP

Critical

11, 12, 12L, 13, 14

**Arm components**

These vulnerabilities affect Arm components and further details are available directly from Arm. The severity assessment of these issues is provided directly by Arm.

   

CVE

References

Severity

Subcomponent

CVE-2023-3889  

A-295942985 \*

High

Mali

CVE-2023-4272  

A-296910715 \*

High

Mali

CVE-2023-32804  

A-272772567 \*

High

Mali

**Imagination Technologies**

These vulnerabilities affect Imagination Technologies components and further details are available directly from Imagination Technologies. The severity assessment of these issues is provided directly by Imagination Technologies.

   

CVE

References

Severity

Subcomponent

CVE-2023-21162  

A-292004168 \*

High

PowerVR-GPU

CVE-2023-21163  

A-292003338 \*

High

PowerVR-GPU

CVE-2023-21164  

A-292002918 \*

High

PowerVR-GPU

CVE-2023-21166  

A-292002163 \*

High

PowerVR-GPU

CVE-2023-21215  

A-291982610 \*

High

PowerVR-GPU

CVE-2023-21216  

A-291999952 \*

High

PowerVR-GPU

CVE-2023-21217  

A-292087506 \*

High

PowerVR-GPU

CVE-2023-21218  

A-292000190 \*

High

PowerVR-GPU

CVE-2023-21228  

A-291999439 \*

High

PowerVR-GPU

CVE-2023-21263  

A-305095406 \*

High

PowerVR-GPU

CVE-2023-21401  

A-305091236 \*

High

PowerVR-GPU

CVE-2023-21402  

A-305093885 \*

High

PowerVR-GPU

CVE-2023-21403  

A-305096969 \*

High

PowerVR-GPU

CVE-2023-35690  

A-305095935 \*

High

PowerVR-GPU

CVE-2023-21227  

A-291998937 \*

High

PowerVR-GPU

**MediaTek components**

These vulnerabilities affect MediaTek components and further details are available directly from MediaTek. The severity assessment of these issues is provided directly by MediaTek.

   

CVE

References

Severity

Subcomponent

CVE-2023-32818  

A-294770901  
M-ALPS08013430, M-ALPS08163896 \*

High

vdec

CVE-2023-32847  

A-302982512  
M-ALPS08241940 \*

High

audio

CVE-2023-32848  

A-302982513  
M-ALPS08163896 \*

High

vdec

CVE-2023-32850  

A-302983201  
M-ALPS08016659 \*

High

decoder

CVE-2023-32851  

A-302986375  
M-ALPS08016652 \*

High

decoder

**Misc OEM**

This vulnerability affects Misc OEM components and further details are available directly from Misc OEM. The severity assessment of this issue is provided directly by Misc OEM.

   

CVE

References

Severity

Subcomponent

CVE-2023-45779  

A-301094654 \*

High

System UI

**Unisoc components**

These vulnerabilities affect Unisoc components and further details are available directly from Unisoc. The severity assessment of these issues is provided directly by Unisoc.

   

CVE

References

Severity

Subcomponent

CVE-2022-48456  

A-300376910  
U-1914157 \*

High

Kernel

CVE-2022-48461  

A-300368868  
U-1905646 \*

High

Kernel

CVE-2022-48454  

A-300382178  
U-2220123 \*

High

Android

CVE-2022-48455  

A-300385151  
U-2220123 \*

High

Android

CVE-2022-48457  

A-300368872  
U-2161952 \*

High

Android

CVE-2022-48458  

A-300368874  
U-2161952 \*

High

Android

CVE-2022-48459  

A-300368875  
U-2161952 \*

High

Android

**Qualcomm components**

These vulnerabilities affect Qualcomm components and are described in further detail in the appropriate Qualcomm security bulletin or security alert. The severity assessment of these issues is provided directly by Qualcomm.

   

CVE

References

Severity

Subcomponent

CVE-2023-28588  

A-285902729  
QC-CR#3417458

High

Bluetooth

CVE-2023-33053  

A-299146326  
QC-CR#3453941

High

Kernel

CVE-2023-33063  

A-266568298  
QC-CR#3447219 \[2\]

High

Kernel

CVE-2023-33079  

A-299146464  
QC-CR#3446191

High

Audio

CVE-2023-33087  

A-299146536  
QC-CR#3508356 \[2\]

High

Kernel

CVE-2023-33092  

A-299146537  
QC-CR#3507292

High

Bluetooth

CVE-2023-33106  

A-300941008  
QC-CR#3612841

High

Display

CVE-2023-33107  

A-299649795  
QC-CR#3611296

High

Display

**Qualcomm closed-source components**

These vulnerabilities affect Qualcomm closed-source components and are described in further detail in the appropriate Qualcomm security bulletin or security alert. The severity assessment of these issues is provided directly by Qualcomm.

   

CVE

References

Severity

Subcomponent

CVE-2022-40507  

A-261468680 \*

Critical

Closed-source component

CVE-2022-22076  

A-261469325 \*

High

Closed-source component

CVE-2023-21652  

A-268059928 \*

High

Closed-source component

CVE-2023-21662  

A-271879599 \*

High

Closed-source component

CVE-2023-21664  

A-271879160 \*

High

Closed-source component

CVE-2023-28546  

A-285902568 \*

High

Closed-source component

CVE-2023-28550  

A-280341535 \*

High

Closed-source component

CVE-2023-28551  

A-280341572 \*

High

Closed-source component

CVE-2023-28585  

A-285902652 \*

High

Closed-source component

CVE-2023-28586  

A-285903022 \*

High

Closed-source component

CVE-2023-28587  

A-285903202 \*

High

Closed-source component

CVE-2023-33017  

A-285902412 \*

High

Closed-source component

CVE-2023-33018  

A-285902728 \*

High

Closed-source component

CVE-2023-33022  

A-285903201 \*

High

Closed-source component

CVE-2023-33054  

A-295020170 \*

High

Closed-source component

CVE-2023-33080  

A-299147105 \*

High

Closed-source component

CVE-2023-33081  

A-299145668 \*

High

Closed-source component

CVE-2023-33088  

A-299146964 \*

High

Closed-source component

CVE-2023-33089  

A-299146027 \*

High

Closed-source component

CVE-2023-33097  

A-299147106 \*

High

Closed-source component

CVE-2023-33098  

A-299146466 \*

High

Closed-source component

**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?**

To learn how to check a device's security patch level, see Check and update your Android version.

*   Security patch levels of 2023-12-01 or later address all issues associated with the 2023-12-01 security patch level.
*   Security patch levels of 2023-12-05 or later address all issues associated with the 2023-12-05 security patch level and all previous patch levels.

Device manufacturers that include these updates should set the patch string level to:

*   \[ro.build.version.security\_patch\]:\[2023-12-01\]
*   \[ro.build.version.security\_patch\]:\[2023-12-05\]

For some devices on Android 10 or later, the Google Play system update will have a date string that matches the 2023-12-01 security patch level. Please see this article for more details on how to install security updates.

**2\. Why does this bulletin have two security patch levels?**

This bulletin has two security patch levels so that Android partners have the flexibility to fix a subset of vulnerabilities that are similar across all Android devices more quickly. Android partners are encouraged to fix all issues in this bulletin and use the latest security patch level.

*   Devices that use the 2023-12-01 security patch level must include all issues associated with that security patch level, as well as fixes for all issues reported in previous security bulletins.
*   Devices that use the security patch level of 2023-12-05 or newer must include all applicable patches in this (and previous) security bulletins.

Partners are encouraged to bundle the fixes for all issues they are addressing in a single update.

**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

QC-

Qualcomm reference number

M-

MediaTek reference number

N-

NVIDIA reference number

B-

Broadcom reference number

U-

UNISOC reference number

**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 corresponding reference ID. The update for that issue is generally contained in the latest binary drivers for Pixel devices available from the Google Developer site.

**6\. Why are security vulnerabilities split between this bulletin and device / partner security bulletins, such as the Pixel bulletin?**

Security vulnerabilities that are documented in this security bulletin are required to declare the latest security patch level on Android devices. Additional security vulnerabilities that are documented in the device / partner security bulletins are not required for declaring a security patch level. Android device and chipset manufacturers may also publish security vulnerability details specific to their products, such as Google, Huawei, LGE, Motorola, Nokia, or Samsung.

**Versions**

  

Version

Date

Notes

1.0

December 4, 2023

Bulletin published

CVE-2023-45781: Android Security Bulletin—December 2023

The BGP daemon (bgpd) in IP Infusion ZebOS through 7.10.6 allow remote attackers to cause a denial of service by sending crafted BGP update messages containing a malformed attribute.

**Aug 29 2023**

Border Gateway Protocol is the de facto protocol that directs routing decisions between different ISP networks, and is generally known as the “glue” that holds the internet together. It’s safe to say that the internet we currently know would not function without working BGP implementations.

However, the software on those networks’ routers (I will refer to these as edge devices from now on) that implements BGP has not had a flawless track record. Flaws and problems do exist in commercial and open source implementations of the world’s most critical routing protocol.

Most of these flaws are of course benign in the grand scheme of things; they will be issues around things like route filtering, or insertion, or handling withdraws. However a much more scary issue is a BGP bug that can propagate after causing bad behaviour, akin to a computer worm.

While debugging support for a future feature for my business (bgp.tools) I took a brief diversion to investigate something, and what I came out with might be one of the most concerning things I’ve discovered for the reliability of the internet. To understand the problems, though, we will need a bit more context.

**A mistaken attribute**

On 2 June 2023, a small Brazilian network (re)announced one of their internet routes with a small bit of information called an attribute that was corrupted. The information on this route was for a feature that had not finished standardisation, but was set up in such a way that if an intermediate router did not understand it, then the intermediate router would pass it on unchanged.

As many routers did not understand this attribute, this was no problem for them. They just took the information and propagated it along. However it turned out that Juniper routers running even slightly modern software did understand this attribute, and since the attribute was corrupted the software in its default configuration would respond by raising an error that would shut down the whole BGP session. Since a BGP session is often a critical part of being “connected” to the wider internet, this resulted in the small Brazilian network disrupting other networks’ ability to communicate with the rest of the internet, despite being 1000’s of miles away.

A reader has pointed out that the attribute in question was not actually corrupted, but the support was just unfinished it appears

The packet that causes session shutdowns was really quite benign at first glance:

When a BGP session shuts down due to errors, customer network traffic generally stops flowing down that cable until the BGP connection is automatically restarted (typically within seconds to minutes).

This appears to be what happened to a number of different carriers, for example COLT was heavily impacted by this. Their outage is what originally drew some of my attention to this subject area.

To understand why this sort of thing can happen, we’ll need to take a deeper look at what BGP route attributes are, and what they’re used for.

**What is a BGP Route Attribute?**

At their core a BGP UPDATEs purpose is to tell another router about some traffic that it can (or can no longer) send to it. However just knowing directly what you can send to another router is not very useful without _context_.

For this reason a BGP packet is split up into two sections: the Network Layer Reachability Information (NLRI) data (aka, the IP address ranges), and the attributes that help describe extra context about that reachability data.

Arguably the most used attribute is the AS\_PATH (or actually, the AS4\_PATH), an attribute that tells you which networks a route has travelled through to get to you. Routers use this list of networks to pick paths for their traffic that are either the fastest, economically viable, or least congested, playing a critical role in ensuring that things run smoothly.

At the time of writing there are over 32 different route attribute types, 14 deprecated ones, and 209 officially unassigned ones. The Internet Assigned Numbers Authority (IANA) is in charge of assigning codes to each BGP attribute type codes, normally off the back of IETF Internet-Drafts. The IANA list doesn’t always give the full story, though, as not all internet-drafts make their way into more official documents (like RFC’s), so code numbers are assigned (or sometimes even “squatted”) to attribute types that did not get wide deployment.

**Unknown attribute propagation**

At the start of every route attribute is a set of flags, conveying information about the attribute. One important flag is called the “transitive bit”:

If a BGP implementation does not understand an attribute, and the transitive bit is set, it will copy it to another router. If the router does understand the attribute then it may apply its own policy.

At a glance this “feature” seems like an incredibly bad idea, as it allows possibly unknown information to propagate blindly through systems that do not understand the impact of what they are forwarding. However this feature has also allowed widespread deployment of things like Large Communities to happen faster, and has arguably made deployment of new BGP features possible at all.

**When attribute decoding goes wrong**

What happens when an attribute fails to decode? The answer depends strongly on if the BGP implementation has been updated to use RFC 7606 logic or not; If the session is _not_ RFC 7606 compliant, then typically an error is raised and the session is shut down. If it is, the session can usually continue as normal (except the routes impacted by the decoding error are treated as unreachable).

BGP session shutdowns are particularly undesirable, as they will impact traffic flow along a path. However in the case of a “Transitive” error they can become worm-like. Since not all BGP implementations support the same attributes, an attribute that is unknown to one implementation (and subsequently forwarded along) can cause another implementation to shut down the session it received it from.

With some reasonably educated crafting of a payload, someone could design a BGP UPDATE that “travels” along the internet unharmed, until it reaches a targeted vendor and results in that vendor resetting sessions. If that data comes down the BGP connections that are providing wider internet access for the network, this could result in a network being pulled offline from the internet.

This attack is not even a one-off “hit-and-run”, as the “bad” route is still stored in the peer router; when the session restarts the victim router will reset again the moment the route with the crafted payload is transmitted again. This has the potential to cause prolonged internet or peering outages.

This is a large part of why the RFC mentioned earlier, RFC 7606, exists; looking at its security considerations section, we can see a description of this exact problem::

> Security Considerations This specification addresses the vulnerability of a BGP speaker to a potential attack whereby a distant attacker can generate a malformed optional transitive attribute that is not recognized by intervening routers. Since the intervening routers do not recognize the attribute, they propagate it without checking it. When the malformed attribute arrives at a router that does recognize the given attribute type, that router resets the session over which it arrived. Since significant fan-out can occur between the attacker and the routers that do recognize the attribute type, this attack could potentially be particularly harmful.

In a basic BGP setup this is bad, but with extra engineering it could be used to partition large sections of the internet. If BGP sessions between carriers are forced to reset in this way, causing traffic flow to stop, some routes on the internet would not have alternatives to use, making this a family of bugs that is a grave threat to the overall reliability of the internet.

**Building a basic fuzzer**

**Important Commitment:** I run a business that involves being peered to many IXP route servers and other peoples routers. I have not and will not ever test for BGP bugs/exploits on customer/partner sessions (unless they give consent).

All testing here has been done either on GNS3 VMs, or physical hardware I have hanging around and in isolated VLANs.

To figure out if this would be a practically exploitable attack, I decided to write a fuzzer that would try to stuff random data in random attribute codes to see if I could get sessions to reset on different vendors BGP implementations.

Because I am looking for problems that are “wormable”, I added a Bird 2 router in between my fuzzer and the router being tested. This way Bird will filter out all of the obvious non-exploitable issues, and leave me with the packets that are of concern.

All good fuzzers should be able to run unattended, so how do we teach the fuzzer to tell if the session has reset itself? The solution I came to was that the Victim router would always announce a keepalive prefix, 192.0.2.0/24 (aka TEST-NET-1) and the fuzzer would treat a withdraw of that prefix (from the intermediate bird router) as a sign the session went down, and report back the parameters that caused that to happen!

Testing the fuzzer, I can see that the bird output shows unknown attributes as their type code, and a hex encoding of their contents. In addition it puts a [t] to indicate that it is transitive.

    198.51.100.0/24      unicast [fuzzer 21:31:24.378] * (100) [AS65001?]
    	via 192.168.5.1 on ens5
    	Type: BGP univ
    	BGP.origin: Incomplete
    	BGP.as_path: 65001
    	BGP.next_hop: 192.168.5.1
    	BGP.local_pref: 100
    	BGP.community: (123,2345)
    	BGP.ec [t]: 7d cc c7 30
    

Now that the fuzzer was able to run itself, all that was left was to test all of the vendors one by one…

**Fuzzer findings / Impacted Vendors**

Keep in mind that the described issues are applicable if you are running an edge device with full BGP tables. If you are not running a “full routing table” or a partial peering table, then you are less likely to be impacted by these discoveries.

Another thing to keep in mind, the issues below are different to the ones that the team at Forescout recently presented at BlackHat.

Unimpacted Vendors:

*   MikroTik RouterOS 7+
*   Ubiquiti EdgeOS
*   Arista EOS
*   Huawei NE40
*   Cisco IOS-XE / “Classic” / XR
*   Bird 1.6, All versions of Bird 2.0
*   GoBGP

**Juniper JunOS Impact**

Similar to the problem that caused this research to be done, another exploitable Attribute was found in the form of Attribute 29 (BGP-LS). Due to the nature of the attribute it is unlikely that an exploit attempt will propagate too far over the internet, however peering sessions and route servers are still at risk.

All Juniper users are **urged** to enable bgp-error-tolerance:

    [edit protocols bgp]
    root# show 
    group TRANSIT {
        import import-pol;
        export send-direct;
        peer-as 4200000001;
        local-as 4200000002;
        neighbor 192.0.2.2;
    }
    bgp-error-tolerance;
    

In all tested cases, enabling bgp-error-tolerance does not reset sessions, and applies the improved behaviour without restarting sessions.

A JunOS software release is expected in the future to correct this. One member of staff at Juniper has also authored an Internet-Draft at the IETF around handling these issues. Juniper is tracking this issue as CVE-2023-4481 / JSA72510.

**Nokia SR-OS Impact**

Fuzzing SR-OS (Version 22.10) revealed many, likely highly propagatable and thus exploitable attributes.

All Nokia SR-OS and SR-Linux users are **urged** to enable error-handling update-fault-tolerance on their devices.

     bgp
         group "TRANSIT"              
             export "yes"
             error-handling
                 update-fault-tolerance
             exit
             neighbor 192.0.2.2
                 peer-as 2
             exit
         exit
         no shutdown
     exit
    

In all tested cases, enabling update-fault-tolerance does not reset sessions, and applies the improved behaviour without restarting sessions.

To the best of my understanding, Nokia has no plans to correct these issues, instead suggesting customers apply error-handling update-fault-tolerance to their BGP groups.

**FRR Impact (and other downstream vendors)**

FRR attempts to handle bad attributes using RFC 7606 behaviour. However the fuzzer discovered that a corrupted attribute 23 (Tunnel Encapsulation) will cause a session to go down regardless.

After reporting this bug to FRR maintainers I received an acknowledgement of the issue and understanding that the issue is a DoS risk to FRR users, but I have not managed to get anything out of FRR since.

This bug is being tracked as CVE-2023-38802 and at the time of writing has no patch or fix.

FRR is packaged inside many other products, to name a few: SONIC, PICA8, Cumulus, and DANOS.

**OpenBSD OpenBGPd Impact**

OpenBGPd also supports the improved RFC 7606 behaviour, however it was found that the recently added Only To Customer implementation could cause session resets. This issue was very rapidly fixed after being reported to them, and is tracked as CVE-2023-38283.

OpenBSD users can install Errata 006 to mitigate this issue.

**Extreme Networks EXOS Impact**

As a result of fuzzing EXOS, the program revealed 2 highly propagatable and thus exploitable attributes in the form of:

*   Attribute 21: AS\_PATHLIMIT
*   Attribute 25: IPv6 Address Specific Extended Community

There is currently no known patch or mitigating config for this issue.

I made Extreme aware of this problem, however after a back and forth with them waiting for what I understood was an implied release of a patch or fix, they communicated that they will not be fixing it in the near future.

A quote from the security email thread (I’ve added emphasis to the critical parts of their response):

> After review of all the material, **we are not considering this a vulnerability due to the presence of RFC 7606**, as well as a history of documentation expressing these concerns all the way back to early 2000s, if not earlier. Malformed attributes are not a novel concept as an attack vector to BGP networks, as evidenced by RFC 7606, which is almost a decade old. As such, customers that have chosen to not require or implement RFC 7606 have done so willingly and with knowledge of what is needed to defend against these types of attacks. Thus, the expectation that we’ll reset our BGP sessions based on RFC 4271 attribute handling is proper. We do abide by other RFCs, in which we claim support, that update RFC 4271. Other vendors do claim RFC 7606 support and have been sharing these controls as a mitigation to malformed attribute response. They don’t appear to be producing new work product to account for these behaviors. **We are evaluating support for RFC 7606 as a future feature.** Obviously, if customers desire a different response, we’ll work through our normal feature request pipelines to address. This is no different than any other RFC support request.

I cannot overstate how much I disagree with Extreme’s response to this, and in the interests of full transparency (and to avoid any allegations of editorialising this, in my view, extremely poor response), I have made the full email exchange available here: (PDF).

**The Vendor Security Response**

I’ve been through my fair share of security issue discoveries, and over time I’ve taken a stronger leaning into “simply do not report” or “full disclosure without warning”, rather than the now commonly accepted 90 day “responsible disclosure” methodology. This is mostly because I’ve had really poor experiences when disclosing issues to security teams.

The bugs discussed in this post cover many vendors and implementations. Full disclosure was originally my plan, however due to the clear risk of harm to the general internet routing system from these findings, I felt it was likely inexcusable to do full-disclosure. (Plus, a malicious deployment of these findings could have a small but I believe very real chance of a “kinetic response” from a misunderstanding.)

Overall the response from vendors has been mostly disappointing. One vendor was extremely hard to find contacts for, and I feel that they were stringing me along for some time, only to reply back that they were not going to fix the problem.

Other vendors notably were not immediately interested in notifying customers of mitigating config to the problems, however when I personally started extending notices to my peers at larger carriers about the problems (since if they were not going to, I was going to try and reduce the exploit surface) a vendor notice was issued.

No vendor that I reported to has any form of bug bounty, and this entire adventure has consumed huge volumes of my time and mental capacity. In a normal situation this “cost” would have simply been eaten by an employer whose interest is name recognition or altruistic actions. However I am self-employed with my own company (that admittedly does have an interest in a functioning BGP ecosystem), and so this entire adventure has simply delayed product development that I (and customers) really would have liked to have done.

With all of that in mind, my “good faith” advice to people reporting security bugs in network vendor software is that contacting vendors is not an effective solution.

The people on the other side are either already overloaded, or generally don’t care about receiving issues. Since there is no motivation to report bugs (either in the form of bug bounties, or being treated well), I see no reason to do responsible disclosure (apart from cases where it would clearly protect their innocent customers from misery, while accounting for the risk of a vendor simply doing nothing).

The two options, as far as I see it, are either being strung along by a vendor over email for 90 days and then likely finding out nothing is done, or full disclosure.

I worry about the state of networking vendors.

With that being said, I would like to thank the OpenBSD security team, who very rapidly acknowledged my report, and prepared a patch. My only regret with dealing with the OpenBSD team was reporting the issue to them too quickly.

**Closing thoughts**

As mentioned before, with a few of the vendors (Nokia, Extreme, Juniper) I found myself contacting their own customers myself to warn them to enable mitigating config, as that proved to be a much more effective way at preventing risk than trying to push the vendor itself into action.

As a result at least several incumbent ISPs, 1 large CDN, and 2 “Tier 1” networks have applied configuration to help prevent these issues from impacting them.

If the goal of reporting security flaws is to reduce harm to their customers, I’m not convinced that reporting problems to vendors has enough of an effective impact to be worth doing, vs the loss of personal time and sanity.

Several people I spoke to have been incredibly helpful (some who could not be listed here). I would like to thank the following people for having some role in helping me either discover/disclose these problems, editing this post, or general support for when vendors were being very frustrating.

*   Basil Fillan
*   Alistair Mackenzie
*   Will Hargrave
*   Filippo Valsorda
*   Joseph Lorenzo Hall
*   Job Snijders
*   eta

If you want to stay up to date with the blog you can use the RSS feed or you can follow me on Mastodon/Fediverse @benjojo@benjojo.co.uk

If you run a network and are interested in BGP monitoring do check out bgp.tools! Otherwise if you like what I do or think that you could do with some of my bizarre areas of knowledge I am also open for contract work, please contact me over at workwith@benjojo.co.uk!

Until next time!

CVE-2023-45886: Grave flaws in BGP Error handling

Vulnerability of identity verification being bypassed in the face unlock module. Successful exploitation of this vulnerability will affect integrity and confidentiality.

HUAWEI is releasing monthly security updates for flagship models. This security update includes HUAWEI and third-party library patches:

This security update includes the following third-party library patches:

This security update includes the CVE announced in the October 2023 Android security bulletin:

Critical: CVE-2023-4863

High: CVE-2023-40128, CVE-2023-21266, CVE-2023-40121, CVE-2023-40123, CVE-2023-40133, CVE-2023-40134, CVE-2023-40135, CVE-2023-40136, CVE-2023-40137, CVE-2023-40138, CVE-2023-40139, CVE-2023-40140, CVE-2023-40125, CVE-2023-40127, CVE-2023-40130, CVE-2023-33034, CVE-2023-33035, CVE-2023-21394

Medium: none

Low: none

Already included in previous updates: CVE-2023-21281, CVE-2022-20281, CVE-2023-21177

※ For more information on security patches, please refer to the Android security bulletins (https://source.android.com/security/bulletin).

This security update includes the following HUAWEI patches:

CVE-2022-48613: Race condition vulnerability in the kernel module

Severity: Medium

Affected versions: EMUI 13.0.0, EMUI 12.0.0

Impact: Successful exploitation of this vulnerability may cause variable values to be read with the condition evaluation bypassed.

CVE-2023-44098: Vulnerability of missing encryption in the card management module

Severity: Medium

Affected versions: EMUI 13.0.0, EMUI 12.0.1, EMUI 11.0.1

Impact: Successful exploitation of this vulnerability may affect service confidentiality.

CVE-2023-44115: Vulnerability of improper permission control in the Booster module

Severity: Medium

Affected versions: EMUI 13.0.0, EMUI 12.0.1, EMUI 12.0.0

Impact: Successful exploitation of this vulnerability may affect service confidentiality.

CVE-2023-46755: Vulnerability of input parameters being not strictly verified in the input method module

Severity: Medium

Affected versions: EMUI 13.0.0, EMUI 12.0.1 , EMUI 12.0.0

Impact: Successful exploitation of this vulnerability may cause the launcher to restart.

CVE-2023-46756: Permission control vulnerability in the window management module

Severity: Medium

Affected versions: EMUI 13.0.0, EMUI 12.0.1 , EMUI 12.0.0, EMUI 11.0.1

Impact: Successful exploitation of this vulnerability may cause malicious pop-up windows.

CVE-2023-46758: Permission management vulnerability in the multi-screen interaction module

Severity: Medium

Affected versions: EMUI 13.0.0, EMUI 12.0.1 , EMUI 12.0.0, EMUI 11.0.1

Impact: Successful exploitation of this vulnerability may cause service exceptions of the device.

CVE-2023-46759: Permission control vulnerability in the call module

Severity: Medium

Affected versions: EMUI 13.0.0, EMUI 12.0.1 , EMUI 12.0.0, EMUI 11.0.1

Impact: Successful exploitation of this vulnerability may affect service confidentiality.

CVE-2023-46760: Out-of-bounds write vulnerability in the kernel driver module

Severity: Medium

Affected versions: EMUI 13.0.0

Impact: Successful exploitation of this vulnerability may cause process exceptions.

CVE-2023-46761: Out-of-bounds write vulnerability in the kernel driver module

Severity: Medium

Affected versions: EMUI 13.0.0

Impact: Successful exploitation of this vulnerability may cause process exceptions.

CVE-2023-46762: Out-of-bounds write vulnerability in the kernel driver module

Severity: Medium

Affected versions: EMUI 13.0.0

Impact: Successful exploitation of this vulnerability may cause process exceptions.

CVE-2023-46763: Vulnerability of background app permission management in the framework module

Severity: Medium

Affected versions: EMUI 13.0.0, EMUI 12.0.1 , EMUI 12.0.0, EMUI 11.0.1

Impact: Successful exploitation of this vulnerability may cause background apps to start maliciously.

CVE-2023-46764: Unauthorized startup vulnerability of background apps

Severity: Medium

Affected versions: EMUI 13.0.0, EMUI 12.0.1 , EMUI 12.0.0, EMUI 11.0.1

Impact: Successful exploitation of this vulnerability may cause background apps to start maliciously.

CVE-2023-46765: Vulnerability of uncaught exceptions in the NFC module

Severity: Medium

Affected versions: EMUI 13.0.0, EMUI 12.0.1, EMUI 12.0.0, EMUI 11.0.1

Impact: Successful exploitation of this vulnerability can affect NFC availability.

CVE-2023-46766: Out-of-bounds write vulnerability in the kernel driver module

Severity: Medium

Affected versions: EMUI 13.0.0

Impact: Successful exploitation of this vulnerability may cause process exceptions.

CVE-2023-46767: Out-of-bounds write vulnerability in the kernel driver module

Severity: Medium

Affected versions: EMUI 13.0.0

Impact: Successful exploitation of this vulnerability may cause process exceptions.

CVE-2023-46768: Multi-thread vulnerability in the idmap module

Severity: High

Affected versions: EMUI 13.0.0

Impact: Successful exploitation of this vulnerability may cause features to perform abnormally.

CVE-2023-46769: Use-After-Free (UAF) vulnerability in the dubai module

Severity: High

Affected versions: EMUI 13.0.0

Impact: Successful exploitation of this vulnerability will affect availability.

CVE-2023-46770: Out-of-bounds vulnerability in the sensor module

Severity: High

Affected versions: EMUI 13.0.0, EMUI 12.0.0

Impact: Successful exploitation of this vulnerability may cause mistouch prevention errors on users' mobile phones.

CVE-2023-46771: Security vulnerability in the face unlock module

Severity: Medium

Affected versions: EMUI 13.0.0, EMUI 12.0.0

Impact: Successful exploitation of this vulnerability may affect service confidentiality.

CVE-2023-46772: Vulnerability of parameters being out of the value range in the QMI service module

Severity: Medium

Affected versions: EMUI 11.0.1

Impact: Successful exploitation of this vulnerability may cause errors in reading file data.

CVE-2023-46774: Vulnerability of uncaught exceptions in the NFC module

Severity: Medium

Affected versions: EMUI 13.0.0, EMUI 12.0.1, EMUI 12.0.0, EMUI 11.0.1

Impact: Successful exploitation of this vulnerability can affect NFC availability.

CVE-2023-5801: Vulnerability of identity verification being bypassed in the face unlock module

Severity: Critical

Affected versions: EMUI 13.0.0, EMUI 12.0.0

Impact: Successful exploitation of this vulnerability will affect integrity and confidentiality.

CVE-2023-5801: November

By Waqas
The fate of WeChat and Kaspersky apps on civilian devices remains uncertain.
This is a post from HackRead.com Read the original post: Canada Bans WeChat and Kaspersky Due to Spying Concerns

The Government of Canada has instructed government employees to immediately uninstall WeChat and Kaspersky apps from their smartphones, tablets, and laptops.

Canada has banned the Chinese messaging app WeChat and the Russian antivirus software Kaspersky from government devices, citing privacy and security concerns. The ban, which took effect on October 30, 2023, applies to all government-issued mobile devices, including smartphones, tablets, and laptops.

The Canadian government said that its decision was based on an assessment by Canada’s chief information officer that found that WeChat and Kaspersky “present an unacceptable level of risk to privacy and security.”

The assessment found that both apps collect a wide range of data from users, including their contacts, location, and financial information. It also found that both apps could be used to plant malware on devices or to track communications.

The Chinese government has criticized Canada’s ban, calling it “unreasonable and discriminatory.” Tencent, the company that owns WeChat, has said that the app is “committed to protecting the privacy and security of its users.” Kaspersky has also denied any wrongdoing.

Canada’s ban on WeChat and Kaspersky is part of a broader trend of Western governments taking a more cautious approach to Chinese and Russian technology companies. In recent years, there have been growing concerns that these companies could be used by their governments to spy on users or to interfere in foreign elections.

In addition to Canada, the United States, Australia, and New Zealand have also banned Kaspersky and WeChat from government devices. The United States has also gone further, imposing sanctions on several Chinese technology companies, including Huawei and ZTE.

The ban is likely to have a significant impact on the Chinese and Russian technology industries. WeChat is one of the most popular messaging apps in the world, with over 1.2 billion active users. Kaspersky is also one of the most popular antivirus software companies in the world, with over 400 million active users.

In a press release published on October 30th, 2023, Anita Anand, President of the Treasury Board, stated that,

> _“We are taking a risk-based approach to cyber security by removing access to these applications on government mobile devices. The Government of Canada continuously works to safeguard our information systems and networks to ensure the privacy and protection of government information. We will continue to regularly monitor potential cyber threats and take immediate action when needed.”_
> 
> Anita Anand, President of the Treasury Board

The ban is also likely to send a message to other Western governments that they should be more cautious about using technology from China and Russia. It could also lead to other Western governments imposing similar bans on Chinese and Russian technology companies.

Overall, Canada’s ban on WeChat and Kaspersky is a significant step that is likely to have a major impact on the global technology industry. It is also a sign that Western governments are becoming increasingly concerned about the potential for Chinese and Russian technology companies to be used for malicious purposes.

****_RELATED ARTICLES_****

1.  Kaspersky spots CIA malware with backdoor capabilities
2.  Kaspersky Reveals iPhones of Employees Infected with Spyware
3.  Kaspersky tipped off US about the contractor who stole NSA data
4.  Israel hacked Kaspersky to inform US about Russia stealing NSA exploits
5.  Passwords by Kaspersky Password Manager exposed to brute-force attack

Tag

#huawei