CVE-2017-1000375

Imagine a computer’s memory like a book’s pages: the attacker is trying to slide a “forbidden tool” onto the page directly next to where it matters most (the stack). This NetBSD setup places key runtime code (ld.so) right next to that area, so the attacker has a shorter, easier path to corrupt memory. In the worst case, that can mean the attacker gets the ability to run their own code on your server.

This matters to you if you run NetBSD 7.1 (and possibly older versions) on any server that could be reached by an attacker. Because the weakness is about memory manipulation, the main risk is exposure of the host to untrusted traffic or attacker-controlled inputs. Treat it as a risk when the system is reachable from the internet (or other untrusted networks) and attackers can reach the vulnerable execution path.

Even though this specific issue is not confirmed in the CISA KEV list, there is public exploit code available. That means real attackers can potentially use it without inventing new techniques. Act with priority (amber): patch or apply the recommended remediation as soon as practical, especially for externally reachable NetBSD 7.1 systems.

For technical readers:

1. Confirm exposure

• Identify the OS version on the affected host(s). The findings state NetBSD 7.1 is affected and possibly earlier versions.
• Confirm whether the host is exposed to untrusted networks (internet-facing services, remote admin access, or any pathways an external attacker can interact with).

2. Apply remediation

• Apply the vendor remediation guidance referenced in the findings: https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt
• Follow the specific configuration and mitigation steps described in that guidance for your environment.
• If there are multiple remediation options in the guidance, implement all applicable ones (and document the exact changes).

3. Validate

• After remediation, re-check system configuration to ensure the mitigation is effectively in place per the guidance.
• Re-test any affected services/launch workflows to ensure nothing breaks.

4. Temporary workaround (if immediate remediation isn’t possible)

• Reduce exposure immediately by restricting network access to only required sources/ports (firewalling, VPN-only admin, and removing unnecessary internet reachability).
• Monitor for suspicious authentication attempts or abnormal service behavior while mitigation is pending.

5. Ongoing monitoring

• Track NetBSD security advisories for follow-up fixes and any version-specific updates.
• Watch for alerts indicating unexpected process behavior consistent with memory corruption/compromise attempts.

CISA KEV note

• This CVE is not listed in CISA KEV per the findings, so exploitation-in-the-wild is not confirmed there.

Severity context: The reported risk is very high (CVSS indicates critical impact potential), and the weakness class is CWE-119 (improper resource control / memory-related issue enabling exploitation).

Mechanism and attack surface: The findings describe that NetBSD maps the runtime link-editor (ld.so) directly below the stack region even when ASLR is enabled. This undermines the intended randomization benefit by making memory layout more predictable/easier to manipulate, which can enable memory corruption leading to arbitrary code execution.

Exploitation status: A public exploit is available (1 known). CISA KEV listing is not present for this CVE per the findings.

Patch/mitigation availability: The findings provide vendor remediation guidance via a Qualys “stack-clash.txt” reference rather than a specific fixed NetBSD version.

EPSS: A predicted likelihood is provided in the findings, but because the findings do not state KEV/news-confirmed exploitation, it should not be treated as proof of active exploitation.