Improper Link Resolution Before File Access ('Link Following')

In Cylance CylancePROTECT before 1470, an unprivileged local user can obtain SYSTEM privileges because users have Modify access to the %PROGRAMFILES%\Cylance\Desktop\log folder, the CyUpdate process grants users Modify access to new files created in this folder, and a new file can be a symlink chain to a pathname of an arbitrary DLL that CyUpdate uses.Show less

The fedora-business-cards package before 1-0.1.beta1.fc17 on Fedora 17 and before 1-0.1.beta1.fc18 on Fedora 18 allows local users to cause a denial of service or write to arbitrary files via a symlink attack on /tmp/fedora-business-cards-buffer.svg.Show less

Qemu before version 2.9 is vulnerable to an improper link following when built with the VirtFS. A privileged user inside guest could use this flaw to access host file system beyond the shared folder and potentially escalating their privileges on a host.Show less

In browser editing in Atlassian Bitbucket Server from version 4.13.0 before 5.4.8 (the fixed version for 4.13.0 through 5.4.7), 5.5.0 before 5.5.8 (the fixed version for 5.5.x), 5.6.0 before 5.6.5 (the fixed version for 5.6.x), 5.7.0 before 5.7.3 (the fixed version for 5.7.x), and 5.8.0 before 5.8.2 (the fixed version for 5.8.x), allows authenticated users to gain remote code execution using the in browser editing feature via editing a symbolic link within a repository.Show less

Spring Boot supports an embedded launch script that can be used to easily run the application as a systemd or init.d linux service. The script included with Spring Boot 1.5.9 and earlier and 2.0.0.M1 through 2.0.0.M7 is susceptible to a symlink attack which allows the "run_user" to overwrite and take ownership of any file on the same system. In order to instigate the attack, the application must be installed as a service and the "run_user" requires shell access to the server. Spring Boot application that are not installed as a service, or are not using the embedded launch script are not susceptible.Show less

In Kubernetes versions 1.3.x, 1.4.x, 1.5.x, 1.6.x and prior to versions 1.7.14, 1.8.9 and 1.9.4 containers using subpath volume mounts with any volume type (including non-privileged pods, subject to file permissions) can access files/directories outside of the volume, including the host's filesystem.Show less

RubyGems version Ruby 2.2 series: 2.2.9 and earlier, Ruby 2.3 series: 2.3.6 and earlier, Ruby 2.4 series: 2.4.3 and earlier, Ruby 2.5 series: 2.5.0 and earlier, prior to trunk revision 62422 contains a Directory Traversal vulnerability in install_location function of package.rb that can result in path traversal when writing to a symlinked basedir outside of the root. This vulnerability appears to have been fixed in 2.7.6.Show less

In open buildservice 2.6 before 2.6.3, 2.5 before 2.5.7 and 2.4 before 2.4.8 the source service patch application could generate non-standard files like symlinks or device nodes, which could allow buildservice users to break of confinement or cause denial of service attacks on the source service.Show less

Context relabeling of filesystems is vulnerable to symbolic link attack, allowing a local, unprivileged malicious entity to change the SELinux context of an arbitrary file to a context with few restrictions. This only happens when the relabeling process is done, usually when taking SELinux state from disabled to enable (permissive or enforcing). The issue was found in policycoreutils 2.5-11.Show less

OpenRC opentmpfiles through 0.1.3, when the fs.protected_hardlinks sysctl is turned off, allows local users to obtain ownership of arbitrary files by creating a hard link inside a directory on which "chown -R" will be run.Show less

systemd-tmpfiles in systemd through 237 mishandles symlinks present in non-terminal path components, which allows local users to obtain ownership of arbitrary files via vectors involving creation of a directory and a file under that directory, and later replacing that directory with a symlink. This occurs even if the fs.protected_symlinks sysctl is turned on.Show less

systemd-tmpfiles in systemd before 237 attempts to support ownership/permission changes on hardlinked files even if the fs.protected_hardlinks sysctl is turned off, which allows local users to bypass intended access restrictions via vectors involving a hard link to a file for which the user lacks write access, as demonstrated by changing the ownership of the /etc/passwd file.Show less