Isode M-Vault 16.0v0 through 17.x before 17.0v24 can crash upon an LDAP v1 bind request.

Summary

Denial of Service due to application crash

Release Date

21st December 2022

Product

M-Vault

Version(s)

16.0v0 to 17.0v23

CVE ID

CVE-2022-47581

  
**Summary of vulnerability**

This advisory discloses a critical vulnerability introduced in version R16.0v0 of M-Vault. The following versions are affected by this vulnerability:

*   M-Vault R16.0v0 to R17.0v23.

This is a bug where an LDAPv1 bind request leads to a server crash, thereby leading to denial of service.

**Severity**

Isode rates the severity level of this vulnerability as **high**, according to the CVSS system (details can be found at www.first.org).

**Mitigation**

This vulnerability has been fixed in M-Vault R17.0v24 and affected services are advised to immediately upgrade to this version. Current later versions (such as the subsequent major release R18.0) are **not** affected by this vulnerability.

**Acknowledgements**

This vulnerability was discovered, with thanks from Isode, by Jerome Nokin of the NATO Cyber Security Centre (NCSC).

CVE-2022-47581: Advisory Report for M-Link Incorrect Access Control Vulnerability

The open source container tool is quite popular among developers — and threat actors. Here are a few ways DevOps teams can take control.

_Editor's note: For more about the kinds of vulnerabilities Kubernetes presents and how to address them, read our_ _companion article_ _in The Edge._

Since its initial release in 2014, Kubernetes (aka K8s) has become the standard open source container tool for managing software applications. Kubernetes is cost-effective, offers autoscaling, and can run on any infrastructure. Its benefits are why 85% of IT leaders consider Kubernetes "extremely important" to cloud-native strategies. On top of this, 61% of people use Kubernetes to manage their computer application deployment.

Funso Richard, information security officer at Ensemble, tells Dark Reading that "forward-thinking organizations understand the importance of leveraging containerized microservices to develop scalable and reliable applications as an essential digital transformation strategy" — and Kubernetes has become the leading tool used to achieve this strategy, he adds.

However, Kubernetes also comes with security challenges: It's susceptible to data theft, computational power theft, and denial-of-service (DoS) attacks. Kubernetes' public components (such as kubelets and API authentication) are widely exploited. And threat actors target infrastructure misconfiguration, unpatched software programs, and poor login credentials to gain unauthorized entry to Kubernetes. The vulnerabilities are also widespread. According to Red Hat's "2022 State of Kubernetes" security report, 93% of Kubernetes users experienced at least one security incident in the past 12 months.

As DevOps teams continue to grapple with rising Kubernetes security mishaps, here are a few ways to stay ahead of attackers and keep cloud-native environments secure.

**Securing Kubernetes With Tools**

Kubernetes' security vulnerability affects its efficiency. For instance, concerns over Kubernetes security caused developers to delay application rollouts in 2022, according to Red Hat. Although Kubernetes provides several benefits in application development and container orchestration, says Richard, inadequate security controls expose the open source tool to serious security concerns like misconfiguration, privilege abuse, data exfiltration, credential compromise, exploited public-facing components, and API vulnerabilities. To address these, several Kubernetes security tools have sprung up, including Kubescape, Kube-bench, Kubeaudit, Kube-hunter, and Kyverno.

Kubescape is an open source security platform from ARMO to protect Kubernetes clusters with capabilities such as risk analysis, security compliance, misconfiguration scanning, CI/CD security, RBAC visualizer, and vulnerabilities scanning. One thing that sets Kubescape apart is its library of robust capabilities that aligns with MITRE ATT&CK and NSA-CISA frameworks, says Richard.

"As I track Kubernetes security offerings — both commercial and non-commercial offerings — I haven't come across another offering with the same exact components as Kubescape," agrees Fernando Montenegro, senior principal analyst of cybersecurity infrastructure at Omdia.

Kubescape scans clusters, YAML files, and Helm charts for vulnerabilities either directly or via CI/CD integrations. The idea of scanning infrastructure-as-code (IaC) templates is well-popularized across the industry, says Montenegro. Most IaC scanning is done for cloud resources like Amazon's CloudFormation, HashiCorp's Terraform, and others, with Kubernetes scanning being a more specialized use case, he adds.

There are other offerings in the market — like Red Hat's StackRox (acquired in 2021), Tenable's Terrascan, and Palo Alto Networks' Checkov — offering similar capabilities as Kubernetes.

**Implementing Best Security Practices in Kubernetes**

Richard notes that adherence to cybersecurity fundamentals remains the bedrock of any security effort. While Kubescape is undoubtedly a powerful Kubernetes security tool, he believes developers can effectively secure their Kubernetes clusters by following the basics: implementing proper cluster configuration, pod security standards and policy enforcement, network segmentation, vulnerability scanning, periodic policy reviews, and security audits. "Containers should run with the least privileges and only necessary services, while role-based access controls should be in place to manage user access," Richard says.

While Montenegro says there are several Kubernetes best practices for DevOps and DevSecOps teams to follow, he notes that the following practices must be top on their priority list:

*   **Think about security early on:** Collaborate with your developers/architects to work through a proper threat modeling.
*   **Work with embedding security throughout the application lifecycle:** Security is an end-to-end process, from providing on-the-spot security advice and functionality for a developer working through the code in their development environment, through making sure security tests are part and parcel of the integration stages, then adding the necessary runtime protections to monitor workloads in production.
*   **Safely store Kubernetes secrets:** Implement features like proper namespace separation, use of role-based access control (RBAC).

As Kubernetes grows in adoption, IT teams can avoid security pitfalls by using tools like Kubescape and StackRox, as well as following the best security practices for securing their critical Kubernetes assets.

How to Run Kubernetes More Securely

IBM Security Guardium 11.4 could allow a privileged user to obtain sensitive information inside of an HTTP response. IBM X-Force ID: 235405.

  

**Summary**

IBM Security Guardium has addressed these vulnerabilities \[CVE-2022-39166, CVE-2022-34917, CVE-2022-42889\]

**Vulnerability Details**

**CVEID:**   CVE-2022-39166  
**DESCRIPTION:**   IBM Security Guardium could allow a privileged user to obtain sensitive information inside of an HTTP response.  
CVSS Base score: 4.4  
CVSS Temporal Score: See: https://exchange.xforce.ibmcloud.com/vulnerabilities/235405 for the current score.  
CVSS Vector: (CVSS:3.0/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N)

**CVEID:**   CVE-2022-34917  
**DESCRIPTION:**   Apache Kafka is vulnerable to a denial of service, caused by improper input validation. By sending a specially-crafted request, a remote attacker could exploit this vulnerability to allocate large amounts of memory on brokers, and results in a denial of service condition.  
CVSS Base score: 7.5  
CVSS Temporal Score: See: https://exchange.xforce.ibmcloud.com/vulnerabilities/236498 for the current score.  
CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)

**CVEID:**   CVE-2022-42889  
**DESCRIPTION:**   Apache Commons Text could allow a remote attacker to execute arbitrary code on the system, caused by an insecure interpolation defaults flaw. By sending a specially-crafted input, an attacker could exploit this vulnerability to execute arbitrary code on the system.  
CVSS Base score: 9.8  
CVSS Temporal Score: See: https://exchange.xforce.ibmcloud.com/vulnerabilities/238560 for the current score.  
CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)

**Affected Products and Versions**

**Affected Product(s)**

**Version(s)**

IBM Security Guardium

11.4

  

**Remediation/Fixes**

IBM strongly encourages customers to update their systems promptly.

**Workarounds and Mitigations**

None

**References**

Off

**Acknowledgement**

Desjardins

**Change History**

30 Nov 2022: Initial Publication

\*The CVSS Environment Score is customer environment specific and will ultimately impact the Overall CVSS Score. Customers can evaluate the impact of this vulnerability in their environments by accessing the links in the Reference section of this Security Bulletin.

**Disclaimer**

According to the Forum of Incident Response and Security Teams (FIRST), the Common Vulnerability Scoring System (CVSS) is an "industry open standard designed to convey vulnerability severity and help to determine urgency and priority of response." IBM PROVIDES THE CVSS SCORES ""AS IS"" WITHOUT WARRANTY OF ANY KIND, INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. CUSTOMERS ARE RESPONSIBLE FOR ASSESSING THE IMPACT OF ANY ACTUAL OR POTENTIAL SECURITY VULNERABILITY. In addition to other efforts to address potential vulnerabilities, IBM periodically updates the record of components contained in our product offerings. As part of that effort, if IBM identifies previously unidentified packages in a product/service inventory, we address relevant vulnerabilities regardless of CVE date. Inclusion of an older CVEID does not demonstrate that the referenced product has been used by IBM since that date, nor that IBM was aware of a vulnerability as of that date. We are making clients aware of relevant vulnerabilities as we become aware of them. "Affected Products and Versions" referenced in IBM Security Bulletins are intended to be only products and versions that are supported by IBM and have not passed their end-of-support or warranty date. Thus, failure to reference unsupported or extended-support products and versions in this Security Bulletin does not constitute a determination by IBM that they are unaffected by the vulnerability. Reference to one or more unsupported versions in this Security Bulletin shall not create an obligation for IBM to provide fixes for any unsupported or extended-support products or versions.

**Document Location**

Worldwide

\[{"Business Unit":{"code":"BU059","label":"IBM Software w\\/o TPS"},"Product":{"code":"SSMPHH","label":"IBM Security Guardium"},"Component":"","Platform":\[{"code":"PF016","label":"Linux"}\],"Version":"11.4","Edition":"","Line of Business":{"code":"LOB24","label":"Security Software"}}\]

CVE-2022-39166: IBM Security Guardium is affected by the following vulnerabilities [CVE-2022-39166, CVE-2022-34917, CVE-2022-42889]

IBM Spectrum Control 5.4 uses weaker than expected cryptographic algorithms that could allow an attacker to decrypt highly sensitive information. IBM X-Force ID: 233982.

**Security Bulletin**

  

**Summary**

Vulnerabilities in IBM WebSphere Application Server Liberty and FasterXML jackson-databind such as HTTP header injection, identity spoofing, denial of service may affect IBM Spectrum Control.

**Vulnerability Details**

**CVEID:**   CVE-2022-34165  
**DESCRIPTION:**   IBM WebSphere Application Server 7.0, 8.0, 8.5, and 9.0 and IBM WebSphere Application Server Liberty 17.0.0.3 through 22.0.0.9 are vulnerable to HTTP header injection, caused by improper validation. This could allow an attacker to conduct various attacks against the vulnerable system, including cache poisoning and cross-site scripting. IBM X-Force ID: 229429.  
CVSS Base score: 5.4  
CVSS Temporal Score: See: https://exchange.xforce.ibmcloud.com/vulnerabilities/229429 for the current score.  
CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N)

**CVEID:**   CVE-2022-42004  
**DESCRIPTION:**   FasterXML jackson-databind is vulnerable to a denial of service, caused by a lack of a check in in the BeanDeserializer.\_deserializeFromArray function. By sending a specially-crafted request using deeply nested arrays, a local attacker could exploit this vulnerability to exhaust all available resources.  
CVSS Base score: 6.2  
CVSS Temporal Score: See: https://exchange.xforce.ibmcloud.com/vulnerabilities/237660 for the current score.  
CVSS Vector: (CVSS:3.0/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)

**CVEID:**   CVE-2022-22476  
**DESCRIPTION:**   IBM WebSphere Application Server Liberty 17.0.0.3 through 22.0.0.7 and Open Liberty are vulnerable to identity spoofing by an authenticated user using a specially crafted request. IBM X-Force ID: 225604.  
CVSS Base score: 5  
CVSS Temporal Score: See: https://exchange.xforce.ibmcloud.com/vulnerabilities/225604 for the current score.  
CVSS Vector: (CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L)

**CVEID:**   CVE-2022-38391  
**DESCRIPTION:**   IBM Spectrum Control uses weaker than expected cryptographic algorithms that could allow an attacker to decrypt highly sensitive information.  
CVSS Base score: 5.1  
CVSS Temporal Score: See: https://exchange.xforce.ibmcloud.com/vulnerabilities/233982 for the current score.  
CVSS Vector: (CVSS:3.0/AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N)

**CVEID:**   CVE-2022-42003  
**DESCRIPTION:**   FasterXML jackson-databind is vulnerable to a denial of service, caused by a lack of a check in the primitive value deserializers when the UNWRAP\_SINGLE\_VALUE\_ARRAYS feature is enabled. By sending a specially-crafted request using deep wrapper array nesting, a local attacker could exploit this vulnerability to exhaust all available resources.  
CVSS Base score: 6.2  
CVSS Temporal Score: See: https://exchange.xforce.ibmcloud.com/vulnerabilities/237662 for the current score.  
CVSS Vector: (CVSS:3.0/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)

**Affected Products and Versions**

**Affected Product(s)**

**Version(s)**

IBM Spectrum Control

5.4

**Remediation/Fixes**

**Workarounds and Mitigations**

None

**References**

Off

**Acknowledgement**

The vulnerability was reported to IBM by Mikhail Zakharov - zmey20000@yahoo.com - https://www.linkedin.com/in/mikhailzakharov

**Change History**

15 Dec 2022: Initial Publication

\*The CVSS Environment Score is customer environment specific and will ultimately impact the Overall CVSS Score. Customers can evaluate the impact of this vulnerability in their environments by accessing the links in the Reference section of this Security Bulletin.

**Disclaimer**

According to the Forum of Incident Response and Security Teams (FIRST), the Common Vulnerability Scoring System (CVSS) is an "industry open standard designed to convey vulnerability severity and help to determine urgency and priority of response." IBM PROVIDES THE CVSS SCORES ""AS IS"" WITHOUT WARRANTY OF ANY KIND, INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. CUSTOMERS ARE RESPONSIBLE FOR ASSESSING THE IMPACT OF ANY ACTUAL OR POTENTIAL SECURITY VULNERABILITY. In addition to other efforts to address potential vulnerabilities, IBM periodically updates the record of components contained in our product offerings. As part of that effort, if IBM identifies previously unidentified packages in a product/service inventory, we address relevant vulnerabilities regardless of CVE date. Inclusion of an older CVEID does not demonstrate that the referenced product has been used by IBM since that date, nor that IBM was aware of a vulnerability as of that date. We are making clients aware of relevant vulnerabilities as we become aware of them. "Affected Products and Versions" referenced in IBM Security Bulletins are intended to be only products and versions that are supported by IBM and have not passed their end-of-support or warranty date. Thus, failure to reference unsupported or extended-support products and versions in this Security Bulletin does not constitute a determination by IBM that they are unaffected by the vulnerability. Reference to one or more unsupported versions in this Security Bulletin shall not create an obligation for IBM to provide fixes for any unsupported or extended-support products or versions.

**Document Location**

Worldwide

\[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\\/TPS"},"Product":{"code":"SSWFB4","label":"IBM Spectrum Control Standard Edition"},"Component":"N\\/A","Platform":\[{"code":"PF002","label":"AIX"},{"code":"PF016","label":"Linux"},{"code":"PF033","label":"Windows"}\],"Version":"5.4","Edition":"ALL","Line of Business":{"code":"LOB26","label":"Storage"}}\]

CVE-2022-38391: Security Bulletin: IBM Spectrum Control is vulnerable to multiple weaknesses related IBM WebSphere Application Server Liberty and FasterXML jackson-databind

IBM AIX 7.1, 7.2, 7.3, and VIOS 3.1could allow a local user with elevated privileges to exploit a vulnerability in the lpd daemon to cause a denial of service. IBM X-Force ID: 238641.

  

**Summary**

A vulnerability in the AIX lpd printer daemon could allow a local user with elevated privileges to cause a denial of service (CVE-2022-43382). The lpd daemon is the remote print server on AIX.

**Vulnerability Details**

**CVEID:**   CVE-2022-43382  
**DESCRIPTION:**   IBM AIX could allow a local user with elevated privileges to exploit a vulnerability in the lpd daemon to cause a denial of service.  
CVSS Base score: 6.2  
CVSS Temporal Score: See: https://exchange.xforce.ibmcloud.com/vulnerabilities/238641 for the current score.  
CVSS Vector: (CVSS:3.0/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)

**Affected Products and Versions**

Affected Product(s)

Version(s)

AIX

7.1

AIX

7.2

AIX

7.3

VIOS

3.1

The following fileset levels are vulnerable:

Fileset

Lower Level

Upper Level

bos.rte.printers

7.1.5.0

7.1.5.33

printers.rte

7.1.5.0

7.1.5.31

bos.rte.printers

7.2.5.0

7.2.5.1

bos.rte.printers

7.2.5.100

7.2.5.100

printers.rte

7.2.4.0

7.2.4.0

printers.rte

7.2.5.200

7.2.5.200

bos.rte.printers

7.3.0.0

7.3.0.0

printers.rte

7.3.0.0

7.3.0.0

printers.rte

7.3.1.0

7.3.1.0

To find out whether the affected filesets are installed on your systems, refer to the lslpp command found in the AIX user's guide.

Example: lslpp -L | grep -i bos.rte.printers

  

**Remediation/Fixes**

**A. APARS**

IBM has assigned the following APARs to this problem:

AIX Level

APAR

SP

7.1.5

IJ44552

SP11

7.2.5

IJ44559

SP06

7.3.0

IJ42800

SP03

7.3.1

IJ44564

SP02

VIOS Level

APAR

SP

3.1.2

IJ44615

3.1.2.50

3.1.3

IJ42162

3.1.3.30

3.1.4

IJ44559

3.1.4.20

Subscribe to the APARs here:

https://www.ibm.com/support/pages/apar/IJ42162

https://www.ibm.com/support/pages/apar/IJ42800

https://www.ibm.com/support/pages/apar/IJ44552

https://www.ibm.com/support/pages/apar/IJ44559

https://www.ibm.com/support/pages/apar/IJ44564

https://www.ibm.com/support/pages/apar/IJ44615

By subscribing, you will receive periodic email alerting you to the status of the APAR, and a link to download the fix once it becomes available.

**B. FIXES**

IBM strongly recommends addressing the vulnerability now.

The fixes can be downloaded via ftp or http from:

ftp://aix.software.ibm.com/aix/efixes/security/lpd\_fix3.tar

http://aix.software.ibm.com/aix/efixes/security/lpd\_fix3.tar

https://aix.software.ibm.com/aix/efixes/security/lpd\_fix3.tar

The links above are to a tar file containing this signed advisory, fix packages, and OpenSSL signatures for each package. The fixes below include prerequisite checking. This will enforce the correct mapping between the fixes and AIX Technology Levels.

AIX Level

Interim Fix

7.1.5.8

IJ44552mAa.221208.epkg.Z

7.1.5.9

IJ44552mAa.221208.epkg.Z

7.1.5.10

IJ44552mAa.221208.epkg.Z

7.2.5.3

IJ44559m4a.221214.epkg.Z

7.2.5.4

IJ44559m4a.221214.epkg.Z

7.2.5.5

IJ44559m5a.221208.epkg.Z

7.3.0.1

IJ42800m2a.221208.epkg.Z

7.3.0.2

IJ42800m2a.221208.epkg.Z

7.3.1.1

IJ44564m1a.221208.epkg.Z

Please note that the above table refers to AIX TL/SP level as opposed to fileset level, i.e., 7.2.5.4 is AIX 7200-05-04.

Please reference the Affected Products and Version section above for help with checking installed fileset levels.

VIOS Level

Interim Fix

3.1.2.21

IJ44615m2a.221213.epkg.Z

3.1.2.30

IJ44615m2a.221213.epkg.Z

3.1.2.40

IJ44615m2a.221213.epkg.Z

3.1.3.10

IJ42162m4a.221208.epkg.Z

3.1.3.14

IJ42162m4a.221208.epkg.Z

3.1.3.21

IJ42162m4a.221208.epkg.Z

3.1.4.10

IJ44559m5a.221208.epkg.Z

The fixes are cumulative and address the previously issued AIX/VIOS lpd security bulletin with respect to SP and TL:

https://aix.software.ibm.com/aix/efixes/security/lpd\_advisory2.asc

https://www.ibm.com/support/pages/node/6594859

To extract the fixes from the tar file:

tar xvf lpd\_fix3.tar

cd lpd\_fix3

Verify you have retrieved the fixes intact:

The checksums below were generated using the "openssl dgst -sha256 \[file\]" command as the following:

openssl dgst -sha256

filename

9dbee1f9ad2158e491a36186236a776086ae4a3e6ec65052c84688c2412bec3c

IJ42162m4a.221208.epkg.Z

6c3b3f0c7521e46d6071fa62517173de68768487b34260b8b3641391ee194886

IJ42800m2a.221208.epkg.Z

29594f99310e866eaca906730d347b1a9e976212d708a3d95f6c70b517d96b23

IJ44552mAa.221208.epkg.Z

328df5737201ed540a0b011da0cca28a51b182286a12280a21537cff4b5638ce

IJ44559m4a.221214.epkg.Z

b7ab294f33bddb6679157b9e55d0fd3e822c8d7259e119ccc00b027a7f934642

IJ44559m5a.221208.epkg.Z

371bec45e77ec860b79ee3759feedf5b00ea22098c6a79ea9f51d3e0852b6888

IJ44564m1a.221208.epkg.Z

bb941b81852b4a46944ac793173998a714d6facd8af36e0ca63f300bd3c091ef

IJ44615m2a.221213.epkg.Z

These sums should match exactly. The OpenSSL signatures in the tar file and on this advisory can also be used to verify the integrity of the fixes. If the sums or signatures cannot be confirmed, contact IBM AIX Support at https://ibm.com/support/ and describe the discrepancy.

openssl dgst -sha256 -verify \[pubkey\_file\] -signature \[advisory\_file\].sig \[advisory\_file\]

openssl dgst -sha256 -verify \[pubkey\_file\] -signature \[ifix\_file\].sig \[ifix\_file\]

Published advisory OpenSSL signature file location:

http://aix.software.ibm.com/aix/efixes/security/lpd\_advisory3.asc.sig

https://aix.software.ibm.com/aix/efixes/security/lpd\_advisory3.asc.sig

ftp://aix.software.ibm.com/aix/efixes/security/lpd\_advisory3.asc.sig

**C. FIX AND INTERIM FIX INSTALLATION**

Interim fixes have had limited functional and regression testing but not the full regression testing that takes place for Service Packs; however, IBM does fully support them.

Interim fix management documentation can be found at:

http://www14.software.ibm.com/webapp/set2/sas/f/aix.efixmgmt/home.html

To preview an interim fix installation:

emgr -e ipkg\_name -p # where ipkg\_name is the name of the

\# interim fix package being previewed.

To install an interim fix package:

emgr -e ipkg\_name -X # where ipkg\_name is the name of the

\# interim fix package being installed.

**Workarounds and Mitigations**

None

**References**

Off

**Change History**

14 Dec 2022: Initial Publication

\*The CVSS Environment Score is customer environment specific and will ultimately impact the Overall CVSS Score. Customers can evaluate the impact of this vulnerability in their environments by accessing the links in the Reference section of this Security Bulletin.

**Disclaimer**

According to the Forum of Incident Response and Security Teams (FIRST), the Common Vulnerability Scoring System (CVSS) is an "industry open standard designed to convey vulnerability severity and help to determine urgency and priority of response." IBM PROVIDES THE CVSS SCORES ""AS IS"" WITHOUT WARRANTY OF ANY KIND, INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. CUSTOMERS ARE RESPONSIBLE FOR ASSESSING THE IMPACT OF ANY ACTUAL OR POTENTIAL SECURITY VULNERABILITY. In addition to other efforts to address potential vulnerabilities, IBM periodically updates the record of components contained in our product offerings. As part of that effort, if IBM identifies previously unidentified packages in a product/service inventory, we address relevant vulnerabilities regardless of CVE date. Inclusion of an older CVEID does not demonstrate that the referenced product has been used by IBM since that date, nor that IBM was aware of a vulnerability as of that date. We are making clients aware of relevant vulnerabilities as we become aware of them. "Affected Products and Versions" referenced in IBM Security Bulletins are intended to be only products and versions that are supported by IBM and have not passed their end-of-support or warranty date. Thus, failure to reference unsupported or extended-support products and versions in this Security Bulletin does not constitute a determination by IBM that they are unaffected by the vulnerability. Reference to one or more unsupported versions in this Security Bulletin shall not create an obligation for IBM to provide fixes for any unsupported or extended-support products or versions.

**Document Location**

Worldwide

\[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\\/TPS"},"Product":{"code":"SWG10","label":"AIX"},"Component":"","Platform":\[{"code":"PF002","label":"AIX"}\],"Version":"7.1,7.2,7.3","Edition":"","Line of Business":{"code":"LOB08","label":"Cognitive Systems"}},{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\\/TPS"},"Product":{"code":"SSPHKW","label":"PowerVM Virtual I\\/O Server"},"Component":"","Platform":\[{"code":"PF002","label":"AIX"}\],"Version":"3.1","Edition":"","Line of Business":{"code":"LOB57","label":"Power"}}\]

CVE-2022-43382: Security Bulletin: AIX is vulnerable to a denial of service due to lpd (CVE-2022-43382)

An issue in the firmware update process of TP-Link TL-WA901ND V1 up to v3.11.2 and TL-WA901N V2 up to v3.12.16 allows attackers to execute arbitrary code or cause a Denial of Service (DoS) via uploading a crafted firmware image.

\# A Firmware Modification Vulnerability During Firmware Update in TP-Link TL-WA901N / TL-WA901ND Wireless Access Point ## Affected Products: We have tested on the following devices: - TP-LINK TL-WA901N / TL-WA901ND V1 (firmware version: 3.11.2 and earlier) - TP-LINK TL-WA901N / TL-WA901ND V2 (firmware version: 3.12.16 and earlier) Also, we suspect it may also work on other models of TL-WA901N / TL-WA901ND series devices. ## Overview: An exploitable firmware modification vulnerability was discovered on the TP-Link TL-WA901N / TL-WA901ND wireless access points. A specially crafted firmware update image can allow an attacker to bypass the firmware verification in the firmware update process and install a malicious firmware image, thus resulting in either denial-of-service (DoS) or malware or backdoor planting. This vulnerability could be triggered during a user performing a firmware update with a self-uploaded firmware image. During the firmware delivery, the attacker can replace the user-uploaded firmware image with the malicious firmware image.  ## Details: When performing a firmware update, users can download a new firmware image from the vendor server and upload it via the web interface of the device. The structure of the uploaded firmware image is \[header, bootloader, header, kernel, rootfs\]. It is worth noting that each header contains an \*\*MD5 checksum\*\*, which is used to verify the data integrity of the firmware. When a firmware image is uploaded, the web server will calculate the image checksums and compare them with the checksum values in the headers. The decompiled function that is used to verify the firmware image is shown below. \`\`\` undefined4 upgradeFirmware(int param\_1,int param\_2) { ... if (param\_2 - 0x30000U < 0x7d0001) { iVar8 = check\_filesize(param\_2); if (iVar8 != 0) { iVar8 = isSysUpgradeNeedChecksum(); if (iVar8 != 0) { local\_30 = \*(undefined4 \*)(param\_1 + 0x4c); local\_2c = \*(undefined4 \*)(param\_1 + 0x50); local\_28 = \*(undefined4 \*)(param\_1 + 0x54); local\_24 = \*(undefined4 \*)(param\_1 + 0x58); pcVar11 = getMd5Key; if (\*(int \*)(param\_1 + 0x94) != 0) { pcVar11 = getMd5Key\_bootloader; } ... iVar8 = md5\_verify\_digest(&local\_30,param\_1,param\_2); if (iVar8 == 0) { printf("image md5 checksum is not correct!\\n\\r"); \*(undefined4 \*)(param\_1 + 0x58) = local\_24; \*(undefined4 \*)(param\_1 + 0x4c) = local\_30; \*(undefined4 \*)(param\_1 + 0x50) = local\_2c; \*(undefined4 \*)(param\_1 + 0x54) = local\_28; return 0x4655; } \*(undefined4 \*)(param\_1 + 0x50) = local\_2c; \*(undefined4 \*)(param\_1 + 0x4c) = local\_30; \*(undefined4 \*)(param\_1 + 0x54) = local\_28; \*(undefined4 \*)(param\_1 + 0x58) = local\_24; } if (((DAT\_10002810 != 0) && (iVar8 = isFreeUpdate(), iVar8 == 0)) && ((iVar8 = getProductId(), \*(int \*)(param\_1 + 0x40) != iVar8 || (iVar8 = getProductVer(), \*(int \*)(param\_1 + 0x44) != iVar8)))) { printf("Firmware version check failed"); return 0x4655; } ... } \`\`\` However, the communication during firmware delivery uses the plain HTTP protocol, which does not provide any cryptographic protection of the uploaded contents. Also, there is no signature verification for the update firmware image. Therefore, an attacker with a privileged network position (which could be obtained via ARP spoofing, DNS spoofing, or other approaches) can exploit this issue in order to provide customized malicious firmware updates. Specifically, the attack could replace several bytes in the kernel with arbitrary bytes and replace the checksums in the header after calculating the checksums of the modified firmware image. In this way, a customized malicious firmware image is crafted. During the firmware update process, the attacker can replace the user-uploaded firmware with the crafted firmware, which then causes the device to no longer work or planted with backdoors or malware. The vulnerability has been successfully exploited by creating a proof-of-concept. Take TL-WA901ND V1 (firmware version: 3.11.2) as an example. In this our case, we modified the 4 bytes (address range: 0x20800 to 0x20803) with value 0x9A1B21FF to 0x00000000. Then we modified the checksum fields in the firmware header, the firmware headers before and after modification are listed below. !\[\](https://i.imgur.com/oMUSf9K.png) \*Fig. 2. The original MD5 checksum field in the firmware header.\* \*The original firmware header information:\* \`\`\` Filename : wa901nv1\_en\_3\_11\_2\_up\_boot(100429).bin Filesize : 0x003e0200 / 4063744 Image Vendor : TP-LINK Technologies Image Version : ver. 1.0 Image Size : 0x003e0200 / 4063744 Image Checksum : 08 f5 c5 a5 58 39 1e 73 e4 55 38 a0 b3 4a 14 15 (Valid) Product Id : 0x09010001 (TL-WA901NDv1) Product Version : 0x00000001 Firmware Version : 0.0.0 Bootldr Offset : 0x00000000 / 0 Bootldr Length : 0x0001e0dc / 123100 Image2 Size : 0x003c0000 / 3932160 Image2 Checksum : 4c 70 4a cf 43 c0 51 7d 0d db 8f 01 ba c5 b7 56 (Valid) Kernel Offset : 0x00000200 / 512 Kernel Length : 0x000c70b7 / 815287 Kernel Load Address: 0x80002000 Kernel Entry Point : 0x801a2000 Kernel Checksum : 08 d7 52 57 5c 67 6c 1c 4e 24 0a 0e e5 f2 c7 20 (Not Verified) Rootfs Offset : 0x00100000 / 1048576 Rootfs Length : 0x002c0000 / 2883584 \`\`\` --- !\[\](https://i.imgur.com/Xfp936v.png) \*Fig. 3. The modified MD5 checksum field in the firmware header.\* \*The modified firmware header information:\* \`\`\` Filename : wa901nv1\_en\_3\_11\_2\_up\_boot(100429).bin-new Filesize : 0x003e0200 / 4063744 Image Vendor : TP-LINK Technologies Image Version : ver. 1.0 Image Size : 0x003e0200 / 4063744 Image Checksum : e8 56 f8 c4 98 d9 36 09 b3 14 a1 50 4a 8d 08 fa (Valid) Product Id : 0x09010001 (TL-WA901NDv1) Product Version : 0x00000001 Firmware Version : 0.0.0 Bootldr Offset : 0x00000000 / 0 Bootldr Length : 0x0001e0dc / 123100 Image2 Size : 0x003c0000 / 3932160 Image2 Checksum : 79 e6 c6 c4 60 a8 18 db 43 4a dd 4f b1 7b 81 ba (Valid) Kernel Offset : 0x00000200 / 512 Kernel Length : 0x000c70b7 / 815287 Kernel Load Address: 0x80002000 Kernel Entry Point : 0x801a2000 Kernel Checksum : 08 d7 52 57 5c 67 6c 1c 4e 24 0a 0e e5 f2 c7 20 (Not Verified) Rootfs Offset : 0x00100000 / 1048576 Rootfs Length : 0x002c0000 / 2883584 \`\`\` After replacing the original firmware image with the crafted firmware image during the firmware update procedure, the firmware verification is passed and then the malicious firmware is flashed into the device. Until now, the firmware modification attack is launched successfully.

CVE-2022-46910: A Firmware Modification Vulnerability During Firmware Update in TP-Link TL-WA901N / TL-WA901ND Wireless Access Point - HackMD

An exploitable firmware modification vulnerability was discovered on TP-Link TL-WR743ND V1. An attacker can conduct a MITM (Man-in-the-Middle) attack to modify the user-uploaded firmware image and bypass the CRC check, allowing attackers to execute arbitrary code or cause a Denial of Service (DoS). This affects v3.12.20 and earlier.

\# A Firmware Modification Vulnerability During Firmware Update in TP-Link TL-WR743ND Wireless Routers ## Affected Products: We have tested on the TP-Link TL-WR743ND V1 (Firmware Version: 3.12.20 and earlier) device. Also, we suspect it may also work on other models of TL-WR743ND series devices. ## Overview: An exploitable firmware modification vulnerability was discovered on the TP-Link TL-WR743ND wireless routers. A specially crafted firmware update image can allow an attacker to bypass the firmware verification in the firmware update process and install a malicious firmware image, thus resulting in either denial-of-service (DoS) or malware or backdoor planting. This vulnerability could be triggered during a user performing a firmware update with a self-uploaded firmware image. During the firmware delivery, the attacker can replace the user-uploaded firmware image with the malicious firmware image. ## Details: When performing a firmware update, users can download a new firmware image from the vendor server and upload it via the web interface of the device. The firmware update web interface is shown below. !\[\](https://i.imgur.com/tGSS0ec.png) \*Fig. 1. The web interface for firmware update.\* The structure of the firmware image is \[header, bootloader, header, kernel, rootfs\]. It is worth noting that each header contains an \*\*MD5 checksum\*\*, which is used to verify the data integrity of the firmware. When a firmware image is uploaded, the web server will calculate the image checksums and compare them with the checksum values in the headers. The decompiled function that is used to verify the firmware image is shown below. \`\`\` undefined4 upgradeFirmware(int param\_1,int param\_2) { ... if (param\_2 - 0x30000U < 0x7d0001) { iVar8 = check\_filesize(param\_2); if (iVar8 != 0) { iVar8 = isSysUpgradeNeedChecksum(); if (iVar8 != 0) { local\_30 = \*(undefined4 \*)(param\_1 + 0x4c); local\_2c = \*(undefined4 \*)(param\_1 + 0x50); local\_28 = \*(undefined4 \*)(param\_1 + 0x54); local\_24 = \*(undefined4 \*)(param\_1 + 0x58); pcVar11 = getMd5Key; if (\*(int \*)(param\_1 + 0x94) != 0) { pcVar11 = getMd5Key\_bootloader; } ... iVar8 = md5\_verify\_digest(&local\_30,param\_1,param\_2); if (iVar8 == 0) { printf("image md5 checksum is not correct!\\n\\r"); \*(undefined4 \*)(param\_1 + 0x58) = local\_24; \*(undefined4 \*)(param\_1 + 0x4c) = local\_30; \*(undefined4 \*)(param\_1 + 0x50) = local\_2c; \*(undefined4 \*)(param\_1 + 0x54) = local\_28; return 0x4655; } \*(undefined4 \*)(param\_1 + 0x50) = local\_2c; \*(undefined4 \*)(param\_1 + 0x4c) = local\_30; \*(undefined4 \*)(param\_1 + 0x54) = local\_28; \*(undefined4 \*)(param\_1 + 0x58) = local\_24; } if (((DAT\_100027f0 != 0) && (iVar8 = isFreeUpdate(), iVar8 == 0)) && ((iVar8 = getProductId(), \*(int \*)(param\_1 + 0x40) != iVar8 || (iVar8 = getProductVer(), \*(int \*)(param\_1 + 0x44) != iVar8)))) { printf("Firmware version check failed"); return 0x4655; } ... } \`\`\` However, the communication during firmware delivery uses the plain HTTP protocol, which does not provide any cryptographic protection of the uploaded contents. Also, there is no signature verification for the update firmware image. Therefore, an attacker with a privileged network position (which could be obtained via ARP spoofing, DNS spoofing, or other approaches) can exploit this issue in order to provide customized malicious firmware updates. Specifically, the attack could replace several bytes in the kernel with arbitrary bytes and replace the checksums in the header after calculating the checksums of the modified firmware image. In this way, a customized malicious firmware image is crafted. During the firmware update process, the attacker can replace the user-uploaded firmware with the crafted firmware, which then causes the device to no longer work or planted with backdoors or malware. The vulnerability has been successfully exploited by creating a proof-of-concept. In this our case, we modified the 4 bytes (offset range: 0x102C to 0x102F) with value 0x077C6EC0 to 0x00000000. Then we modified the checksum fields in the firmware header, the firmware headers before and after modification are listed below. !\[\](https://i.imgur.com/cvHig9Y.png) \*Fig. 2. The original MD5 checksum field in the firmware header.\* \*The original firmware header information:\* \`\`\` Filename : wr743ndv1\_en\_3\_12\_20\_up\_boot(130109).bin Filesize : 0x003e0200 / 4063744 Image Vendor : TP-LINK Technologies Image Version : ver. 1.0 Image Size : 0x003e0200 / 4063744 Image Checksum : 04 d5 e5 40 d0 9c 34 c4 3d a3 fd aa df b6 3f 40 (Valid) Product Id : 0x07430001 Product Version : 0x00000001 Firmware Version : 3.12.20 Bootldr Offset : 0x00000000 / 0 Bootldr Length : 0x0001e250 / 123472 Image2 Size : 0x003c0000 / 3932160 Image2 Checksum : 28 38 4b 7e 5f 69 a9 b6 45 4c e4 b3 37 7a a8 c9 (Valid) Kernel Offset : 0x00000200 / 512 Kernel Length : 0x000c6fb4 / 815028 Kernel Load Address: 0x80002000 Kernel Entry Point : 0x801a2000 Kernel Checksum : e4 fd 7d bd 42 c7 8e 4d 72 8a ae 7d 17 70 77 f5 (Not Verified) Rootfs Offset : 0x00100000 / 1048576 Rootfs Length : 0x002c0000 / 2883584 \`\`\` --- !\[\](https://i.imgur.com/qr86GaF.png) \*Fig. 3. The modified MD5 checksum field in the firmware header.\* \*The modified firmware header information:\* \`\`\` Filename : wr743ndv1\_en\_3\_12\_20\_up\_boot(130109).bin Filesize : 0x003e0200 / 4063744 Image Vendor : TP-LINK Technologies Image Version : ver. 1.0 Image Size : 0x003e0200 / 4063744 Image Checksum : 84 8c a9 67 87 80 93 a4 0d 8a bb 40 dc 71 13 26 (Valid) Product Id : 0x07430001 Product Version : 0x00000001 Firmware Version : 3.12.20 Bootldr Offset : 0x00000000 / 0 Bootldr Length : 0x0001e250 / 123472 Image2 Size : 0x003c0000 / 3932160 Image2 Checksum : e6 e6 e4 5d bf aa 31 1f 15 ba 1d ab 91 2e 2c 80 (Valid) Kernel Offset : 0x00000200 / 512 Kernel Length : 0x000c6fb4 / 815028 Kernel Load Address: 0x80002000 Kernel Entry Point : 0x801a2000 Kernel Checksum : e4 fd 7d bd 42 c7 8e 4d 72 8a ae 7d 17 70 77 f5 (Not Verified) Rootfs Offset : 0x00100000 / 1048576 Rootfs Length : 0x002c0000 / 2883584 \`\`\` After replacing the original firmware image with the crafted firmware image during the firmware update procedure, the firmware verification is passed and then the malicious firmware is flashed into the device. Until now, the firmware modification attack is launched successfully.

CVE-2022-46432: A Firmware Modification Vulnerability During Firmware Update in TP-Link TL-WR743ND Wireless Routers - HackMD

An issue in the firmware update process of TP-Link TL-WA7510N v1 v3.12.6 and earlier allows attackers to execute arbitrary code or cause a Denial of Service (DoS) via uploading a crafted firmware image.

\# A Firmware Modification Vulnerability During Firmware Update in TP-Link TL-WA7510N V1 Wireless Access Point ## Affected Products: We have tested on the TP-Link TL-WA7510N V1 (firmware version: 3.12.6 and earlier) device. Also, we suspect it may also work on other models of TL-WA7510N series devices. ## Overview: An exploitable firmware modification vulnerability was discovered on the TP-Link TL-WA7510N wireless access points. A specially crafted firmware update image can allow an attacker to bypass the firmware verification in the firmware update process and install a malicious firmware image, thus resulting in either denial-of-service (DoS) or malware or backdoor planting. This vulnerability could be triggered during a user performing a firmware update with a self-uploaded firmware image. During the firmware delivery, the attacker can replace the user-uploaded firmware image with the malicious firmware image. ## Details: When performing a firmware update, users can download a new firmware image from the vendor server and upload it via the web interface of the device. The firmware update web interface is shown below. !\[\](https://i.imgur.com/SWc6ulB.png) \*Fig. 1. The web interface for firmware update.\* The structure of the firmware image is \[header, bootloader, header, kernel, rootfs\]. It is worth noting that each header contains an \*\*MD5 checksum\*\*, which is used to verify the data integrity of the firmware. When a firmware image is uploaded, the web server will calculate the image checksums and compare them with the checksum values in the headers. The decompiled function that is used to verify the firmware image is shown below. \`\`\` undefined4 upgradeFirmware(int param\_1,int param\_2) { ... if (param\_2 - 0x30000U < 0x7d0001) { iVar8 = check\_filesize(param\_2); if (iVar8 != 0) { iVar8 = isSysUpgradeNeedChecksum(); if (iVar8 != 0) { local\_30 = \*(undefined4 \*)(param\_1 + 0x4c); local\_2c = \*(undefined4 \*)(param\_1 + 0x50); local\_28 = \*(undefined4 \*)(param\_1 + 0x54); local\_24 = \*(undefined4 \*)(param\_1 + 0x58); pcVar11 = getMd5Key; if (\*(int \*)(param\_1 + 0x94) != 0) { pcVar11 = getMd5Key\_bootloader; } ... iVar8 = md5\_verify\_digest(&local\_30,param\_1,param\_2); if (iVar8 == 0) { printf("image md5 checksum is not correct!\\n\\r"); \*(undefined4 \*)(param\_1 + 0x58) = local\_24; \*(undefined4 \*)(param\_1 + 0x4c) = local\_30; \*(undefined4 \*)(param\_1 + 0x50) = local\_2c; \*(undefined4 \*)(param\_1 + 0x54) = local\_28; return 0x4655; } \*(undefined4 \*)(param\_1 + 0x50) = local\_2c; \*(undefined4 \*)(param\_1 + 0x4c) = local\_30; \*(undefined4 \*)(param\_1 + 0x54) = local\_28; \*(undefined4 \*)(param\_1 + 0x58) = local\_24; } if (((DAT\_10005820 != 0) && (iVar8 = isFreeUpdate(), iVar8 == 0)) && ((iVar8 = getProductId(), \*(int \*)(param\_1 + 0x40) != iVar8 || (iVar8 = getProductVer(), \*(int \*)(param\_1 + 0x44) != iVar8)))) { printf("Firmware version check failed"); return 0x4655; } ... } \`\`\` However, the communication during firmware delivery uses the plain HTTP protocol, which does not provide any cryptographic protection of the uploaded contents. Also, there is no signature verification for the update firmware image. Therefore, an attacker with a privileged network position (which could be obtained via ARP spoofing, DNS spoofing, or other approaches) can exploit this issue in order to provide customized malicious firmware updates. Specifically, the attack could replace several bytes in the kernel with arbitrary bytes and replace the checksums in the header after calculating the checksums of the modified firmware image. In this way, a customized malicious firmware image is crafted. During the firmware update process, the attacker can replace the user-uploaded firmware with the crafted firmware, which then causes the device to no longer work or planted with backdoors or malware. The vulnerability has been successfully exploited by creating a proof-of-concept. In this our case, we modified the 4 bytes (address range: 0x207A0 to 0x207A3) with value 0x17F64643 to 0x00000000. Then we modified the checksum fields in the firmware header, the firmware headers before and after modification are listed below. !\[\](https://i.imgur.com/T7b1bKW.png) \*Fig. 2. The original MD5 checksum field in the firmware header.\* \*The original firmware header information:\* \`\`\` Filename : wa7510nv1\_en\_3\_12\_6\_up\_boot(130427).bin Filesize : 0x003e0200 / 4063744 Image Vendor : TP-LINK Technologies Image Version : ver. 1.0 Image Size : 0x003e0200 / 4063744 Image Checksum : 6f 16 2d 3e 23 98 fc cf 81 67 61 ac 60 11 e9 8d (Valid) Product Id : 0x75100001 Product Version : 0x00000001 Firmware Version : 3.12.6 Bootldr Offset : 0x00000000 / 0 Bootldr Length : 0x0001e40c / 123916 Image2 Size : 0x003c0000 / 3932160 Image2 Checksum : 27 54 5e a7 f6 ae aa dc ee 2b ea d0 c8 e8 71 bc (Valid) Kernel Offset : 0x00000200 / 512 Kernel Length : 0x000c70d7 / 815319 Kernel Load Address: 0x80002000 Kernel Entry Point : 0x801a2000 Kernel Checksum : be e0 c9 2c dc 66 74 b4 5f 5e 0d 29 61 3f c3 14 (Not Verified) Rootfs Offset : 0x00100000 / 1048576 Rootfs Length : 0x002c0000 / 2883584 \`\`\` --- !\[\](https://i.imgur.com/YtmcPEP.png) \*Fig. 3. The modified MD5 checksum field in the firmware header.\* \*The modified firmware header information:\* \`\`\` Filename : wa7510nv1\_en\_3\_12\_6\_up\_boot(130427).bin Filesize : 0x003e0200 / 4063744 Image Vendor : TP-LINK Technologies Image Version : ver. 1.0 Image Size : 0x003e0200 / 4063744 Image Checksum : 03 0a 1a 0d 73 5b 5f bb 63 e3 40 5a ba ae cf 7d (Valid) Product Id : 0x75100001 Product Version : 0x00000001 Firmware Version : 3.12.6 Bootldr Offset : 0x00000000 / 0 Bootldr Length : 0x0001e40c / 123916 Image2 Size : 0x003c0000 / 3932160 Image2 Checksum : b6 83 a3 99 28 b4 e0 0a 51 d8 ab ce 9c 49 4e d3 (Valid) Kernel Offset : 0x00000200 / 512 Kernel Length : 0x000c70d7 / 815319 Kernel Load Address: 0x80002000 Kernel Entry Point : 0x801a2000 Kernel Checksum : be e0 c9 2c dc 66 74 b4 5f 5e 0d 29 61 3f c3 14 (Not Verified) Rootfs Offset : 0x00100000 / 1048576 Rootfs Length : 0x002c0000 / 2883584 \`\`\` After replacing the original firmware image with the crafted firmware image during the firmware update procedure, the firmware verification is passed and then the malicious firmware is flashed into the device. Until now, the firmware modification attack is launched successfully.

CVE-2022-46434: A Firmware Modification Vulnerability During Firmware Update in TP-Link TL-WA7510N V1 Wireless Access Point - HackMD

An issue in the firmware update process of TP-Link TL-WR941ND V2/V3 up to 3.13.9 and TL-WR941ND V4 up to 3.12.8 allows attackers to execute arbitrary code or cause a Denial of Service (DoS) via uploading a crafted firmware image.

\# A Firmware Modification Vulnerability During Firmware Update in TP-Link TL-WR941ND Wireless Routers ## Affected Products: We have tested on the following devices: - TP-Link TL-WR941ND V2/V3 (firmware version: 3.13.9 and earlier) - TP-Link TL-WR941ND V4 (firmware version: 3.12.8 and earlier) Also, we suspect it may also work on other models of TL-WR941ND/TL-WR941N series devices. ## Overview: An exploitable firmware modification vulnerability was discovered on the TP-Link TL-WR941ND V2 and V3 wireless routers. A specially crafted firmware update image can allow an attacker to bypass the firmware verification in the firmware update process and install a malicious firmware image, thus resulting in either denial-of-service (DoS) or malware or backdoor planting. This vulnerability could be triggered during a user performing a firmware update with a self-uploaded firmware image. During the firmware delivery, the attacker can replace the user-uploaded firmware image with the malicious firmware image. ## Details: When performing a firmware update, users can download a new firmware image from the vendor server and upload it via the web interface of the device. The firmware update web interface is shown below. !\[\](https://i.imgur.com/wETZCE1.png) \*Fig. 1. The web interface for firmware update.\* The structure of the firmware image is \[header, bootloader, header, kernel, rootfs\]. It is worth noting that each header contains an \*\*MD5 checksum\*\*, which is used to verify the data integrity of the firmware. When a firmware image is uploaded, the web server will calculate the image checksums and compare them with the checksum values in the headers. The decompiled function that is used to verify the firmware image is shown below. \`\`\` undefined4 upgradeFirmware(int param\_1,int param\_2) { ... if (param\_2 - 0x30000U < 0x7d0001) { iVar8 = check\_filesize(param\_2); if (iVar8 != 0) { iVar8 = isSysUpgradeNeedChecksum(); if (iVar8 != 0) { local\_30 = \*(undefined4 \*)(param\_1 + 0x4c); local\_2c = \*(undefined4 \*)(param\_1 + 0x50); local\_28 = \*(undefined4 \*)(param\_1 + 0x54); local\_24 = \*(undefined4 \*)(param\_1 + 0x58); pcVar11 = getMd5Key; if (\*(int \*)(param\_1 + 0x94) != 0) { pcVar11 = getMd5Key\_bootloader; } ... iVar8 = md5\_verify\_digest(&local\_30,param\_1,param\_2); if (iVar8 == 0) { printf("image md5 checksum is not correct!\\n\\r"); \*(undefined4 \*)(param\_1 + 0x58) = local\_24; \*(undefined4 \*)(param\_1 + 0x4c) = local\_30; \*(undefined4 \*)(param\_1 + 0x50) = local\_2c; \*(undefined4 \*)(param\_1 + 0x54) = local\_28; return 0x4655; } \*(undefined4 \*)(param\_1 + 0x50) = local\_2c; \*(undefined4 \*)(param\_1 + 0x4c) = local\_30; \*(undefined4 \*)(param\_1 + 0x54) = local\_28; \*(undefined4 \*)(param\_1 + 0x58) = local\_24; } if (((DAT\_10002810 != 0) && (iVar8 = isFreeUpdate(), iVar8 == 0)) && ((iVar8 = getProductId(), \*(int \*)(param\_1 + 0x40) != iVar8 || (iVar8 = getProductVer(), \*(int \*)(param\_1 + 0x44) != iVar8)))) { printf("Firmware version check failed"); return 0x4655; } ... } \`\`\` However, the communication during firmware delivery uses the plain HTTP protocol, which does not provide any cryptographic protection of the uploaded contents. Also, there is no signature verification for the update firmware image. Therefore, an attacker with a privileged network position (which could be obtained via ARP spoofing, DNS spoofing, or other approaches) can exploit this issue in order to provide customized malicious firmware updates. Specifically, the attack could replace several bytes in the kernel with arbitrary bytes and replace the checksums in the header after calculating the checksums of the modified firmware image. In this way, a customized malicious firmware image is crafted. During the firmware update process, the attacker can replace the user-uploaded firmware with the crafted firmware, which then causes the device to no longer work or planted with backdoors or malware. The vulnerability has been successfully exploited by creating a proof-of-concept. Take a TL-WR941ND V3 (firmware version: 3.13.9) device as an example. In this case, we modified the 4 bytes (address range: 0x400 to 0x403) with value 0xBB50EA2C to 0x00000000. Then we modified the checksum fields in the firmware header, the firmware headers before and after modification are listed below. !\[\](https://i.imgur.com/8kPVCri.png) \*Fig. 2. The original MD5 checksum field in the firmware header.\* \*The original firmware header information:\* \`\`\` Filename : wr941nv3\_en\_3\_13\_9\_up(120201).bin Filesize : 0x003c0000 / 3932160 Image Vendor : TP-LINK Technologies Image Version : ver. 1.0 Image Size : 0x003c0000 / 3932160 Image Checksum : a0 b1 9a 0f 99 cf 9f 04 72 7d c8 d0 5b 07 62 a4 (Valid) Product Id : 0x09410002 (TL-WR941NDv2) Product Version : 0x00000002 Firmware Version : 3.13.9 Kernel Offset : 0x00000200 / 512 Kernel Length : 0x000ca8ed / 829677 Kernel Load Address: 0x80002000 Kernel Entry Point : 0x801ae000 Kernel Checksum : 53 5f 84 d5 d4 c7 c0 85 b6 57 1e 4d a5 45 a1 ad (Not Verified) Rootfs Offset : 0x00100000 / 1048576 Rootfs Length : 0x002c0000 / 2883584 \`\`\` --- !\[\](https://i.imgur.com/RJR94at.png) \*Fig. 3. The modified MD5 checksum field in the firmware header.\* \*The modified firmware header information:\* \`\`\` Filename : wr941nv3\_en\_3\_13\_9\_up(120201).bin Filesize : 0x003c0000 / 3932160 Image Vendor : TP-LINK Technologies Image Version : ver. 1.0 Image Size : 0x003c0000 / 3932160 Image Checksum : b7 20 40 e9 f0 79 98 21 2b 1a b2 0d a7 eb 83 8b (Valid) Product Id : 0x09410002 (TL-WR941NDv2) Product Version : 0x00000002 Firmware Version : 3.13.9 Kernel Offset : 0x00000200 / 512 Kernel Length : 0x000ca8ed / 829677 Kernel Load Address: 0x80002000 Kernel Entry Point : 0x801ae000 Kernel Checksum : 53 5f 84 d5 d4 c7 c0 85 b6 57 1e 4d a5 45 a1 ad (Not Verified) Rootfs Offset : 0x00100000 / 1048576 Rootfs Length : 0x002c0000 / 2883584 \`\`\` After replacing the original firmware image with the crafted firmware image during the firmware update procedure, the firmware verification is passed and then the malicious firmware is flashed into the device. Until now, the firmware modification attack is launched successfully.

CVE-2022-46435: A Firmware Modification Vulnerability During Firmware Update in TP-Link TL-WR941ND Wireless Routers - HackMD

TP-Link TL-WR740N V1 and V2 v3.12.4 and earlier allows authenticated attackers to execute arbitrary code or cause a Denial of Service (DoS) via uploading a crafted firmware image during the firmware update process.

\# A Firmware Modification Vulnerability During Firmware Update in TP-Link TL-WR741ND and TL-WR740N Wireless Routers ## Affected Products: We have tested on the following devices: - TL-WR740N V1 and V2 (firmware version: 3.12.4 and earlier) - TL-WR741ND V1 and V2 (firmware version: 3.12.4 and earlier) Also, we suspect it may also work on other models of TL-WR741ND and TL-WR740N series devices. ## Overview: An exploitable firmware modification vulnerability was discovered on the TP-Link TL-WR741ND and TL-WR740N wireless routers. A specially crafted firmware update image can allow an attacker to bypass the firmware verification in the firmware update process and install a malicious firmware image, thus resulting in either denial-of-service (DoS) or malware or backdoor planting. This vulnerability could be triggered during a user performing a firmware update with a self-uploaded firmware image. During the firmware delivery, the attacker can replace the user-uploaded firmware image with the malicious firmware image. ## Details: When performing a firmware update, users can download a new firmware image from the vendor server and upload it via the web interface of the device. The firmware update web interface is shown below. !\[\](https://i.imgur.com/RIWj4Ku.png) \*Fig. 1. The web interface for firmware update.\* The structure of the firmware image is \[header, bootloader, header, kernel, rootfs\]. It is worth noting that each header contains an \*\*MD5 checksum\*\*, which is used to verify the data integrity of the firmware. When a firmware image is uploaded, the web server will calculate the image checksums and compare them with the checksum values in the headers. The decompiled function that is used to verify the firmware image is shown below. \`\`\` undefined4 upgradeFirmware(int param\_1,int param\_2) { ... if (param\_2 - 0x30000U < 0x7d0001) { iVar8 = check\_filesize(param\_2); if (iVar8 != 0) { iVar8 = isSysUpgradeNeedChecksum(); if (iVar8 != 0) { local\_30 = \*(undefined4 \*)(param\_1 + 0x4c); local\_2c = \*(undefined4 \*)(param\_1 + 0x50); local\_28 = \*(undefined4 \*)(param\_1 + 0x54); local\_24 = \*(undefined4 \*)(param\_1 + 0x58); pcVar11 = getMd5Key; if (\*(int \*)(param\_1 + 0x94) != 0) { pcVar11 = getMd5Key\_bootloader; } ... iVar8 = md5\_verify\_digest(&local\_30,param\_1,param\_2); if (iVar8 == 0) { printf("image md5 checksum is not correct!\\n\\r"); \*(undefined4 \*)(param\_1 + 0x58) = local\_24; \*(undefined4 \*)(param\_1 + 0x4c) = local\_30; \*(undefined4 \*)(param\_1 + 0x50) = local\_2c; \*(undefined4 \*)(param\_1 + 0x54) = local\_28; return 0x4655; } \*(undefined4 \*)(param\_1 + 0x50) = local\_2c; \*(undefined4 \*)(param\_1 + 0x4c) = local\_30; \*(undefined4 \*)(param\_1 + 0x54) = local\_28; \*(undefined4 \*)(param\_1 + 0x58) = local\_24; } if (((DAT\_100027d0 != 0) && (iVar8 = isFreeUpdate(), iVar8 == 0)) && ((iVar8 = getProductId(), \*(int \*)(param\_1 + 0x40) != iVar8 || (iVar8 = getProductVer(), \*(int \*)(param\_1 + 0x44) != iVar8)))) { printf("Firmware version check failed"); return 0x4655; } ... } \`\`\` However, the communication during firmware delivery uses the plain HTTP protocol, which does not provide any cryptographic protection of the uploaded contents. Also, there is no signature verification for the update firmware image. Therefore, an attacker with a privileged network position (which could be obtained via ARP spoofing, DNS spoofing, or other approaches) can exploit this issue in order to provide customized malicious firmware updates. Specifically, the attack could replace several bytes in the kernel with arbitrary bytes and replace the checksums in the header after calculating the checksums of the modified firmware image. In this way, a customized malicious firmware image is crafted. During the firmware update process, the attacker can replace the user-uploaded firmware with the crafted firmware, which then causes the device to no longer work or planted with backdoors or malware. The vulnerability has been successfully exploited by creating a proof-of-concept. Take a TL-WR741ND V2 (firmware version: 3.12.4) device as an example. In this case, we modified the 4 bytes (offset range: 0xF02 to 0xF05) with value 0xD4813CF9 to 0x00000000. Then we modified the checksum fields in the firmware header, the firmware headers before and after modification are listed below. !\[\](https://i.imgur.com/ddCGEDJ.png) \*Fig. 2. The original MD5 checksum field in the firmware header.\* \*The original firmware header information:\* \`\`\` Filename : wr741nv1\_en\_3\_12\_4\_up(100910).bin Filesize : 0x003c0000 / 3932160 Image Vendor : TP-LINK Technologies Image Version : ver. 1.0 Image Size : 0x003c0000 / 3932160 Image Checksum : fc c3 39 58 82 34 69 ce 7b 40 c1 5c e6 c2 f8 08 (Valid) Product Id : 0x07410001 Product Version : 0x00000001 Firmware Version : 0.0.0 Kernel Offset : 0x00000200 / 512 Kernel Length : 0x000c7c6c / 818284 Kernel Load Address: 0x80002000 Kernel Entry Point : 0x801a4000 Kernel Checksum : 4d 8e b2 8e b2 23 8d d0 c6 66 53 53 81 8e ce db (Not Verified) Rootfs Offset : 0x00100000 / 1048576 Rootfs Length : 0x002c0000 / 2883584 \`\`\` !\[\](https://i.imgur.com/9IFqrk6.png) \*Fig. 3. The modified MD5 checksum field in the firmware header.\* \*The modified firmware header information:\* \`\`\` Filename : wr741nv1\_en\_3\_12\_4\_up(100910).bin Filesize : 0x003c0000 / 3932160 Image Vendor : TP-LINK Technologies Image Version : ver. 1.0 Image Size : 0x003c0000 / 3932160 Image Checksum : 93 18 89 48 a8 56 9a 37 28 4c 19 2e 40 e1 1c 05 (Valid) Product Id : 0x07410001 Product Version : 0x00000001 Firmware Version : 0.0.0 Kernel Offset : 0x00000200 / 512 Kernel Length : 0x000c7c6c / 818284 Kernel Load Address: 0x80002000 Kernel Entry Point : 0x801a4000 Kernel Checksum : 4d 8e b2 8e b2 23 8d d0 c6 66 53 53 81 8e ce db (Not Verified) Rootfs Offset : 0x00100000 / 1048576 Rootfs Length : 0x002c0000 / 2883584 \`\`\` After replacing the original firmware image with the crafted firmware image during the firmware update procedure, the firmware verification is passed and then the malicious firmware is flashed into the device. Until now, the firmware modification attack is launched successfully.

Tag

#dos