Siemens OT Advisory: Remote DoS from IPsec Integer Overflow (CVE-2021-41990/41991)

Siemens ProductCERT and CISA republished an advisory detailing remote integer‑overflow vulnerabilities that affect a broad set of Siemens networking and communication modules — SIMATIC NET CP, SINEMA Remote Connect Server, and many SCALANCE and RUGGEDCOM devices — and operators must treat the bulletin as an urgent operational-security matter while following vendor patch guidance and layered mitigations.

Background / Overview​

Siemens’ ProductCERT advisory (SSA‑539476) — republished through CISA’s ICS advisory channel — identifies integer overflow / wraparound defects in the IPsec/strongSwan‑based components used across multiple Siemens embedded network modules and remote‑access products. The advisory assigns two CVE identifiers, CVE‑2021‑41990 and CVE‑2021‑41991, each carrying a CVSS v3.1 base score of 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H), which reflects remote exploitability with low attack complexity and an availability impact.
The affected product scope is extensive and global: it includes many models from the SCALANCE M-800 family, the RUGGEDCOM RM1224 LTE variants, SIMATIC CP interface modules (CP 1242‑7 V2, CP 1243‑1, CP 1542SP‑1 and others), and the SINEMA Remote Connect Server, among numerous SIPLUS and SCALANCE variants. The advisory enumerates firmware thresholds: for many SCALANCE/RUGGEDCOM models the fix is delivered as V7.1 or later, while SIMATIC CP/SIPLUS CP families reference version thresholds such as V3.3.46, V2.2.28, V3.0.22, or V1.1 depending on the model. Operators must map installed firmware to the per‑model remediation table in the vendor advisory.
Two key technical notes in the advisory deserve immediate emphasis:

• One integer overflow is rooted in the gmp plugin in strongSwan (versions prior to 5.9.4) and can be triggered via a crafted certificate with an RSASSA‑PSS signature; the reported impact is denial‑of‑service — not arbitrary code execution.
• A second integer‑overflow affects the in‑memory certificate cache used by strongSwan: by flooding the cache with many different certificates an attacker can trigger overflow/wraparound during cache replacement, leading to service disruption and potentially memory misuse that might — under very specific and unlikely conditions — be weaponized further.

CISA’s public posting repeats Siemens’ recommendation that ProductCERT is the canonical source for ongoing updates; CISA will not maintain continuous updates for Siemens products beyond initial advisories. That operational shift makes direct vendor monitoring essential to maintain timely patching programs.

---

Why this matters: operational impact and threat model​

Remote DoS with low complexity, potential for larger escalation​

The advisory’s CVSS vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) indicates remote network attack with no privileges or user interaction required and a primary impact on availability (DoS). For industrial and critical‑manufacturing environments where SCALANCE or SIMATIC networking modules act as gateways, firewalls, or remote‑connect endpoints, a remote DoS can interrupt telemetry, impair command and control, and force manual interventions — outcomes that translate directly into safety and production risk.
While Siemens and the advisory authors state remote code execution is not expected for the gmp plugin bug and very unlikely for the cache bug absent memory control, those are engineering assessments that hinge on exploitation primitives and target memory layouts. Operators should treat DoS as the primary risk while remaining aware that proof‑of‑concept evolution or toolchain advances can change feasibility over time. The advisory explicitly states remote code execution "cannot be excluded completely" for the cache issue, albeit unlikely.

Breadth of affected devices multiplies operational friction​

Affected devices are frequently deployed at the OT perimeter — cellular routers, M‑800 series edge routers, remote access servers, and CP‑class protocol processors in production cabinets. These devices are often:

• Distributed in remote sites (making hands‑on patching slow),
• Managed by separate OT teams with long maintenance windows,
• Interconnected with vendor‑managed services or third‑party remote access.

That distribution and operational constraint increase the cost and complexity of patching campaigns and favor careful, staged deployment and compensating controls for devices that cannot be taken offline quickly.

---

Technical analysis: what the bugs are and how they get triggered​

Integer overflow in gmp plugin (certificate processing)​

• Root cause: improper arithmetic checks when processing certain RSA‑PSS signature parameters from certificates processed by the gmp plugin in strongSwan.
• Attack vector: a remote initiator can present a crafted certificate (for example, a self‑signed CA certificate) during the IPsec handshake. This malformed input causes integer wraparound that is handled poorly by the code path, ultimately resulting in a crash or service termination.
• Impact profile: Denial‑of‑Service (process or service crash). The advisory indicates remote code execution is not possible from this specific bug, based on the attack surface and code paths observed.

Certificate‑cache replacement bug (random selection flaw)​

• Root cause: the in‑memory certificate cache uses a randomization/selection algorithm intended to pick less‑used entries for replacement, but the rand/selection code incorrectly handles counters and indices — leading to integer overflow/wraparound when many unique certificates are inserted.
• Attack vector: a remote actor repeatedly initiates connections using varied certificates to exhaust the cache, then send additional requests that trigger replacement logic paths. Due to wraparound, the point of selection can move into an invalid state that causes memory corruption or service termination.
• Impact profile: Denial‑of‑Service, with remote code execution considered very unlikely unless an attacker can also control the memory contents at dereference time — a higher bar in embedded, well‑segmented OT environments.

Practical exploitability considerations​

• Network reachability is required: attackers must be able to reach the vulnerable IPsec/remote‑access interface. Devices directly exposed to the internet or lightly segmented DMZs are highest risk.
• Attack sophistication: the certificate flood/replacement attack requires automation and volume; the gmp crafted‑certificate exploit is lower complexity but limited to DoS.
• Evidence gap: as of the advisory republication, no public exploitation specifically targeting these CVEs was reported; operators should treat that status as time‑sensitive intelligence rather than a guarantee of safety.

---

Affected product families and the vendor fixes (practical summary)​

Siemens provides a per‑model mapping of affected products and fixed firmware/software thresholds. The advisory lists dozens of SKUs across SCALANCE, RUGGEDCOM, SIMATIC CP families, and SIPLUS variants. Representative guidance includes:

• SCALANCE M‑series and many M‑800 family devices: update to V7.1 or later.
• SIMATIC CP 1242‑7 V2 / CP 1243‑1 / CP 1243‑7 / CP 1542SP‑1 variants: firmware thresholds such as V3.3.46 or V2.2.28 or V1.1 for affected SKUs — follow per‑SKU recommendations in the advisory.
• SINEMA Remote Connect Server: update to V3.1 or later for the CVE‑2021‑41991 fix when applicable.
• SCALANCE SC6xx series (SC622‑2C, SC632‑2C, SC636‑2C, SC642‑2C, SC646‑2C): update to V2.3 or later where indicated.

Operators must consult the full vendor advisory to match their exact part numbers and firmware revisions; the advisory lists specific part numbers (for example, 6GK5874‑3AA00‑2AA2 and many others) and exact version thresholds. Inventory mapping is the first step in any remediation plan.

---

Mitigations and recommended control stack​

Siemens and the advisory include specific updates and general mitigations. Operators should treat remediation as a multi‑track program: immediate tactical mitigations, prioritized patching, and longer‑term resilience measures.

Immediate tactical mitigations (apply now)​

• Minimize network exposure: ensure no vulnerable control system devices are directly reachable from the internet; enforce strict firewall rules at network edges and DMZs.
• Segmentation: place vulnerable devices behind dedicated OT firewalls and isolate them from business networks and unmanaged endpoints. Use allow‑lists for management traffic.
• Restrict IPsec peer endpoints and certificate sources: limit which external IPs and certificate authorities are allowed to establish tunnels with infrastructure devices; when possible, whitelist only known peers.
• For SIMATIC CP family items where the advisory recommends certificate deployment via the TIA Portal produced certificates only — follow that constraint (i.e., only deploy certificates that were created with TIA Portal) until updated firmware is deployed.

Prioritized patching (next 30–90 days)​

• Inventory all devices that match the advisory’s SKUs and record current firmware levels.
• For devices with vendor‑provided fixes (per the advisory table), schedule staged updates to the recommended firmware versions (for example, V7.1 for many SCALANCE M‑series models, or the model‑specific CP/SIPLUS firmware).
• Test vendor firmware in a lab or representative staging environment prior to broad rollout — verify functional compatibility with management systems and any integrated OT applications.

Compensating controls where patching is delayed or impossible​

• Apply strict ingress/egress ACLs to management ports (block IPsec initiation from untrusted sources).
• Use VPNs with mutual authentication and tightly controlled gateway access (recognize VPNs must themselves be kept current).
• Deploy network intrusion detection tuned for anomalous certificate‑flooding behavior (numerous unique certificates or repeated IPsec handshakes) and create automated alerting for suspicious patterns that could indicate cache exhaustion attacks.

Detection and monitoring​

• Watch for unusual spikes in certificate exchanges or repeated failed/aborted IPsec handshakes that correlate with device instability.
• Monitor device availability and process logs for repeated restarts/daemon crashes of IPsec components.
• Centralize logs and apply correlation rules that surface certificate flood patterns originating from specific source IPs over short windows.

---

Operational playbook: prioritized steps for SOC/OT teams​

• Immediately identify in‑scope devices by matching installed inventory against the vendor advisory part numbers and firmware thresholds.
• If any vulnerable device is reachable from untrusted networks, put an emergency rule in place to block or restrict that reachability (firewall, VPN gateway controls).
• Schedule a test upgrade for the most exposed site/device and validate functional interoperability with management consoles and remote‑access workflows.
• For devices that cannot be patched immediately, deploy compensating access controls and create heightened monitoring for certificate anomalies and availability issues.
• After patch deployment, validate via functional tests (connectivity, IPsec tunnel stability, throughput) and monitor for any regressions for at least one maintenance cycle.

---

Strengths, vendor response quality, and remaining risks — critical analysis​

Notable strengths​

• Siemens published a detailed, SKU‑level advisory listing exact part numbers and recommended firmware thresholds, enabling direct inventory matching and targeted patching. That level of granularity is operationally useful for large estates.
• The advisory is explicit about attack classes (integer overflow / wraparound) and quantifies expected impact (DoS) while being transparent about remote code execution likelihood — this helps operators make evidence‑based risk decisions.

Practical and policy weaknesses / risks​

• The affected components are widely distributed across the OT perimeter and are often difficult to patch quickly due to remote site logistics, long maintenance windows, or vendor‑managed devices. That operational reality means many installations will be running vulnerable versions for some time.
• CISA’s operational posture — not continuously updating Siemens advisories beyond initial notifications since January 10, 2023 — places the onus on operators to monitor Siemens ProductCERT directly for follow‑ups. That increases the risk that estates relying solely on third‑party trackers or aggregated feeds will miss vendor follow‑up patches.
• The advisory’s assessment that RCE is unlikely should be treated with cautious optimism: as proof‑of‑concept techniques evolve, exploitation paths that initially only yielded DoS can sometimes be chained into memory corruption primitives with higher impacts. The advisory itself flags that RCE cannot be completely excluded for the cache issue.

Verification and cross‑checks​

• The technical descriptions (strongSwan 5.9.4 gmp plugin fix and certificate cache behavior) are consistent across the advisory text and published CVE records embedded in the advisory dataset. Operators should still cross‑check product‑specific CVE entries when planning remediation to confirm the vendor‑assigned fixed versions for each SKU.

---

Long‑term resilience and governance recommendations​

• Maintain an authoritative, constantly‑updated inventory of fielded devices (part numbers, firmware versions, management endpoints) that is queryable for advisories and CVE matching. A reliable inventory is the single most effective enabler of targeted patching.
• Adopt a vendor‑monitoring process that subscribes to ProductCERT/SSA feeds for vendors supplying critical OT infrastructure instead of relying only on centralized government advisories which may not be maintained continuously.
• Harden the OT perimeter with robust segmentation, deny‑by‑default firewall policies, and strong authentication for remote access. Where possible, require device‑to‑device mutual authentication and strict certificate vetting workflows.
• Build a test and rollback plan for firmware updates in OT: vendor firmware occasionally changes behavior; a validated roll‑back option reduces pressure on patch windows and improves operational confidence during rollouts.
• Integrate anomaly detection that monitors certificate churn and IPsec handshake volumes, and craft playbooks that automate containment for certificate‑flood style events.

---

Unverifiable or time‑sensitive claims — cautionary notes​

• The advisory states no known public exploitation has been reported at the time of republication; this is a snapshot of telemetry and reporting status and can change rapidly if exploit code or campaign activity emerges. Treat that statement as time‑sensitive intelligence rather than permanent assurance.
• Statements about the absolute impossibility of remote code execution for these specific bugs are engineering assessments; while the vendor’s analysis is authoritative, absolute impossibility cannot be proven in the general case, and operators should continue to monitor for exploit reports and prioritize mitigations accordingly.

---

Conclusion — a practical risk posture​

This advisory is important because it affects everyday OT network infrastructure — the routers, access servers, and CP interface modules that sit at the interface between plant assets and remote management. The primary impact is availability (DoS) from integer overflow / wraparound conditions in certificate processing code, and Siemens provides model‑specific firmware updates for many affected SKUs. Operators should act decisively:

• inventory affected devices,
• apply network access controls to limit exposure,
• prioritize vendor firmware updates in test and production windows,
• and deploy compensating monitoring and containment measures where immediate patching is impractical.

Because CISA now routes continuous updates to Siemens’ ProductCERT and the vendor’s SSA pages, direct vendor monitoring is required to stay current with additional fixes, mitigations, or revised impact assessments.Immediate next steps checklist (actionable)

• Match inventory to the advisory’s SKU list and record current firmware levels.
• Block or restrict external access to vulnerable IPsec/remote‑access endpoints until patched.
• Test vendor firmware in a staging environment and deploy patches per your change management process.
• Put compensating controls in place for unpatchable devices: ACLs, segmentation, certificate whitelisting, and anomaly alerts.
• Subscribe to Siemens ProductCERT/SSA feeds and add them to your vendor‑monitoring pipeline for future updates.

Operators who follow this sequence will reduce immediate exposure and build the institutional processes necessary to manage similar advisories across the OT estate in the future.

---

Source: CISA Siemens SIMATIC NET CP, SINEMA, and SCALANCE | CISA