Execution with Unnecessary Privileges

Weave Net is open source software which creates a virtual network that connects Docker containers across multiple hosts and enables their automatic discovery. Weave Net before version 2.8.0 has a vulnerability in which can allow an attacker to take over any host in the cluster. Weave Net is supplied with a manifest that runs pods on every node in a Kubernetes cluster, which are responsible for managing network connections for all other pods in the cluster. This requires a lot of power over the host, and the manifest sets `privileged: true`, which gives it that power. It also set `hostPID: true`, which gave it the ability to access all other processes on the host, and write anywhere in the root filesystem of the host. This setting was not necessary, and is being removed. You are only vulnerable if you have an additional vulnerability (e.g. a bug in Kubernetes) or misconfiguration that allows an attacker to run code inside the Weave Net pod, No such bug is known at the time of release, and there are no known instances of this being exploited. Weave Net 2.8.0 removes the hostPID setting and moves CNI plugin install to an init container. Users who do not update to 2.8.0 can edit the hostPID line in their existing DaemonSet manifest to say false instead of true, arrange some other way to install CNI plugins (e.g. Ansible) and remove those mounts from the DaemonSet manifest.Show less

A local privilege escalation vulnerability in telnetd.real of Juniper Networks Junos OS may allow a locally authenticated shell user to escalate privileges and execute arbitrary commands as root. telnetd.real is shipped with setuid permissions enabled and is owned by the root user, allowing local users to run telnetd.real with root privileges. This issue affects Juniper Networks Junos OS: all versions prior to 15.1R7-S9; 17.3 versions prior to 17.3R3-S11; 17.4 versions prior to 17.4R2-S12, 17.4R3-S3; 18.1 versions prior to 18.1R3-S11; 18.2 versions prior to 18.2R3-S6; 18.3 versions prior to 18.3R2-S4, 18.3R3-S4; 18.4 versions prior to 18.4R2-S7, 18.4R3-S6; 19.1 versions prior to 19.1R2-S2, 19.1R3-S4; 19.2 versions prior to 19.2R1-S6, 19.2R3-S1; 19.3 versions prior to 19.3R3-S1; 19.4 versions prior to 19.4R2-S2, 19.4R3; 20.1 versions prior to 20.1R1-S4, 20.1R2; 20.2 versions prior to 20.2R2.Show less

A sensitive information disclosure vulnerability in delta-export configuration utility (dexp) of Juniper Networks Junos OS may allow a locally authenticated shell user the ability to create and read database files generated by the dexp utility, including password hashes of local users. Since dexp is shipped with setuid permissions enabled and is owned by the root user, this vulnerability may allow a local privileged user the ability to run dexp with root privileges and access sensitive information in the dexp database. This issue affects Juniper Networks Junos OS: 15.1 versions prior to 15.1R7-S8; 15.1X49 versions prior to 15.1X49-D230; 17.3 versions prior to 17.3R3-S9; 17.4 versions prior to 17.4R2-S12, 17.4R3-S3; 18.1 versions prior to 18.1R3-S11; 18.2 versions prior to 18.2R3-S6; 18.2X75 versions prior to 18.2X75-D34; 18.3 versions prior to 18.3R3-S4; 18.4 versions prior to 18.4R2-S7, 18.4R3-S6; 19.1 versions prior to 19.1R1-S6, 19.1R2-S2, 19.1R3-S3; 19.2 versions prior to 19.2R1-S5, 19.2R3-S1; 19.3 versions prior to 19.3R2-S5, 19.3R3-S1; 19.4 versions prior to 19.4R1-S3, 19.4R2-S2, 19.4R3-S1; 20.1 versions prior to 20.1R1-S4, 20.1R2; 20.2 versions prior to 20.2R1-S2, 20.2R2.Show less

A flaw was found in the Linux kernel before 5.9-rc4. Memory corruption can be exploited to gain root privileges from unprivileged processes. The highest threat from this vulnerability is to data confidentiality and integrity.Show less

A vulnerability has been identified in License Management Utility (LMU) (All versions < V2.4). The lmgrd service of the affected application is executed with local SYSTEM privileges on the server while its configuration can be modified by local users. The vulnerability could allow a local authenticated attacker to execute arbitrary commands on the server with local SYSTEM privileges.Show less

Universal Robots controller execute URCaps (zip files containing Java-powered applications) without any permission restrictions and a wide API that presents many primitives that can compromise the overall robot operations as demonstrated in our video. In our PoC we demonstrate how a malicious actor could 'cook' a custom URCap that when deployed by the user (intendedly or unintendedly) compromises the systemShow less

Kata Containers doesn't restrict containers from accessing the guest's root filesystem device. Malicious containers can exploit this to gain code execution on the guest and masquerade as the kata-agent. This issue affects Kata Containers 1.11 versions earlier than 1.11.1; Kata Containers 1.10 versions earlier than 1.10.5; and Kata Containers 1.9 and earlier versions.Show less

Apport reads and writes information on a crashed process to /proc/pid with elevated privileges. Apport then determines which user the crashed process belongs to by reading /proc/pid through get_pid_info() in data/apport. An unprivileged user could exploit this to read information about a privileged running process by exploiting PID recycling. This information could then be used to obtain ASLR offsets for a process with an existing memory corruption vulnerability. The initial fix introduced regressions in the Python Apport library due to a missing argument in Report.add_proc_environ in apport/report.py. It also caused an autopkgtest failure when reading /proc/pid and with Python 2 compatibility by reading /proc maps. The initial and subsequent regression fixes are in 2.20.11-0ubuntu16, 2.20.11-0ubuntu8.6, 2.20.9-0ubuntu7.12, 2.20.1-0ubuntu2.22 and 2.14.1-0ubuntu3.29+esm3.Show less

Unquoted service executable path in DXL Broker in McAfee Data eXchange Layer (DXL) Framework 6.0.0 and earlier allows local users to cause a denial of service and malicious file execution via carefully crafted and named executable files.Show less

In PyInstaller before version 3.6, only on Windows, a local privilege escalation vulnerability is present in this particular case: If a software using PyInstaller in "onefile" mode is launched by a privileged user (at least more than the current one) which have his "TempPath" resolving to a world writable directory. This is the case for example if the software is launched as a service or as a scheduled task using a system account (TempPath will be C:\Windows\Temp). In order to be exploitable the software has to be (re)started after the attacker launch the exploit program, so for a service launched at startup, a service restart is needed (e.g. after a crash or an upgrade).Show less

If an attacker can get a user to open a specially prepared directory tree as a workspace in Visual Studio Code with the CodeQL extension active, arbitrary code of the attacker's choosing may be executed on the user's behalf. This is fixed in version 1.0.1 of the extension. Users should upgrade to this version using Visual Studio Code Marketplace's upgrade mechanism. After upgrading, the codeQL.cli.executablePath setting can only be set in the per-user settings, and not in the per-workspace settings. More information about VS Code settings can be found here.Show less

The virConnectBaselineHypervisorCPU() and virConnectCompareHypervisorCPU() libvirt APIs, 4.x.x before 4.10.1 and 5.x.x before 5.4.1, accept an "emulator" argument to specify the program providing emulation for a domain. Since v1.2.19, libvirt will execute that program to probe the domain's capabilities. Read-only clients could specify an arbitrary path for this argument, causing libvirtd to execute a crafted executable with its own privileges.Show less

The virConnectGetDomainCapabilities() libvirt API, versions 4.x.x before 4.10.1 and 5.x.x before 5.4.1, accepts an "emulatorbin" argument to specify the program providing emulation for a domain. Since v1.2.19, libvirt will execute that program to probe the domain's capabilities. Read-only clients could specify an arbitrary path for this argument, causing libvirtd to execute a crafted executable with its own privileges.Show less

rkt through version 1.30.0 does not isolate processes in containers that are run with `rkt enter`. Processes run with `rkt enter` are not limited by cgroups during stage 2 (the actual environment in which the applications run). Compromised containers could exploit this flaw to access host resources.Show less

rkt through version 1.30.0 does not isolate processes in containers that are run with `rkt enter`. Processes run with `rkt enter` do not have seccomp filtering during stage 2 (the actual environment in which the applications run). Compromised containers could exploit this flaw to access host resources.Show less

rkt through version 1.30.0 does not isolate processes in containers that are run with `rkt enter`. Processes run with `rkt enter` are given all capabilities during stage 2 (the actual environment in which the applications run). Compromised containers could exploit this flaw to access host resources.Show less

It was discovered freeradius up to and including version 3.0.19 does not correctly configure logrotate, allowing a local attacker who already has control of the radiusd user to escalate his privileges to root, by tricking logrotate into writing a radiusd-writable file to a directory normally inaccessible by the radiusd user. NOTE: the upstream software maintainer has stated "there is simply no way for anyone to gain privileges through this alleged issue."Show less