CIP IEC-62443-4-2 SVV-4 testing ================================================================== .. contents:: Revision History .. list-table:: :header-rows: 1 * - Revision No - Date - Change description - Author - Reviewed by * - 001 - 2026-03-04 - SVV-4 testing details from BV test report and guidelines for CIP users - Dinesh Kumar - BV (Bureau Veritas) 1. About CIP SVV-4 testing -------------------------- SVV‑4 testing, also known as `Penetration Testing`, is a key activity defined under the IEC‑62443‑4‑1 secure development lifecycle. Product owners are expected to perform penetration testing during product development, as it can reveal vulnerabilities that other testing methods may not detect. As part of the CIP IEC‑62443 assessment, Bureau Veritas (BV) conducted SVV‑4 penetration testing and shared the detailed test report with CIP members. This document provides a concise overview of the BV SVV‑4 test report, its findings, and CIP’s analysis of the identified issues. Because SVV‑4 testing aims to strengthen the overall security posture of a product, not all detected issues are necessarily critical in the context of specific product use cases. This enables product users to perform their own security evaluation and make informed decisions about which issues require immediate remediation and which can be treated with lower priority. BV concluded that no critical security vulnerabilities were identified during the CIP SVV‑4 testing. Based on this outcome, CIP can determine any further actions required through its security analysis process. Though SVV-4 testing is part of secure developmnt process (IEC-62443-4-1). However, it's actually conducted during IEC-62443-4-2 assessment as it requires completely developed product. 2. BV SVV-4 test report summary ------------------------------- 2.1 Device Under Test (DUT) ~~~~~~~~~~~~~~~~~~~~~~~~~~~ +------------------+------------------------------------------------------------+ | Information | Manufacturer | +==================+============================================================+ | Model type | M-COM RT X86 V1 xSSD | +------------------+------------------------------------------------------------+ | Software Version | Linux Demo 6.1.131-cip39 | | | (isar-cip-core) Build_ID = v1.7 (Based on Debian Bookworm) | +------------------+------------------------------------------------------------+ | Hardware Version | M-COM RT x86 VT | +------------------+------------------------------------------------------------+ 2.2 Tools used ~~~~~~~~~~~~~~ +-------------+-----------+ | Tool name | Version | +=============+===========+ | Kali Linux | 2024.4 | +-------------+-----------+ | Wireshark | 4.6.0 | +-------------+-----------+ | Burp suite | 2024.9.4 | +-------------+-----------+ | binwalk | 2.4.3 | +-------------+-----------+ | ssh-keyscan | 1:9.9p1-3 | +-------------+-----------+ | nmap | 7.94 | +-------------+-----------+ 2.3 Security issues report ~~~~~~~~~~~~~~~~~~~~~~~~~~ **CVE-2025-32463** Following comment was shared by BV in the report. ``The details of the vulnerability shows that Sudo before 1.9.17p1 allows local users to obtain root access because /etc/nsswitch.conf from a user-controlled directory is used with the --chroot option. The test lab found the current Sudo version could be vulnerable to the CVE-2025-32463`` Following two exploits were used by BV to confirm if the device can be exploited. * https://www.exploit-db.com/exploits/52352 * https://github.com/MohamedKarrab/CVE-2025-32463 **BV remark** *CVE-2025-32463 exploitation was not possible under current sudo policy restrictions*; however, this does not conclusively indicate patching, as exploit failure was due to permission limitations rather than vulnerability absence. If sudoers policies are modified or a more privileged user is compromised, exploitation may become possible **CIP developers analysis** CIP evaluation image has sudo package version 1.9.13p3-1+deb12u2 installed. According to `NVD database page `__ . sudo package versions from 1.9.14 to 1.9.17 were affected by CVE-2025-32463. Therefore, no further action is required at CIP side. BV did not have any further comments about CIP analysis, according to them it's upto CIP to take further actions. **CVE-2023-40791** Following comment was shared by BV in the report. ``CVE-2023-40791 is a Linux kernel vulnerability caused by improper memory management in the extract_user_to_sg() function located in lib/scatterlist.c. This function is used to construct scatter/gather lists during data transfers between user space and kernel space.`` ``In Linux kernel versions prior to 6.4.12, under specific error-handling conditions, the function fails to correctly unpin previously pinned user memory pages. As a result, references to these memory pages are not properly released, which may lead to kernel warnings, memory leaks, and unstable kernel memory states. Although the issue does not directly result in arbitrary code execution, it may impact system stability and could potentially be abused as part of a broader exploitation chain.`` BV tried exploit code to exploit the device. The detail is not shared with CIP. however, the exploit was not successful based on BV comment in the report. **CIP developers analysis** The CIP kernel version installed on the evaluation image is 6.1.131-cip39. According to `NVD database page `__ affected kernel versions are up to (excluding 6.4.12). It indicates the CIP kernel version used in CIP security image was not affected kernel. However, it was confirmed the issue was fixed in later versions of `CIP kernel `__ **CVE-2023-42754** Following comment was shared by BV in the report. ``CVE-2023-42754 is a Linux kernel vulnerability affected versions up to (excluding) 6.6 involving a NULL pointer dereference in the IPv4 networking code of the kernel. Specifically, the kernel assumes that a network packet’s socket buffer (skb) is always tied to a network device before calling __ip_options_compile. In certain routing scenarios (e.g., when ipvs re-routes the packet), this assumption can be false, leading to a NULL pointer dereference and potentially allowing a local user with CAP_NET_ADMIN privileges to crash the system (denial of service).`` BV tried `exploit code `__. However, the exploit was not successful. **CIP developers analysis** This CVE was fixed in CIP kernel `v6.1.58-cip7 `__ The evaluation CIP kernel version is much later version 6.1.131-cip39. It means the CIP evaluation version already had fix included. BV could not provide any technical details for how this CVE impacts CIP kernel used in evaluation image. **CVE-2024-6387** Following comment was shared by BV in the report. ``By quickly extracting the public host key information from the target server, it was found that the server supports modern encryption algorithms (ECDSA, RSA, Ed25519), indicating a relatively high security standard of the target system. Additionally, we identified that the target is running the OpenSSH, version 9.2p1`` ``Researching vulnerabilities related to OpenSSH 9.2p1 revealed CVE-2024-6387, which affects OpenSSH version before 9.8p1, which might lead to direct remote code execution by race condition. An exploit code can be found on the ExploitDB (https://www.exploit-db.com/exploits/52269)`` **BV remark** ``Since Address Space Layout Randomization (ASLR) is enable by default making exploitation harder and more time-consuming, the exploitation is not successfully after 30 minutes attacks.`` ``CVE-2024-6387 is a race-condition vulnerability whose successful exploitation is probabilistic in nature. During testing, no successful exploitation was observed within the defined test duration. This result does not eliminate the presence of the vulnerability, but indicates that exploitation is highly timing-dependent and unreliable under the tested conditions. Furthermore, although Address Space Layout Randomization (ASLR) and system timing constraints significantly reduce the likelihood of successful exploitation, they do not eliminate the underlying vulnerability. Therefore, the system should be considered affected unless the vendor-provided patch has been applied.`` **CIP developers analysis** CIP evaluation has OpenSSH package version 1:9.2p1-2+deb12u7 installed in the image which is already including the fix for the reported CVE. According to `Debian Security tracker page `__ bookworm version 1:9.2p1-2+deb12u3 has a fix for the CVE. **Login credential shown in console issue** BV identified when CIP security image boots, it shows root user credntials on the console. Considering CIP image is a reference image and not a production image. This issue does not pose any crtitical security issue. However, this issue was fixed in isar-cip-core v1.9 **CIP firmware analysis issue** BV firmware analysis of CIP image found following issue. ``The reviewed CIP-provided reference firmware image (version 1.7) demonstrates a generally sound security posture with no immediate credential or privilege management concerns identified. The firmware stores the root account password in a SHA-512 hashed format, and no evidence of empty, weak, or plaintext credentials was observed. Entropy analysis further shows that encryption or compression is applied selectively to specific firmware regions, while large portions remain accessible in plaintext, suggesting partial rather than full firmware protection`` ``The firmware contains a hashed root password using SHA-512, but no evidence of empty, weak, or plaintext credentials was identified.`` ``A review of the /etc/group configuration identified only standard Linux system and service groups. No users were assigned to privileged groups such as root, sudo, disk, or shadow. The sudo group contains no members. No misconfigurations or privilege escalation risks were identified.`` ``Entropy analysis indicates that only specific regions of the firmware exhibit high entropy consistent with encryption or compression, while substantial portions remain low-entropy and accessible in plaintext. This suggests selective protection rather than full firmware encryption`` **BV Recommendation** ``As the DUT operates as a reference image, the following recommendations are directed at product implementers and OEMs. The test lab recommends that all production firmware be encrypted to protect confidentiality and intellectual property, for example by using AES-256 encryption and GCM mode with device-unique encryption keys generated during the manufacturing process.`` ``In addition, all reference-platform cryptographic materials should be replaced with production-grade credentials, and a unique SHA-512 (or stronger) root hash should be generated for each production firmware build.`` **CIP developers analysis** Analysis of this issue is currently in progress, once it's completed, this section will be updated. 2.4 SVV-4 report summary ~~~~~~~~~~~~~~~~~~~~~~~~~ As the DUT operates as a reference image, the following recommendations are directed at product implementers and OEMs. The test lab recommends that all production firmware be encrypted to protect confidentiality and intellectual property, for example by using AES-256 encryption and GCM mode with device-unique encryption keys generated during the manufacturing process. In addition, all reference-platform cryptographic materials should be replaced with production-grade credentials, and a unique SHA-512 (or stronger) root hash should be generated for each production firmware build. There were no significant findings as a result of this assessment. Of the identified findings, it is recommended that updating to the latest version to prevent future exploitation. 3. Guidelines for CIP users ---------------------------- **TBD** 4. TODOs -------- This section would be updated based on further updates on investigation or any response from BV 5. References ------------- **TBD**