CVE Vulnerabilities

CVE-2017-0166

Incorrect Calculation of Buffer Size

Published: Apr 12, 2017 | Modified: Oct 03, 2019
CVSS 3.x
8.1
HIGH
Source:
NVD
CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS 2.x
9.3 HIGH
AV:N/AC:M/Au:N/C:C/I:C/A:C
RedHat/V2
RedHat/V3
Ubuntu

An elevation of privilege vulnerability exists in Windows when LDAP request buffer lengths are improperly calculated. In a remote attack scenario, an attacker could exploit this vulnerability by running a specially crafted application to send malicious traffic to a Domain Controller, aka LDAP Elevation of Privilege Vulnerability.

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

Name Vendor Start Version End Version
Windows_server_2012 Microsoft r2 r2
Windows_server_2016 Microsoft * *
Windows_7 Microsoft - -
Windows_10 Microsoft 1511 1511
Windows_10 Microsoft 1607 1607
Windows_8.1 Microsoft * *
Windows_server_2008 Microsoft r2 r2
Windows_rt_8.1 Microsoft - -
Windows_7 Microsoft - -
Windows_vista Microsoft - -
Windows_server_2012 Microsoft * *
Windows_10 Microsoft * *
Windows_server_2008 Microsoft * *
Windows_10 Microsoft 1703 1703

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.

References