CVE Vulnerabilities

CVE-2019-13752

Out-of-bounds Read

Published: Dec 10, 2019 | Modified: Nov 07, 2023
CVSS 3.x
6.5
MEDIUM
Source:
NVD
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N
CVSS 2.x
4.3 MEDIUM
AV:N/AC:M/Au:N/C:P/I:N/A:N
RedHat/V2
RedHat/V3
6.5 MODERATE
CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N
Ubuntu
MEDIUM

Out of bounds read in SQLite in Google Chrome prior to 79.0.3945.79 allowed a remote attacker to obtain potentially sensitive information from process memory via a crafted HTML page.

Weakness

The product reads data past the end, or before the beginning, of the intended buffer.

Affected Software

Name Vendor Start Version End Version
Chrome Google * 79.0.3945.79 (excluding)
Red Hat Enterprise Linux 6 Supplementary RedHat chromium-browser-0:79.0.3945.79-1.el6_10 *
Red Hat Enterprise Linux 8 RedHat sqlite-0:3.26.0-6.el8 *
Red Hat Enterprise Linux 8 RedHat sqlite-0:3.26.0-6.el8 *
Chromium-browser Ubuntu bionic *
Chromium-browser Ubuntu devel *
Chromium-browser Ubuntu disco *
Chromium-browser Ubuntu eoan *
Chromium-browser Ubuntu focal *
Chromium-browser Ubuntu groovy *
Chromium-browser Ubuntu hirsute *
Chromium-browser Ubuntu impish *
Chromium-browser Ubuntu jammy *
Chromium-browser Ubuntu kinetic *
Chromium-browser Ubuntu lunar *
Chromium-browser Ubuntu mantic *
Chromium-browser Ubuntu noble *
Chromium-browser Ubuntu oracular *
Chromium-browser Ubuntu trusty *
Chromium-browser Ubuntu upstream *
Chromium-browser Ubuntu xenial *
Sqlite Ubuntu bionic *
Sqlite Ubuntu disco *
Sqlite Ubuntu eoan *
Sqlite Ubuntu groovy *
Sqlite Ubuntu hirsute *
Sqlite Ubuntu impish *
Sqlite Ubuntu kinetic *
Sqlite Ubuntu trusty *
Sqlite Ubuntu trusty/esm *
Sqlite Ubuntu xenial *
Sqlite3 Ubuntu bionic *
Sqlite3 Ubuntu disco *
Sqlite3 Ubuntu eoan *
Sqlite3 Ubuntu precise/esm *
Sqlite3 Ubuntu trusty *
Sqlite3 Ubuntu trusty/esm *
Sqlite3 Ubuntu xenial *

Potential Mitigations

  • Assume all input is malicious. Use an “accept known good” input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
  • When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, “boat” may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as “red” or “blue.”
  • Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code’s environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
  • To reduce the likelihood of introducing an out-of-bounds read, ensure that you validate and ensure correct calculations for any length argument, buffer size calculation, or offset. Be especially careful of relying on a sentinel (i.e. special character such as NUL) in untrusted inputs.

References