Security
Filesystem images and unprivileged containers
At the 2016 Linux Security Summit, James Bottomley presented some problems that users of unprivileged containers have encountered with regard to the user and group IDs (UIDs and GIDs) stored in filesystem images. Because of the way that user namespaces remap these IDs, there is a need for privileges in the initial namespace to access some files, which is exactly what unprivileged containers are trying to avoid. Bottomley also described some in-progress potential solutions to the problem.
He began by noting that his experience in container technology predates Docker. His interest lies in the kernel's primitive interfaces for containers, rather than the higher-level view of containers that Docker and other container orchestration tools have. Every orchestration tool uses those same kernel interfaces, so any work that is done on the kernel API is automatically made available to them—as long as they turn the feature on, that is.
![[James Bottomley]](https://static.lwn.net/images/2016/lss-bottomley-sm.jpg "James Bottomley")
One of the advantages of the kernel API is that it provides granular virtualization options so that container implementations can pick and choose. Container orchestration systems can enable the virtualization of various kinds of resources via namespaces—or not. That is what allows Docker to not use user namespaces for its containers, since it is not forced to do so, he said.
On the other hand, that granularity makes for an infinite variety of configurations for containers. The Open Container Initiative (OCI) standardization effort does not address this problem at all, Bottomley said. It is concerned with the packaging format for containers and says nothing about the kernel and container configuration. But there is also a subset of those configurations (which is also infinite) that are "completely insecure from the get-go".
Control groups (cgroups) and namespaces are the building blocks of containers, but he noted that most of the interesting development for containers—particularly security-related work—in the kernel right now is happening in the namespace code.
One of the more important namespaces for containers is the mount namespace, which allows containers to have their own view of the mounted filesystems. It is somewhat complex to set up securely, however, he said. The problems for unprivileged containers are primarily found in the mount namespace.
The process ID (PID) namespace is used by many container managers, but Bottomley said he has never quite understood why. There are both system containers, which are those that are meant to contain a full running system, and application containers (like Docker) that exist only to run a single application. The PID namespace exists partly so that there can be multiple init processes all running as PID 1 in separate system containers. The main advantage of having application containers in their own PID namespace is that it virtualizes the PIDs in the system so that containers cannot see the processes in other containers.
User namespaces
User namespaces were dissed in an earlier talk, he said, but he has a different take. "Instead of telling you why you should fear user namespaces, I'd like to tell you why you should love user namespaces."
The kernel API for containers is often described as "completely toxic", Bottomley said. Docker will proudly proclaim that the interface is too hard to be used, which is why everyone should use Docker. But unprivileged containers, which are containers that have been set up without relying on an orchestration system, also provide the "backbone of all security in container subsystems".
As the name implies, unprivileged containers are those that don't have a privileged root user. But that means different things to different people. The idea is to have a container where there is a root user ID inside it, but that ID maps to the unprivileged "nobody" user outside of the container. One way to do that is to have a container that doesn't map the root user (UID 0) at all, which is something that "a lot of people should do, but don't", he said with a chuckle. But some applications may need some "root-y privileges", so there needs to be a UID 0 inside the container that has some amount of elevated privileges with respect to the other UIDs in the container.
User namespaces can be used to implement both cases, but the "contentious bit" is having a root user with some privileges inside what is supposed to be an unprivileged container. In the ideal case, root inside the container would not have any privileges outside of it, but there are lots of actions that require privileges—including setting up namespaces. Many of the container primitives in Linux (e.g. unshare()) need root privileges.
The current state (as of Linux 4.8-rc3) is that user namespaces work well for unprivileged containers. But "cgroups don't work at all" for them. Thus, his talk is all about namespaces because he can't get cgroups to work for him.
Effectively, user namespaces give enhanced privileges to a user. Any time there is a mechanism to upgrade user privileges, it has the potential to be a security problem. But, he said, user namespaces do allow giving users enhanced privileges such that they believe they are root in a container, though they cannot damage the rest of the system using those privileges. That is the ideal that is being sought.
The allegation that he has heard is that "we are not there yet", but he disagrees. The IBM Bluemix container cloud is running in a bare-metal environment that employs user namespaces as the sole mechanism to protect the host from the guests, Bottomley said. The company is demonstrating that user namespaces are sufficient for security separation in a publicly accessible cloud. It has effectively bet its cloud business on user namespaces.
At its core, a user namespace is a mapping between IDs inside and outside the namespace. It is controlled by /proc files (uid_map and gid_map) that describe ranges of UIDs and GIDs to map from and to. There is also a projid_map file that is for group quotas, which can largely be ignored since it is only available for XFS, though ext4 support is coming. Finally, there is a setgroups file that can be used to deny processes in the namespace the ability to drop groups, which could actually grant privileges in some (believed to be fairly uncommon) configurations.
The user that creates a user namespace only has privileges to map their own UID into the new namespace. There are privileged utilities (newuidmap and newgidmap) that will allow additional mappings. The UID that creates the namespace is considered the owner of that namespace, so only it and root can actually enter the namespace (using nsenter()). In addition, unmapped UIDs are inaccessible even to root inside the namespace.
Filesystems
The kernel maps between the uid_t that represents the UID in the namespace to a kuid_t that is the real UID. For filesystems mounted in a namespace, that mapping is still done. So a container filesystem image gets handled with the real kuid_t values that have been stored as a file's owner and group.
So, if you try to run a standard Docker image in an unprivileged container, "it will fall over" because it has the wrong UIDs. Filesystem images can be shifted to have UIDs that get mapped into the container, but managing multiple shifted filesystem images is problematic.
What is really wanted is that IDs would be changed to their real counterparts within the kernel (so that any escape from the container would not be done using the container-specific UIDs), but that accesses to the filesystem would be translated back to the container UIDs—but only for filesystems mounted within the container. This is an unsolved problem in Linux right now, and one that is currently being worked on.
An old solution is bindfs, which is a FUSE filesystem that remounts a subtree with UID and GID changes. It requires root to do the mount. One problem is that the mappings are done one by one on the FUSE command line, so handling a thousand remappings is problematic. That is a solvable problem, but container developers are leery of depending on FUSE because of performance concerns.
Two other solutions were proposed for 4.6: Bottomley's shiftfs and portable root filesystems from Djalal Harouni. Shiftfs is effectively an in-kernel bindfs that uses ID ranges to avoid that problem in bindfs. It also requires root to set up a remapped subtree, which can then be bind mounted into the container. It "works reasonably well", he said.
Portable root filesystems allow any mounted filesystem to be marked as "shiftable", which means that it can be bind mounted into a container using the existing user namespace remapping. It requires changes to the VFS and underlying filesystems to add the mark, however. Both shiftfs and portable root filesystems allow bind mounting a subtree into a container, which solves most of the problem.
In addition, Seth Forshee is working on unprivileged FUSE mounting, which is part of what has held up either of the other two solutions from getting merged—beyond the fact that no one is quite sure which of the two should be chosen. Being root inside a user namespace does not provide enough privileges to mount a FUSE filesystem, so Forshee and namespaces maintainer Eric Biederman are looking to add filesystem ownership to user namespaces.
Effectively, the superblock of a filesystem would have a mapping for UIDs and GIDs that would be applied whenever a write was done to the filesystem. That would mean there would be a "double shift" of IDs: once from the namespace to kernel and then from the kernel to the filesystem view. But, to him, it looks like a good solution since it would move any security problems in shiftfs from being his responsibility to Forshee and Biederman, he said with a grin. That might not make for a particularly good argument from a security perspective, however.
The challenge now is to integrate the various pieces. Instead of two solutions (shiftfs, portable roots), where one needs to be chosen, there are those two solutions plus a "radically different" approach (superblock mapping). Both shiftfs and portable roots would trivially be able to use the superblock mapping (since they both have superblocks), but it all needs to be put together in a form that's ready for merging. He doesn't expect that to happen for a few more kernel development cycles, so there is still time for security folks to weigh in with concerns if they have them.
In conclusion, Bottomley said that the problem of accessing container images in unprivileged containers is unsolved at this point, but the broad outlines of potential solutions are taking shape. If there are security concerns with those, and "the squeaking in the room" seemed to indicate that there are, now would be the right time to bring them up. Either a solution is found or containers will always have a root user in them, which is more of a security threat than providing a sort of "fake root" for accessing container images.
[I would like to thank the Linux Foundation for travel support to attend the Linux Security Summit in Toronto.]
Minijail
Sandboxing services and applications running on the Linux kernel is a way to help mitigate problems they can cause when they have bugs or are compromised. While there are multiple technologies in the kernel to help with creating the sandbox, it is easy for programmers to get it wrong. Jorge Lucangeli Obes gave a presentation on minijail, which is a tool and library that Google uses in multiple systems for sandboxing. In fact, he said, Google uses it everywhere: on Android, Chrome OS, on its servers, and beyond.
He started the talk by showing a portion of a ps listing from his laptop that showed multiple root-owned processes running. Each of those processes is "one bug away" from an attacker getting root privileges. For example, the Bluetooth daemon is running as root and listening on the air even on a "super modern kernel". He could have set up a Bluetooth beacon in the room to try to exploit the Bluetooth stacks in the laptops present, which would have given him complete control of them if it was successful; he didn't do that, but it is certainly possible.
Part of the reason that so many processes run as root is that there are misaligned incentives, Lucangeli said. Administrators don't know what permissions are needed by the software and developers don't know where their software is running. Even when the developers do try to reduce the privileges their programs need, they make mistakes as there are a lot of pitfalls in doing so correctly.
![[Jorge Lucangeli Obes]](https://static.lwn.net/images/2016/lss-lucangeli-sm.jpg "Jorge Lucangeli Obes")
So instead of reinventing the wheel for each program and expecting the developers to be experts in security hardening, Google developed minijail. That way, those who are writing Android or Chrome OS system programs do not have be security experts; there is simply a library they can use to handle these sandboxing chores. That library will be regularly tested to ensure that it always works and there will be one place to fix bugs when it doesn't.
Minijail is also part of what allows Android apps to run on Chrome OS, he said. It is effectively creating a container for programs that use it. So minijail is a "containment helper" for Android, Chrome OS, Brillo, and more.
The goal is to eliminate as many of the services running as root as possible. For one thing, minijail uses Linux capabilities to reduce the privileges a process needs. For example, the Bluetooth daemon needs the ability to administrate network interfaces and to open sockets, but it does not need to be able to remount filesystems or reboot the system. So it is given the appropriate capabilities that allow it to do its job—and no others.
In Chrome OS, for example, no network-facing services are running as root. They are not completely unprivileged, of course, but instead try to follow the principle of least privilege.
There's more to minijail than just capabilities, though. Processes with a restricted set of capabilities can still access the entire kernel API. It really doesn't make sense for a process that doesn't have the capability needed to mount a filesystem to still have access to the mount() system call, Lucangeli said.
So minijail uses seccomp to restrict the system calls that processes can make. For example, cat needs only nine system calls to function, instead of the 350 or so that are available in the kernel API. The idea is that even if the process gets subverted, it can't really do anything more than it is meant to do. The Chrome rendering process only needs around half of the available system calls to do its job; with seccomp protections, malicious content still can't cause it to make any of those other calls.
Minijail uses LD_PRELOAD to ensure that the mini-jail is entered before the program's main() function is called. This has the advantage that the system calls used by glibc initialization do not have to be added to the seccomp rules, since glibc is loaded and initialized before the jail.
There is another reason that LD_PRELOAD is needed, he said. Ostensibly, capabilities are inherited over execve(), so you can have a launcher that sets up the sandbox and runs the program in it, but there is a hitch. Unless filesystem capabilities are enabled, it is impossible to actually pass the capabilities on to the new program. There are good reasons not to enable the file-based capabilities, however, because they allow processes to gain capabilities at runtime, which makes reasoning about them more difficult. "Everyone who tried to use capabilities to do something useful" has seen the problem, he said. The solution was ambient capabilities, which allow processes to pass their capabilities across an execve() call without using filesystem capabilities.
Sometimes code is not prepared to deal with the errors returned from a capability check or a seccomp rule, so there is another option in that case: return a dummy object. That is the way he thinks of namespaces in some contexts. They allow the kernel to return "fake" objects for some resources. Namespaces make it easier to port code from elsewhere without having to do major surgery on the code, Lucangeli said.
All seven of the Linux namespaces are supported in minijail at this point. He showed an example using process ID (PID) namespaces, which can be used to prevent "exploiting horizontally"—attacking other processes rather than the kernel. Separating processes into their own PID namespace prevents compromised programs from even seeing the other processes. Over the years, there have been several bugs in the code checking for ptrace() access, but they can't be exploited if the target PID cannot even be seen.
The minijail0 binary wraps all of these techniques up together into a single program that can start and enter namespaces, apply seccomp rules, manage capabilities, and so on. It provides access to all of the Linux sandbox features in that one binary. When starting a PID namespace, it will launch a small program that knows how to act like init in the namespace. It will also use a mount namespace to remount /proc inside the mini-jail.
While there may be security concerns about user namespaces, they are the thing that "ties everything together" for minijail. Up until user namespace support was added to minijail, minijail0 had to be run as the root user. The team got requests from within Google to be able to run minijail on systems where root access was not available. Now it can be run as a regular user, which has opened up new applications for minijail, such as on build systems or in the fuzzing infrastructure.
There are some processes that need to run as root, such as the Android init process. So, for the Android container on Chrome OS, the team put the Android system into a user namespace where it was root; some parts of the filesystem were bind-mounted into the container so that init could find things where it expected them. Everything "pretty much just worked". Input events were plumbed into the container and graphics textures are sent out to Chrome OS over a file descriptor; those were the two main changes to Android to make it work. Minijail allowed most of Android to run unmodified on Chrome OS and it also solved many other problems in Chrome OS, Lucangeli said.
Many people were involved in developing minijail. It is used in Chrome OS and will be in Android 7.0 (Nougat), mostly for the seccomp support. It is available under the BSD license in the Android repositories.
[I would like to thank the Linux Foundation for travel support to attend the Linux Security Summit in Toronto.]
Brief items
Security quotes of the week
On unprotected equipment, the device's makers say it will "instantly and permanently disable unprotected hardware" .
Who would do this? It doesn't seem like something an activist, criminal, or researcher would do. Profiling core infrastructure is common practice in espionage and intelligence gathering. It's not normal for companies to do that. Furthermore, the size and scale of these probes -- and especially their persistence -- points to state actors. It feels like a nation's military cybercommand trying to calibrate its weaponry in the case of cyberwar. It reminds me of the US's Cold War program of flying high-altitude planes over the Soviet Union to force their air-defense systems to turn on, to map their capabilities.
New vulnerabilities
curl: certificate reuse
| Package(s): | curl | CVE #(s): | CVE-2016-7141 | ||||||||||||||||||||||||||||
| Created: | September 9, 2016 | Updated: | September 14, 2016 | ||||||||||||||||||||||||||||
| Description: | From the Debian LTS advisory: It was discovered that libcurl built on top of NSS (Network Security Services) incorrectly re-used client certificates if a certificate from file was used for one TLS connection but no certificate set for a subsequent TLS connection. | ||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||
elog: unauthorized posts
| Package(s): | elog | CVE #(s): | CVE-2016-6342 | ||||||||
| Created: | September 12, 2016 | Updated: | September 14, 2016 | ||||||||
| Description: | From the Red Hat bugzilla:
It has been reported that one can post from any username entry on the logbook, with a post request and guest readable logbook, using elog 3.1.1. | ||||||||||
| Alerts: |
| ||||||||||
file-roller: file deletion
| Package(s): | file-roller | CVE #(s): | CVE-2016-7162 | ||||||||||||||||
| Created: | September 9, 2016 | Updated: | September 22, 2016 | ||||||||||||||||
| Description: | From the Ubuntu advisory: It was discovered that File Roller incorrectly handled symlinks. If a user were tricked into extracting a specially-crafted archive, an attacker could delete files outside of the extraction directory. | ||||||||||||||||||
| Alerts: |
| ||||||||||||||||||
gdk-pixbuf: denial of service
| Package(s): | gdk-pixbuf | CVE #(s): | CVE-2016-6352 | ||||||||||||||||||||
| Created: | September 9, 2016 | Updated: | November 4, 2016 | ||||||||||||||||||||
| Description: | From the openSUSE bug report: A write out-of-bounds parsing an ico file was found in gdk-pixbuf 2.30.7. A maliciously crafted file can cause the application to crash. | ||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||
gnutls: certificate verification bypass
| Package(s): | gnutls | CVE #(s): | CVE-2016-7444 | ||||||||||||||||||||||||||||||||
| Created: | September 14, 2016 | Updated: | September 28, 2016 | ||||||||||||||||||||||||||||||||
| Description: | From the Red Hat bugzilla:
It was found an issue in certificate validation using OCSP responses caused by not verifying the serial length, which can falsely report a certificate as valid. See the CVE assignment for more information. | ||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||
inspircd: user impersonation
| Package(s): | inspircd | CVE #(s): | CVE-2016-7142 | ||||
| Created: | September 9, 2016 | Updated: | September 14, 2016 | ||||
| Description: | From the Debian advisory: It was discovered that incorrect SASL authentication in the Inspircd IRC server may lead to users impersonating other users. | ||||||
| Alerts: |
| ||||||
libarchive: two vulnerabilities
| Package(s): | libarchive | CVE #(s): | CVE-2015-8915 CVE-2016-7166 | ||||||||||||||||||||||||||||||||||||
| Created: | September 12, 2016 | Updated: | September 14, 2016 | ||||||||||||||||||||||||||||||||||||
| Description: | From the Debian LTS advisory:
CVE-2015-8915: Paris Zoumpouloglou of Project Zero labs discovered a flaw in libarchive bsdtar. Using a crafted file bsdtar can perform an out-of-bounds memory read which will lead to a SEGFAULT. CVE-2016-7166: Alexander Cherepanov discovered a flaw in libarchive compression handling. Using a crafted gzip file, one can get libarchive to invoke an infinite chain of gzip compressors until all the memory has been exhausted or another resource limit kicks in. | ||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||
libarchive: file overwrite
| Package(s): | libarchive | CVE #(s): | CVE-2016-5418 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | September 13, 2016 | Updated: | October 17, 2016 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Red Hat advisory:
A flaw was found in the way libarchive handled hardlink archive entries of non-zero size. Combined with flaws in libarchive's file system sandboxing, this issue could cause an application using libarchive to overwrite arbitrary files with arbitrary data from the archive. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
libtorrent-rasterbar: denial of service
| Package(s): | libtorrent-rasterbar | CVE #(s): | CVE-2016-7164 | ||||||||
| Created: | September 14, 2016 | Updated: | September 26, 2016 | ||||||||
| Description: | From the Arch Linux advisory:
A bug has been found in the libtorrent-rasterbar code handling GZIP-encoded responses from a tracker, where malformed responses could lead to a crash. A remote attacker can crash a client using libtorrent-rasterbar by sending malformed GZIP-encoded responses from a tracker. | ||||||||||
| Alerts: |
| ||||||||||
mysql: SQL injection/privilege escalation
| Package(s): | mysql mariadb | CVE #(s): | CVE-2016-6662 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | September 14, 2016 | Updated: | November 11, 2016 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the legalhackers advisory:
An independent research has revealed multiple severe MySQL vulnerabilities. This advisory focuses on a critical vulnerability with a CVEID of CVE-2016-6662 which can allow attackers to (remotely) inject malicious settings into MySQL configuration files (my.cnf) leading to critical consequences. The vulnerability affects all MySQL servers in default configuration in all version branches (5.7, 5.6, and 5.5) including the latest versions, and could be exploited by both local and remote attackers. Both the authenticated access to MySQL database (via network connection or web interfaces such as phpMyAdmin) and SQL Injection could be used as exploitation vectors. As SQL Injection attacks are one of the most common issues in web applications, the CVE-2016-6662 vulnerability could put web applications at a critical risk in case of a successful SQL Injection attack. A successful exploitation could allow attackers to execute arbitrary code with root privileges which would then allow them to fully compromise the server on which an affected version of MySQL is running. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
openjpeg2: two vulnerabilities
| Package(s): | openjpeg2 | CVE #(s): | CVE-2016-1924 CVE-2016-7163 | ||||||||||||||||||||||||||||
| Created: | September 12, 2016 | Updated: | September 19, 2016 | ||||||||||||||||||||||||||||
| Description: | From the Debian advisory:
Multiple vulnerabilities in OpenJPEG, a JPEG 2000 image compression / decompression library, may result in denial of service or the execution of arbitrary code if a malformed JPEG 2000 file is processed. | ||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||
pdns: denial of service
| Package(s): | pdns | CVE #(s): | CVE-2016-5426 CVE-2016-5427 | ||||||||||||||||||||||||
| Created: | September 12, 2016 | Updated: | October 3, 2016 | ||||||||||||||||||||||||
| Description: | From the Debian advisory:
CVE-2016-5426 / CVE-2016-5427: Florian Heinz and Martin Kluge reported that the PowerDNS Authoritative Server accepts queries with a qname's length larger than 255 bytes and does not properly handle dot inside labels. A remote, unauthenticated attacker can take advantage of these flaws to cause abnormal load on the PowerDNS backend by sending specially crafted DNS queries, potentially leading to a denial of service. | ||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||
php: multiple vulnerabilities
| Package(s): | php | CVE #(s): | CVE-2016-7133 CVE-2016-7134 | ||||||||||||||||||||||||||||||||
| Created: | September 9, 2016 | Updated: | September 14, 2016 | ||||||||||||||||||||||||||||||||
| Description: | From the CVE entries CVE-2016-7133 - Multiple cross-site scripting (XSS) vulnerabilities in onlinetools.org EasyImageCatalogue 1.3.1 allow remote attackers to inject arbitrary web script or HTML via the (1) search and (2) d index.php parameters to index.php, (3) dir parameter to thumber.php, and the d parameter to (4) describe.php and (5) addcomment.php. NOTE: the provenance of this information is unknown; the details are obtained solely from third party information. CVE-2016-7134 - Multiple cross-site scripting (XSS) vulnerabilities in the default URI in Chris LaPointe RedGalaxy Download Center 1.2 allow remote attackers to inject arbitrary web script or HTML via the (1) file parameter, (2) message parameter in a login action, (3) category parameter in a browse action, (4) now parameter, or (5) search parameter in a search_results action. NOTE: the provenance of this information is unknown; the details are obtained solely from third party information. | ||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||
python-jwcrypto: information disclosure
| Package(s): | python-jwcrypto | CVE #(s): | CVE-2016-6298 | ||||||||
| Created: | September 12, 2016 | Updated: | September 14, 2016 | ||||||||
| Description: | From the CVE entry:
The _Rsa15 class in the RSA 1.5 algorithm implementation in jwa.py in jwcrypto before 0.3.2 lacks the Random Filling protection mechanism, which makes it easier for remote attackers to obtain cleartext data via a Million Message Attack (MMA). | ||||||||||
| Alerts: |
| ||||||||||
qemu: directory/path traversal
| Package(s): | qemu | CVE #(s): | CVE-2016-7116 | ||||||||||||||||||||||||||||||||
| Created: | September 12, 2016 | Updated: | September 14, 2016 | ||||||||||||||||||||||||||||||||
| Description: | From the Debian LTS advisory:
Quick Emulator(Qemu) built with the VirtFS, host directory sharing via Plan 9 File System(9pfs) support, is vulnerable to a directory/path traversal issue. It could occur while creating or accessing files on a shared host directory. A privileged user inside guest could use this flaw to access undue files on the host. | ||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||
webkit2gtk: multiple vulnerabilities
| Package(s): | webkit2gtk | CVE #(s): | CVE-2016-1854 CVE-2016-1858 CVE-2016-1859 CVE-2016-4583 CVE-2016-4585 CVE-2016-4586 CVE-2016-4588 CVE-2016-4589 CVE-2016-4623 CVE-2016-4651 | ||||
| Created: | September 14, 2016 | Updated: | September 14, 2016 | ||||
| Description: | From the Ubuntu advisory:
A large number of security issues were discovered in the WebKitGTK+ Web and JavaScript engines. If a user were tricked into viewing a malicious website, a remote attacker could exploit a variety of issues related to web browser security, including cross-site scripting attacks, denial of service attacks, and arbitrary code execution. | ||||||
| Alerts: |
| ||||||
wget: race condition
| Package(s): | wget | CVE #(s): | CVE-2016-7098 | ||||||||||||
| Created: | September 12, 2016 | Updated: | January 4, 2017 | ||||||||||||
| Description: | From the openSUSE bug report:
A possible vulnerability was found in wget. The vulnerability surfaces when wget is used to download a single file with recursive option (-r / -m) and an access list ( -A ), wget only applies the list at the end of the download process. Although the file get successfully deleted in the end, this creates a race condition situation as an attacker who has control over the URL, could slow down the download process so that he had a chance to make use of the malicious file before it gets deleted. | ||||||||||||||
| Alerts: |
| ||||||||||||||
wordpress: multiple vulnerabilities
| Package(s): | wordpress | CVE #(s): | CVE-2016-7168 CVE-2016-7169 | ||||||||||||||||
| Created: | September 9, 2016 | Updated: | September 30, 2016 | ||||||||||||||||
| Description: | From the arch Linux advisory: CVE-2016-7168 (cross-site scripting) A cross-site scripting vulnerability via an image filename, reported by SumOfPwm researcher Cengiz Han Sahin. CVE-2016-7169 (directory traversal) A directory traversal vulnerability in the upgrade package uploader, reported by Dominik Schilling from the Wordpress security team. | ||||||||||||||||||
| Alerts: |
| ||||||||||||||||||
xen: multiple vulnerabilities
| Package(s): | xen | CVE #(s): | CVE-2016-7092 CVE-2016-7094 CVE-2016-7154 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | September 9, 2016 | Updated: | September 14, 2016 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Debian advisory: CVE-2016-7092 (XSA-185) Jeremie Boutoille of Quarkslab and Shangcong Luan of Alibaba discovered a flaw in the handling of L3 pagetable entries, allowing a malicious 32-bit PV guest administrator can escalate their privilege to that of the host. CVE-2016-7094 (XSA-187) x86 HVM guests running with shadow paging use a subset of the x86 emulator to handle the guest writing to its own pagetables. Andrew Cooper of Citrix discovered that there are situations a guest can provoke which result in exceeding the space allocated for internal state. A malicious HVM guest administrator can cause Xen to fail a bug check, causing a denial of service to the host. CVE-2016-7154 (XSA-188) Mikhail Gorobets of Advanced Threat Research, Intel Security discovered a use after free flaw in the FIFO event channel code. A malicious guest administrator can crash the host, leading to a denial of service. Arbitrary code execution (and therefore privilege escalation), and information leaks, cannot be excluded. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||
xen: privilege escalation
| Package(s): | xen | CVE #(s): | CVE-2016-7093 | ||||||||||||||||||||||||||||||||||||
| Created: | September 14, 2016 | Updated: | September 14, 2016 | ||||||||||||||||||||||||||||||||||||
| Description: | From the Red Hat bugzilla:
When emulating HVM instructions, Xen uses a small i-cache for fetches from guest memory. The code that handles cache misses does not check if the address from which it fetched lies within the cache before blindly writing to it. As such it is possible for the guest to overwrite hypervisor memory. It is currently believed that the only way to trigger this bug is to use the way that Xen currently incorrectly wraps CS:IP in 16 bit modes. The included patch prevents such wrapping. A malicious HVM guest administrator can escalate their privilege to that of the host. | ||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||
Page editor: Jake Edge
Next page:
Kernel development>>