CVE-2019-19282

A vulnerability has been identified in OpenPCS 7 V8.1 (All versions), OpenPCS 7 V8.2 (All versions), OpenPCS 7 V9.0 (All versions < V9.0 Upd3), SIMATIC BATCH V8.1 (All versions), SIMATIC BATCH V8.2 (All versions < V8.2 Upd12), SIMATIC BATCH V9.0 (All versions < V9.0 SP1 Upd5), SIMATIC NET PC Software V14 (All versions < V14 SP1 Update 14), SIMATIC NET PC Software V15 (All versions), SIMATIC NET PC Software V16 (All versions < V16 Update 1), SIMATIC PCS 7 V8.1 (All versions), SIMATIC PCS 7 V8.2 (All versions), SIMATIC PCS 7 V9.0 (All versions < V9.0 SP3), SIMATIC Route Control V8.1 (All versions), SIMATIC Route Control V8.2 (All versions), SIMATIC Route Control V9.0 (All versions < V9.0 Upd4), SIMATIC WinCC (TIA Portal) V13 (All versions < V13 SP2), SIMATIC WinCC (TIA Portal) V14 (All versions < V14 SP1 Update 10), SIMATIC WinCC (TIA Portal) V15.1 (All versions < V15.1 Update 5), SIMATIC WinCC (TIA Portal) V16 (All versions < V16 Update 1), SIMATIC WinCC V7.3 (All versions), SIMATIC WinCC V7.4 (All versions < V7.4 SP1 Update 14), SIMATIC WinCC V7.5 (All versions < V7.5 SP1 Update 1). Through specially crafted messages, when encrypted communication is enabled, an attacker with network access could use the vulnerability to compromise the availability of the system by causing a Denial-of-Service condition. Successful exploitation requires no system privileges and no user interaction.

Weakness

The product does not correctly calculate the size to be used when allocating a buffer, which could lead to a buffer overflow.

Affected Software

Potential Mitigations

• Understand the programming language’s underlying representation and how it interacts with numeric calculation (CWE-681). Pay close attention to byte size discrepancies, precision, signed/unsigned distinctions, truncation, conversion and casting between types, “not-a-number” calculations, and how the language handles numbers that are too large or too small for its underlying representation. [REF-7]
• Also be careful to account for 32-bit, 64-bit, and other potential differences that may affect the numeric representation.
• Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
• Use libraries or frameworks that make it easier to handle numbers without unexpected consequences, or buffer allocation routines that automatically track buffer size.
• Examples include safe integer handling packages such as SafeInt (C++) or IntegerLib (C or C++). [REF-106]
• Use automatic buffer overflow detection mechanisms that are offered by certain compilers or compiler extensions. Examples include: the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice, which provide various mechanisms including canary-based detection and range/index checking.
• D3-SFCV (Stack Frame Canary Validation) from D3FEND [REF-1334] discusses canary-based detection in detail.
• Run or compile the software using features or extensions that randomly arrange the positions of a program’s executable and libraries in memory. Because this makes the addresses unpredictable, it can prevent an attacker from reliably jumping to exploitable code.
• Examples include Address Space Layout Randomization (ASLR) [REF-58] [REF-60] and Position-Independent Executables (PIE) [REF-64]. Imported modules may be similarly realigned if their default memory addresses conflict with other modules, in a process known as “rebasing” (for Windows) and “prelinking” (for Linux) [REF-1332] using randomly generated addresses. ASLR for libraries cannot be used in conjunction with prelink since it would require relocating the libraries at run-time, defeating the whole purpose of prelinking.
• For more information on these techniques see D3-SAOR (Segment Address Offset Randomization) from D3FEND [REF-1335].
• Use a CPU and operating system that offers Data Execution Protection (using hardware NX or XD bits) or the equivalent techniques that simulate this feature in software, such as PaX [REF-60] [REF-61]. These techniques ensure that any instruction executed is exclusively at a memory address that is part of the code segment.
• For more information on these techniques see D3-PSEP (Process Segment Execution Prevention) from D3FEND [REF-1336].
• Run the code in a “jail” or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software.
• OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations.
• This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise.
• Be careful to avoid CWE-243 and other weaknesses related to jails.

Related Attack Patterns

• https://cwe.mitre.org/data/definitions/100.html
• https://cwe.mitre.org/data/definitions/47.html

References

• https://cert-portal.siemens.com/productcert/pdf/ssa-270778.pdf