CPE, qui signifie Common Platform Enumeration, est un système normalisé de dénomination du matériel, des logiciels et des systèmes d'exploitation. CPE fournit un schéma de dénomination structuré pour identifier et classer de manière unique les systèmes informatiques, les plates-formes et les progiciels sur la base de certains attributs tels que le fournisseur, le nom du produit, la version, la mise à jour, l'édition et la langue.
CWE, ou Common Weakness Enumeration, est une liste complète et une catégorisation des faiblesses et des vulnérabilités des logiciels. Elle sert de langage commun pour décrire les faiblesses de sécurité des logiciels au niveau de l'architecture, de la conception, du code ou de la mise en œuvre, qui peuvent entraîner des vulnérabilités.
CAPEC, qui signifie Common Attack Pattern Enumeration and Classification (énumération et classification des schémas d'attaque communs), est une ressource complète, accessible au public, qui documente les schémas d'attaque communs utilisés par les adversaires dans les cyberattaques. Cette base de connaissances vise à comprendre et à articuler les vulnérabilités communes et les méthodes utilisées par les attaquants pour les exploiter.
Services & Prix
Aides & Infos
Recherche de CVE id, CWE id, CAPEC id, vendeur ou mots clés dans les CVE
The arch_pick_mmap_layout function in arch/x86/mm/mmap.c in the Linux kernel through 4.5.2 does not properly randomize the legacy base address, which makes it easier for local users to defeat the intended restrictions on the ADDR_NO_RANDOMIZE flag, and bypass the ASLR protection mechanism for a setuid or setgid program, by disabling stack-consumption resource limits.
Category : 7PK - Security Features Software security is not security software. Here we're concerned with topics like authentication, access control, confidentiality, cryptography, and privilege management.
Métriques
Métriques
Score
Gravité
CVSS Vecteur
Source
V3.0
7.8
HIGH
CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
More informations
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.
Local
A vulnerability exploitable with Local access means that the vulnerable component is not bound to the network stack, and the attacker's path is via read/write/execute capabilities. In some cases, the attacker may be logged in locally in order to exploit the vulnerability, otherwise, she may rely on User Interaction to execute a malicious file.
Attack Complexity
This metric describes the conditions beyond the attacker's control that must exist in order to exploit the vulnerability.
Low
Specialized access conditions or extenuating circumstances do not exist. An attacker can expect repeatable success against the vulnerable component.
Privileges Required
This metric describes the level of privileges an attacker must possess before successfully exploiting the vulnerability.
Low
The attacker is authorized with (i.e. requires) privileges that provide basic user capabilities that could normally affect only settings and files owned by a user. Alternatively, an attacker with Low privileges may have the ability to cause an impact only to non-sensitive resources.
User Interaction
This metric captures the requirement for a 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
An important property captured by CVSS v3.0 is the ability for a vulnerability in one software component to impact resources beyond its means, or privileges.
Scope
Formally, Scope refers to the collection of privileges defined by a computing authority (e.g. an application, an operating system, or a sandbox environment) when granting access to computing resources (e.g. files, CPU, memory, etc). These privileges are assigned based on some method of identification and authorization. In some cases, the authorization may be simple or loosely controlled based upon predefined rules or standards. For example, in the case of Ethernet traffic sent to a network switch, the switch accepts traffic that arrives on its ports and is an authority that controls the traffic flow to other switch ports.
Unchanged
An exploited vulnerability can only affect resources managed by the same authority. In this case the vulnerable component and the impacted component are the same.
Base: Impact Metrics
The Impact metrics refer to the properties of the impacted component.
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.
High
There is total loss of confidentiality, resulting in all resources within the impacted component being divulged to the attacker. Alternatively, access to only some restricted information is obtained, but the disclosed information presents a direct, serious impact. For example, an attacker steals the administrator's password, or private encryption keys of a web server.
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.
High
There is total loss of availability, resulting in the attacker being able to fully deny access to resources in the impacted component; this loss is either sustained (while the attacker continues to deliver the attack) or persistent (the condition persists even after the attack has completed). Alternatively, the attacker has the ability to deny some availability, but the loss of availability presents a direct, serious consequence to the impacted component (e.g., the attacker cannot disrupt existing connections, but can prevent new connections; the attacker can repeatedly exploit a vulnerability that, in each instance of a successful attack, leaks a only small amount of memory, but after repeated exploitation causes a service to become completely unavailable).
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 that one has in the description of a vulnerability.
Environmental Metrics
nvd@nist.gov
V2
4.6
AV:L/AC:L/Au:N/C:P/I:P/A:P
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.
Date
EPSS V0
EPSS V1
EPSS V2 (> 2022-02-04)
EPSS V3 (> 2025-03-07)
EPSS V4 (> 2025-03-17)
2022-02-06
–
–
3.53%
–
–
2022-02-13
–
–
3.53%
–
–
2022-04-03
–
–
3.53%
–
–
2022-05-15
–
–
3.53%
–
–
2022-12-18
–
–
3.53%
–
–
2023-01-01
–
–
3.53%
–
–
2023-02-05
–
–
3.53%
–
–
2023-02-19
–
–
3.53%
–
–
2023-02-26
–
–
3.53%
–
–
2023-03-12
–
–
–
0.04%
–
2024-06-02
–
–
–
0.04%
–
2025-01-19
–
–
–
0.04%
–
2025-03-18
–
–
–
–
0.02%
2025-03-18
–
–
–
–
0.02,%
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.
Date de publication : 2016-04-05 22h00 +00:00 Auteur : Hector Marco & Ismael Ripoll EDB Vérifié : No
Source: http://hmarco.org/bugs/CVE-2016-3672-Unlimiting-the-stack-not-longer-disables-ASLR.html
CVE-2016-3672 - Unlimiting the stack not longer disables ASLR
Authors: Hector Marco & Ismael Ripoll
CVE: CVE-2016-3672
Dates: April 2016
Description
We have fixed an old and very known weakness in the Linux ASLR implementation.
Any user able to running 32-bit applications in a x86 machine can disable the ASLR by setting the RLIMIT_STACK resource to unlimited.
Following are the steps to test whether your system is vulnerable or not:
1) Create a dummy program which shows its memory map:
#include <stdio.h>
int main(int argc, const char *argv[])
{
char cmd[256];
sprintf(cmd, "cat /proc/%d/maps", getpid());
system(cmd);
return 0;
}
2) Compile it:
$ gcc show_maps.c -o show_maps # In a i386 machine
$ gcc show_maps.c -o show_maps -m32 # In a 64-bit machine
3) Run the application to check that ASLR is working
$ for i in `seq 1 10`; do ./show_maps | grep "r-xp.*libc"; done
f75c4000-f7769000 r-xp 00000000 08:01 784726 /lib32/libc-2.19.so
f75db000-f7780000 r-xp 00000000 08:01 784726 /lib32/libc-2.19.so
f7557000-f76fc000 r-xp 00000000 08:01 784726 /lib32/libc-2.19.so
f7595000-f773a000 r-xp 00000000 08:01 784726 /lib32/libc-2.19.so
f7574000-f7719000 r-xp 00000000 08:01 784726 /lib32/libc-2.19.so
f75af000-f7754000 r-xp 00000000 08:01 784726 /lib32/libc-2.19.so
f7530000-f76d5000 r-xp 00000000 08:01 784726 /lib32/libc-2.19.so
f7529000-f76ce000 r-xp 00000000 08:01 784726 /lib32/libc-2.19.so
f75c2000-f7767000 r-xp 00000000 08:01 784726 /lib32/libc-2.19.so
f75fe000-f77a3000 r-xp 00000000 08:01 784726 /lib32/libc-2.19.so
The libc-2.19.so library is mapped at random positions, so, the ASLR is working properly.
Now, we run the same test but setting the stack to unlimited:
$ ulimit -a | grep stack
stack size (kbytes, -s) 8192
$ ulimit -s unlimited
stack size (kbytes, -s) unlimited
$ for i in `seq 1 10`; do ./show_maps | grep "r-xp.*libc"; done
5559a000-5573f000 r-xp 00000000 08:01 784726 /lib32/libc-2.19.so
5559a000-5573f000 r-xp 00000000 08:01 784726 /lib32/libc-2.19.so
5559a000-5573f000 r-xp 00000000 08:01 784726 /lib32/libc-2.19.so
5559a000-5573f000 r-xp 00000000 08:01 784726 /lib32/libc-2.19.so
5559a000-5573f000 r-xp 00000000 08:01 784726 /lib32/libc-2.19.so
5559a000-5573f000 r-xp 00000000 08:01 784726 /lib32/libc-2.19.so
5559a000-5573f000 r-xp 00000000 08:01 784726 /lib32/libc-2.19.so
5559a000-5573f000 r-xp 00000000 08:01 784726 /lib32/libc-2.19.so
5559a000-5573f000 r-xp 00000000 08:01 784726 /lib32/libc-2.19.so
5559a000-5573f000 r-xp 00000000 08:01 784726 /lib32/libc-2.19.so
The libc-2.19.so library is mapped at the same position in all executions: the ASLR has been disabled.
This is a very old trick to disable ASLR, but unfortunately it was still present in current Linux systems.
Vulnerable packages
The weakness, IFAIK is present from the first version of current Linux GIT repository. The first version on this resposiroty is Linux-2.6.12-rc2 dated on April 2005.
Impact
An attacker capable of running 32-bit system applications in a x86 machine is able to disable the ASLR of any application, including sensitive applications such as setuid and setgid. Note that it is not a exploitable vulnerability by itself but a trick to disable the ASLR. This weakness can be use by an attacker when trying to exploit some other bug. Since the i386 is still very used, the number of systems and affected users could be extremely huge.
The wekaness
The issue arises because the ASLR Linux implementation does not randomize always the mmap base address when the stack size is set to unlimited. Concretely, on i386 and on X86_64 when emulating X86_32 in legacy mode, only the stack and the executable are randomized but not other mmapped files (libraries, vDSO, etc.). And depending in the Linux version, the executable is neither randomized.
The function to calculate the libraries position when the stack is set to unlimited is mmap_legacy_base():
static unsigned long mmap_legacy_base(void)
{
if (mmap_is_ia32())
return TASK_UNMAPPED_BASE;
else
return TASK_UNMAPPED_BASE + mmap_rnd();
}
The function doesn't add any random offset when the system is running in a native 32-bit system (i386) or a 32-bit emulated system (x86_32).
Exploit
To exploit this weakness, the attacker just need to set to unlimited the stack and then execute a 32-bit application. Obviously the idea is to execute (attack) privileged applications such as setuid/setgid.
FIX
We have created a patch to fix this issue:
diff --git a/arch/x86/mm/mmap.c b/arch/x86/mm/mmap.c
index 96bd1e2..389939f 100644
--- a/arch/x86/mm/mmap.c
+++ b/arch/x86/mm/mmap.c
@@ -94,18 +94,6 @@ static unsigned long mmap_base(unsigned long rnd)
}
/*
- * Bottom-up (legacy) layout on X86_32 did not support randomization, X86_64
- * does, but not when emulating X86_32
- */
-static unsigned long mmap_legacy_base(unsigned long rnd)
-{
- if (mmap_is_ia32())
- return TASK_UNMAPPED_BASE;
- else
- return TASK_UNMAPPED_BASE + rnd;
-}
-
-/*
* This function, called very early during the creation of a new
* process VM image, sets up which VM layout function to use:
*/
@@ -116,7 +104,7 @@ void arch_pick_mmap_layout(struct mm_struct *mm)
if (current->flags & PF_RANDOMIZE)
random_factor = arch_mmap_rnd();
- mm->mmap_legacy_base = mmap_legacy_base(random_factor);
+ mm->mmap_legacy_base = TASK_UNMAPPED_BASE + random_factor;
if (mmap_is_legacy()) {
mm->mmap_base = mm->mmap_legacy_base;
The patch enables randomization for the libraries, vDSO and mmap requests on i386 and in X86_32 in legacy mode. We already sent the patch to Linux mantainers and the issue will be not problem in incomming Linux versions: Enable full randomization on i386 and X86_32
Discussion
Although this vulnerability is not exploitable by itself, the truth is that the ASLR protection mechanism is useless on local attacks for i386 and x86_32 systems when the attackers are able to attack applications that they can lauch.
Hector Marco - http://hmarco.org