By Waqas
Popular keyboard apps leak user data! Citizen Lab reports 8 out of 9 Android IMEs expose keystrokes. Change yours & protect passwords!
This is a post from HackRead.com Read the original post: Popular Keyboard Apps Leak User Data: Billion Potentially Exposed

Citizen Lab investigated the security of cloud-based pinyin keyboard apps and found that eight out of nine vendors transmitted user keystrokes in an insecure manner. This means keystrokes could be intercepted by eavesdroppers on the network.

A new report by Citizen Lab has uncovered critical security vulnerabilities in popular keyboard apps, potentially exposing the keystrokes of nearly a billion users to eavesdroppers.

The report, titled “The not-so-silent type: Vulnerabilities across keyboard apps reveal keystrokes to network eavesdroppers,” investigates cloud-based pinyin input method editors (IMEs) used on a vast majority of Android devices in China.

Researchers analyzed keyboard apps from nine major vendors: Baidu, Honor, Huawei, iFlytek, OPPO, Samsung, Tencent, Vivo, and Xiaomi. Alarmingly, they found vulnerabilities in eight of these apps that could allow attackers to steal users’ keystrokes as they type.

The report details various weaknesses in how these apps transmit data. Some apps, like Samsung Keyboard, send keystrokes completely unencrypted, making them easy for anyone snooping on the network to intercept. Others rely on flawed encryption methods that can be cracked.

The ease of eavesdropping varies depending on the app. In some cases, a malicious actor on the same Wi-Fi network could steal your data. Even more concerning, some vulnerabilities are exploitable by entirely passive eavesdroppers, who can intercept data without needing any interaction from the user.

The report highlights Huawei as the only vendor whose keyboard app did not exhibit these vulnerabilities. This offers some peace of mind for Huawei users but leaves a significant number of users potentially exposed.

Citizen Lab estimates that the combined market share of Baidu, Sogou (mentioned in a previous report by Citizen Lab), and iFlytek represents over 95% of the third-party IME market in China, translating to roughly one billion users at risk.

This security lapse has serious consequences. Keystrokes can contain sensitive information like passwords, credit card details, and private messages. If intercepted, this data could be used for identity theft, financial fraud, and other malicious activities.

Nevertheless, the report shows the importance of using secure keyboard apps. Users should prioritize apps with a strong reputation for security and that encrypt user data properly. Additionally, it’s recommended to avoid using sensitive information on public Wi-Fi networks.

Researchers urge app developers to address these vulnerabilities immediately by implementing strong encryption methods and secure data transmission protocols.

1.  AI Model Listens to Typing, Compromising Sensitive Data
2.  Keyboard app collecting users data after 31M records leaked online
3.  Intel removes remote Android keyboard app rather than fixing its flaws
4.  Chinese Keyboard Developer Spies on User Through Built-in Keylogger
5.  Android Emoji keyboard app makes millions with unauthorized purchases

Popular Keyboard Apps Leak User Data: Billion Potentially Exposed

PRESS RELEASE

Copenhagen, Denmark, April 16, 2024 – Keepit, a global leader in SaaS data backup and recovery, today announced Kim Larsen as new Chief Information Security Officer (CISO). With more than 20 years of leadership experience in IT and cybersecurity from government and the private sector, the new CISO’s areas of expertise include: business driven security; aligning corporate, digital and security strategies; risk management and threat mitigation; developing and implementing security strategies; leading through communication; and coaching. Larsen's deep government and broad private sector experience will position him to bring Keepit’s security advisory capabilities and development of future services to the next level.  

Kim Larsen is an experienced keynote speaker, negotiator, and board advisor on cyber and general security topics, with experience from a wide range of organizations, including NATO, EU, Verizon, Systematic, and a number of industry security boards. 

“It's a real pleasure to welcome Kim Larsen to the team — his deep government and broad private sector experience is exceptional, and perfectly positions him to bring Keepit’s security advisory capabilities and development of future services to the next level. Our current growth trajectory and go-to-market strategy has us engaging in conversations where his expertise is highly valuable,” says Morten Felsvang, Keepit CEO.

Kim Larsen started his career in the Danish National Police and subsequently spent nine years with Security and Intelligence Service (PET) where he served as delegate for the Danish government in both NATO’s and the EU’s security committees.

Moving into the private sector to act as strategic advisor on government, public and financial sector matters, and developing security organizations and partnerships in companies such as Verizon, Huawei and Systematic, he has served on the information security board of the Danish Industry confederation (DI) and Danish Council for Digital Security for 10 years. 

Backup and recovery critical components to cybersecurity

With this background, Kim Larsen has a holistic take on cybersecurity and a profound understanding of what is required and desired in organizations bolstering their IT infrastructures against cyber threats:

“I am very happy to join Keepit: Backup and recovery are critical components of a solid cybersecurity posture, and the unique Keepit solution is the answer to so many compliance and security challenges. It’s a great opportunity to work with organizations on how to retain access to their data in the face of any malign or arbitrary threats to their infrastructure,” says Kim Larsen.

The CISO points to compliance, cyber resilience, and disaster recovery best practices as three of his favorite subjects and reasons for choosing Keepit as his new stomping ground: 

“If there’s one thing we can be sure of, it’s this: We don’t know the threats we will be facing in the future. But we can make educated guesses. And based on those, we can make sure to cross the t’s and dot the i’s that we do know about. That’s why the Keepit solution is a future-proof solution: With its vendor-independent tech stack that keeps data physically and logically separate from the production environment, it’s a guarantee that customer data is always available. And with local data centers keeping data in the same regulatory regions as the organization, full compliance is assured. It really is quite unique,” states Kim Larsen. 

About Kim Larsen

Kim Larsen is Chief Information Security Officer at Keepit and has more than 20 years of leadership experience in IT and cybersecurity from government and the private sector.

Areas of expertise include business driven security, aligning corporate, digital and security strategies, risk management and threat mitigation adequate to business needs, developing and implementing security strategies, leading through communication, and coaching.

Kim Larsen is an experienced keynote speaker, negotiator, and board advisor on cyber and general security topics, with experience from a wide range of organizations, including NATO, EU, Verizon, Systematic, and a number of industry security boards.

Find Kim Larsen on LinkedIn.

Kim Larsen New Chief Information Security Officer at SaaS Data Protection Vendor Keepit

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!

Tag

#huawei