English
Français
Light
Dark
System

CVEFind - Alertes CVE

Restez informé en continue
Créer un compte Ouvrez un compte Simple et Gratuit Se connecter Gérez vos alertes

CVE-2016-1583 : Détail

CVE-2016-1583

7.8
/
HIGH
Overflow
0.05%V3
Local
2016-06-27 08:00 +00:00
2018-12-06 20:57 +00:00
CVE.org
NVD

Alerte pour un CVE

Restez informé de toutes modifications pour un CVE spécifique.
Gestion des alertes

Descriptions

The ecryptfs_privileged_open function in fs/ecryptfs/kthread.c in the Linux kernel before 4.6.3 allows local users to gain privileges or cause a denial of service (stack memory consumption) via vectors involving crafted mmap calls for /proc pathnames, leading to recursive pagefault handling.

Informations

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 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

The vulnerable component is not bound to the network stack and the attacker’s path is via read/write/execute capabilities.

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 when attacking the vulnerable component.

Privileges Required

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

Low

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 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.

High

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 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 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 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.

 [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.
EPSS First.org

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 12.0

Novell>>Suse_linux_enterprise_software_development_kit >> Version 12.0

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

        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

        http://www.ubuntu.com/usn/USN-3006-1
        Tags : vendor-advisory, x_refsource_UBUNTU
        http://www.ubuntu.com/usn/USN-3004-1
        Tags : vendor-advisory, x_refsource_UBUNTU
        http://rhn.redhat.com/errata/RHSA-2016-2766.html
        Tags : vendor-advisory, x_refsource_REDHAT
        http://www.ubuntu.com/usn/USN-3001-1
        Tags : vendor-advisory, x_refsource_UBUNTU
        https://www.exploit-db.com/exploits/39992/
        Tags : exploit, x_refsource_EXPLOIT-DB
        http://www.ubuntu.com/usn/USN-3005-1
        Tags : vendor-advisory, x_refsource_UBUNTU
        http://www.securityfocus.com/bid/91157
        Tags : vdb-entry, x_refsource_BID
        http://www.ubuntu.com/usn/USN-2999-1
        Tags : vendor-advisory, x_refsource_UBUNTU
        http://www.openwall.com/lists/oss-security/2016/06/10/8
        Tags : mailing-list, x_refsource_MLIST
        http://www.ubuntu.com/usn/USN-2997-1
        Tags : vendor-advisory, x_refsource_UBUNTU
        http://www.ubuntu.com/usn/USN-3000-1
        Tags : vendor-advisory, x_refsource_UBUNTU
        http://www.debian.org/security/2016/dsa-3607
        Tags : vendor-advisory, x_refsource_DEBIAN
        http://www.securitytracker.com/id/1036763
        Tags : vdb-entry, x_refsource_SECTRACK
        http://www.ubuntu.com/usn/USN-3002-1
        Tags : vendor-advisory, x_refsource_UBUNTU
        http://www.ubuntu.com/usn/USN-2996-1
        Tags : vendor-advisory, x_refsource_UBUNTU
        https://access.redhat.com/errata/RHSA-2017:2760
        Tags : vendor-advisory, x_refsource_REDHAT
        http://www.ubuntu.com/usn/USN-3007-1
        Tags : vendor-advisory, x_refsource_UBUNTU
        http://rhn.redhat.com/errata/RHSA-2016-2124.html
        Tags : vendor-advisory, x_refsource_REDHAT
        http://www.ubuntu.com/usn/USN-3003-1
        Tags : vendor-advisory, x_refsource_UBUNTU
        http://www.openwall.com/lists/oss-security/2016/06/22/1
        Tags : mailing-list, x_refsource_MLIST
        http://www.ubuntu.com/usn/USN-2998-1
        Tags : vendor-advisory, x_refsource_UBUNTU
        http://www.ubuntu.com/usn/USN-3008-1
        Tags : vendor-advisory, x_refsource_UBUNTU

        Plus d'informations
        Cliquez sur le bouton à gauche (OFF), pour autoriser l'inscription de cookie améliorant les fonctionnalités du site. Cliquez sur le bouton à gauche (Tout accepter), pour ne plus autoriser l'inscription de cookie améliorant les fonctionnalités du site.