Security
A trio of fuzzers
In the testing and fuzzing microconference at the 2016 Linux Plumbers Conference, three separate kernel fuzzing projects were presented and discussed. It didn't take long to see that there are a few different opportunities for the projects to collaborate even though they have different focuses and operational modes. Some of that collaboration got started the next day in a session on creating a formal specification of the Linux user-space APIs.
Fuzzing is a testing technique aimed at finding bugs by providing random inputs to programs and APIs. Often, the bugs found are exploitable security vulnerabilities, so there is a strong push to apply fuzzing to the kernel.
syzkaller
First up was Dmitry Vyukov, who was presenting about syzkaller, which is a coverage-guided fuzzer. The idea is to take a corpus of "interesting inputs" and to record the code paths that are executed for those inputs. The inputs are then mutated in various ways, and if a new code path is taken, that input gets added to the corpus. This has been done before in user space, but he wanted to apply it to the kernel.
![[Dmitry Vyukov]](https://static.lwn.net/images/2016/lpc-vyukov-sm.jpg "Dmitry Vyukov")
One problem is in how to get the coverage information out of the kernel. Over the last year or so, GCC has gained the ability to insert a function call into every basic block in the code. The syzkaller team added the CONFIG_KCOV option to the kernel to build it using that GCC mode and to provide a way for user space to retrieve the coverage information from debugfs.
Vyukov spent a bit of time explaining the system-call descriptions that are used to guide the mutations of the inputs. It is mostly about argument and return types for the function, but goes beyond simply the C types of those elements. For example, it can describe things like the map file descriptors that are created by the bpf() system call (when using the MAP_CREATE flag), which are placed into a structure that gets passed to other bpf() operations.
The system-call descriptions allow syzkaller to generate and mutate programs that make system calls. The algorithm used is to start with an empty corpus; each iteration either generates a new program or chooses one from the corpus to mutate. The program is executed and the coverage is collected; if new parts of the kernel code have been reached, the program is added into the corpus.
There is a threaded execution mode to handle blocking system calls. For example, a read() on a pipe will block until a write() is done on the other end of the pipe, so each system call is done in its own thread. There is also a "collider" that tries to simultaneously run consecutive system calls in the program, which finds "a lot of data races", he said. It is currently implemented in a basic form. There is an open question how to make it better and how hard to collide the calls.
Another area that is a work in progress is a way to provide "external stimulus" to the programs. For example, a program may need to have some network packets delivered to it. The idea is to have hooks in the kernel to inject data in the right places, but it is not completely clear where those hooks should be. It needs to be done synchronously in the thread so that the code coverage information can be collected. It also needs to be reproducible so that problems can be tracked down. Part of that is that he needs to ensure that the kernel is not keeping state information between calls, such as dynamic cookie values.
He is also looking at doing smarter program mutation; the program space is "enormous". Right now, there is some basic prioritization, so that a program that works with TCP sockets will add more calls that use sockets. But he thinks there is more work to be done; using the knowledge of what the program is doing, there should be a way to mutate the programs better. He doesn't have an exact solution, but hopes to get there.
But a small group of people cannot describe all of the system calls, he said. Sometimes a good description requires domain knowledge for the system call and underlying subsystem. Also, new system calls, flags, and fields in structures are constantly being added, so the syzkaller team cannot keep up. The previous day he had gotten together with the BPF folks and made the description of that system call better.
Currently, those descriptions are part of syzkaller itself, but it would be nice to have them in the kernel tree, Vyukov said. There are two proposed locations for those descriptions: include/uapi or Documentation. Sasha Levin suggested that a machine-readable description of the system calls could be used by other tools to, for example, validate system calls at runtime. And Thomas Gleixner objected that "random descriptions" as documentation is not what is needed; a formal specification of the user-space API should be created instead. There is a group in Germany working on safety certifications for Linux that would be willing to help with that effort, he said, as would some kernel developers. That idea was generally well-received and would come up again in the microconference.
Each program that is generated for testing is self-contained, Vyukov said. They run in one process with separate directories for each. The programs can become arbitrarily long if needed; if there is a resource that the program needs to use, it must create it as there are no facilities for passing things into the program.
In less than a year, though, syzkaller has found more than 300 runtime failures. Many of those were security issues, he said, so reports from the syzkaller team should not be ignored.
Gleixner suggested that syzkaller exercise the signal code in the kernel because it is a code path that has not had much coverage over the years. If one thread is blocked in a system call and another thread sends it a signal that will get into code paths that are rarely executed. Vyukov said that syzkaller has support for some of the signal-related system calls, but not to do what Gleixner proposed. It should be possible to do so, though.
Trinity
Dave Jones then stepped forward to talk about the Trinity system-call fuzzer. Jones gave more details on how Trinity functions in a talk at linux.conf.au in 2013.
![[Dave Jones]](https://static.lwn.net/images/2016/lpc-jones-sm.jpg "Dave Jones")
Over the last year, he has been trying to get the child process that is making the system calls to run longer before it fails from bugs in Trinity itself. It used to be on the order of 50 system calls before a crash, but is now around 5000 calls. Longer-running processes meant that he needed to add garbage collection for the mmap() regions so that the processes do not get a visit from the out-of-memory (OOM) killer.
A key feature that he has added in the last year is to alter the access patterns for the mmap() regions. Now a test run can access the first page, last page, every other page, or a random page (as it had done previously) in the region. That, he said, turned up a lot of bugs.
He has also been improving the BPF support in Trinity. In the last six months, he has added better BPF generation. The plan is to attach random BPF programs to tracepoints and "see what falls out". There have also been stability and debuggability improvements made.
For a new system call, Trinity can find trivial bugs in the implementation pretty quickly. The others that it finds are those that take a long time to run and are hard to reproduce. In addition, there is no way to get a real handle on what caused the crash. He does dump the last system calls made in all of the threads, but that may not really help. He is going to add network logging which would allow Trinity to store more state before the crash.
Mathieu Desnoyers asked if Trinity could use the tracing facilities in the kernel, such as the ftrace function tracer or LTTng, to gather its state. Jones said that was a good idea that he wanted to explore. Steve Rostedt suggested that choosing only certain functions to trace could be one way to reduce the size of the trace. The ftrace ring buffer will be part of what gets dumped in a kernel crash dump, so that could be used to extract the tracepoints that were hit before a crash.
At Facebook, where Jones works, he has machines running Trinity constantly. He would like to make it more parallelizable across machines so that crashes that take 24 hours to reproduce could be done in an hour on, say, 50 machines. He wants to find a way to reduce the randomness in Trinity when trying to reproduce problems so that crashes happen more predictably and can hopefully be diagnosed more quickly.
Jones noted that he wanted to talk to Desnoyers and Rostedt about tracing, as well as Vyukov about the system-call descriptions that syzkaller uses. Vyukov said that it might make sense for Trinity to use the syzkaller descriptions, and Jones agreed. Right now, it is a lot manual work to maintain that information, which is something Jones hates doing. He also often misses new system calls and flags that get added. There is a lot of value in having two fuzzers that work differently sharing infrastructure, he said.
The conversation turned back to the idea of a formal system-call specification. Mike Frysinger noted that user space could use that information in a variety of ways; strace could use it, for example. Jones said it is surprising that "we haven't gotten there already", but it appears that a critical mass is forming around the idea at this point.
Someone asked if the macros that define system calls in the kernel could be extended with more metadata to automatically generate the specification. Vyukov said there is a lot more that is needed than could be put into the macros; for example, valid flag values and crypto algorithms would need to part of the specification. Levin said that it was important to write the specification rather than get the information automatically; the kernel should "chase the specification", instead of the other way around.
Jones concluded by saying that he plans to get back to the networking code in Trinity. He hasn't really been finding networking bugs over the last year and would like to change that. He wants to talk with Vyukov about his ideas for injecting network traffic into processes. There is a huge opportunity to collaborate on that, he said.
perf_fuzzer
The last fuzzer presented in the track is a special-purpose one that simply fuzzes a single system call: perf_event_open(). Vince Weaver spoke about his perf_fuzzer tool, which he has also written about for LWN. Weaver is a professor at the University of Maine and said that he had wanted to give his presentation using a Raspberry Pi with a custom operating system that he wrote, but had recently broken the frame buffer support, so he went without slides (as had Jones before him).
![[Vince Weaver]](https://static.lwn.net/images/2016/lpc-weaver-sm.jpg "Vince Weaver")
He set out to fuzz perf because he wanted to show that it is safe for use in high-performance computing (HPC). Users of HPC systems hate crashes, but want to use the performance counters to monitor their workloads. perf_event_open() has different paranoia levels that can be set via a sysctl parameter (kernel.perf_event_paranoid). The default is 2, which does not allow regular users access to some of the more interesting perf features. He set out to show that it would be safe to reduce that value to 0, so that users could access those features.
Unfortunately, his results have shown the opposite. A value of 0 is not safe at this point, which has led to calls to further restrict perf_event_open(). That is not at all what he wanted to see, he said.
perf_event_open() has a complicated interface that involves a structure with lots of entries that can interact in different ways. The man page is not that great, which he can say since he wrote it. perf_event_open() also interacts with other system calls.
At this point, all of the low-hanging fruit has been caught in perf_event_open(). Other fuzzers, such as Trinity and syzkaller don't find any problems, but perf_fuzzer still does. The perf subsystem has "tentacles all over the kernel", it is entangled with the proc filesystem, sysfs, fork(), BPF, tracepoints, and more. It also generates a lot of non-maskable interrupts (NMIs). Beyond that are the hardware interactions that make it hard to have deterministic results. Things like cache misses are not deterministic at the hardware level, for example. Also, performance counters cannot be virtualized.
Over the previous two weeks, he had run a bunch of tests with perf_fuzzer, which was rather tedious to do, Weaver said. He wanted to run with a recent kernel from Git, which is easy to do on x86, but not so easy for ARM. He has difficulty getting Git kernels to run on his boards.
When only using the facilities available with a paranoid value of 2, a
Pentium 4 will crash in eight hours minutes,
while a Core 2 will run for a week without any problems. Others, such
as Haswell, will crash in two or three days. A Raspberry Pi will run for
more than a week without problems, but that may be due to how slow the
processor is.
Most of the bugs are either RCU or NMI stalls and it is not clear what the underlying problem actually is. Sometimes the systems lock up with nothing on the serial console. Many of the problems are not reproducible either.
For a paranoid value of 1, the Core 2 will crash in one day, while a Haswell will crash in two hours. At a paranoid level of 0, the Core 2 takes 21 hours to crash, and the Haswell will crash in one or two hours. He has run into something he suspects is a hardware bug on Haswell as well. A paranoid value of -1 (no restrictions) is "not recommended", he said. So, after years of work finding and fixing bugs in perf_event_open(), you can still crash a machine by running perf_fuzzer long enough. Those crashes will be hard to debug, which is frustrating.
Weaver likes the idea of a more formalized specification for system calls and other user-space APIs. It would be nice to have a way to find out about new things added to the interfaces and it is great to see more people get interested in these problems. He has tried getting funding and in having his research published without much success. In addition, perf_fuzzer is being used to find bugs and collect bug bounties, but he rarely gets any code contributions from others—or even hears from them at all.
For a long time, work on improving perf_fuzzer has been stalled because it was so easy to crash machines with it. There simply has been no impetus to add more features. He would like to add support for control groups and BPF to the fuzzer, possibly by reusing the Trinity BPF fuzzing code. He finished by noting that he has a paper [PDF] on his web site that goes into some detail on how perf_fuzzer operates.
Vyukov wondered if Weaver had tried using the KernelAddressSanitizer (KASAN) while fuzzing with perf_fuzzer. Weaver said that he had not done so, but there was no real reason for that, so it is probably worth trying. Vyukov also asked what the advantage was for a specialized fuzzer and perf developer Peter Zijlstra quickly spoke up to say that perf_fuzzer is still finding bugs, while syzkaller can't crash perf any longer.
Part of the difference may be that syzkaller runs in a virtual machine, normally, while perf_fuzzer runs on bare metal. Weaver also pointed out that perf_event_open() has specialized needs for things like its mmap() region that Trinity and syzkaller may not be creating in the right way because they lack the specialized knowledge of the interface that perf_fuzzer has. Jones suggested that both Trinity and perf_fuzzer might benefit from some coverage guidance to help in reproducing bugs when they are encountered.
That's where the conversation wound down, but it is clear there are several areas of collaboration that could, and seemingly will, be pursued. The system-call (or user-space API) specification gained quite a bit of traction in the microconference; we will have to see where that ends up. Meanwhile, these three fuzzers (and perhaps others that might crop up) can benefit from each others' work—which should hopefully lead to more kernel bugs being found and fixed.
[ Thanks to LWN subscribers for supporting my travel to Santa Fe for LPC. ]
New vulnerabilities
389-ds-base: two vulnerabilities
| Package(s): | 389-ds-base | CVE #(s): | CVE-2016-5405 CVE-2016-5416 | ||||||||||||||||||||||||||||||||||||
| Created: | November 3, 2016 | Updated: | November 21, 2016 | ||||||||||||||||||||||||||||||||||||
| Description: | From the Red Hat advisory:
* It was found that 389 Directory Server was vulnerable to a remote password disclosure via timing attack. A remote attacker could possibly use this flaw to retrieve directory server password after many tries. (CVE-2016-5405) * It was found that 389 Directory Server was vulnerable to a flaw in which the default ACI (Access Control Instructions) could be read by an anonymous user. This could lead to leakage of sensitive information. (CVE-2016-5416) | ||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||
ansible: two vulnerabilities
| Package(s): | ansible | CVE #(s): | CVE-2016-8614 CVE-2016-8628 | ||||||||||||
| Created: | November 8, 2016 | Updated: | November 21, 2016 | ||||||||||||
| Description: | From the Red Hat bugzilla:
CVE-2016-8614: It was found that apt_key module does not properly verify key fingerprints, allowing remote adversary to create an OpenPGP key which matches the short key ID and inject this key instead of the correct key. CVE-2016-8628: It was found that it's possible to inject code and gain remote code execution via setting ansible_ssh_executable variable by attacker that takes over of controlled server. | ||||||||||||||
| Alerts: |
| ||||||||||||||
chromium: memory leak
| Package(s): | chromium | CVE #(s): | CVE-2016-5198 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | November 7, 2016 | Updated: | November 9, 2016 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the openSUSE advisory:
- CVE-2016-5198: out of bounds memory access in v8 (boo#1008274) | ||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||
curl: insufficient validation
| Package(s): | curl | CVE #(s): | CVE-2016-8625 | ||||||||||||||||||||||||||||||||
| Created: | November 3, 2016 | Updated: | November 9, 2016 | ||||||||||||||||||||||||||||||||
| Description: | From the Arch Linux advisory:
- CVE-2016-8625 (insufficient validation): When curl is built with libidn to handle International Domain Names (IDNA), it translates them to puny code for DNS resolving using the IDNA 2003 standard, while IDNA 2008 is the modern and up-to-date IDNA standard. This misalignment causes problems with for example domains using the German ß character (known as the Unicode Character 'LATIN SMALL LETTER SHARP S') which is used at times in the .de TLD and is translated differently in the two IDNA standards, leading to users potentially and unknowingly issuing network transfer requests to the wrong host. For example, straße.de is translated into strasse.de using IDNA 2003 but is translated into xn--strae-oqa.de using IDNA 2008. Needless to say, those host names could very well resolve to different addresses and be two completely independent servers. IDNA 2008 is mandatory for .de domains. This name problem exists for DNS-using protocols in curl, but only when built to use libidn. | ||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||
jasper: multiple vulnerabilities
| Package(s): | jasper | CVE #(s): | CVE-2016-8884 CVE-2016-8885 CVE-2016-8887 | ||||||||||||||||||||||||
| Created: | November 7, 2016 | Updated: | November 9, 2016 | ||||||||||||||||||||||||
| Description: | From the openSUSE bug reports:
CVE-2016-8884: AddressSanitizer: SEGV on unknown address 0x000000000000 0x7f90527a18fd in bmp_getdata ... jasper-1.900.5/src/libjasper/bmp/bmp_dec.c:394:5 CVE-2016-8885: AddressSanitizer: SEGV on unknown address 0x000000000000 0x7f888b2f5a43 in bmp_getdata ... jasper-1.900.5/src/libjasper/bmp/bmp_dec.c:398:5 CVE-2016-8887: AddressSanitizer: SEGV on unknown address 0x000000000000 0x7f8dcb5bc940 in jp2_colr_destroy ... jasper-1.900.5/src/libjasper/jp2/jp2_cod.c:443:3 | ||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||
jasper: multiple vulnerabilities
| Package(s): | jasper | CVE #(s): | CVE-2016-8690 CVE-2016-8691 CVE-2016-8692 CVE-2016-8693 CVE-2016-8880 CVE-2016-8881 CVE-2016-8882 CVE-2016-8883 CVE-2016-8886 | ||||||||||||||||||||||||||||||||
| Created: | November 4, 2016 | Updated: | November 9, 2016 | ||||||||||||||||||||||||||||||||
| Description: | From the openSUSE advisory:
- CVE-2016-8690: Null pointer dereference in bmp_getdata triggered by crafted BMP image (bsc#1005084). - CVE-2016-8691, CVE-2016-8692: Missing range check on XRsiz and YRsiz fields of SIZ marker segment (bsc#1005090). - CVE-2016-8693: The memory stream interface allowed for a buffer size of zero. The case of a zero-sized buffer was not handled correctly, as it could lead to a double free (bsc#1005242). - CVE-2016-8880: Heap overflow in jpc_dec_cp_setfromcox() (bsc#1006591). - CVE-2016-8881: Heap overflow in jpc_getuint16() (bsc#1006593). - CVE-2016-8882: Null pointer access in jpc_pi_destroy (bsc#1006597). - CVE-2016-8883: Assert triggered in jpc_dec_tiledecode() (bsc#1006598). - CVE-2016-8886: Memory allocation failure in jas_malloc (jas_malloc.c) (bsc#1006599). | ||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||
java-1.8.0-openjdk-aarch32: multiple vulnerabilities
| Package(s): | java-1.8.0-openjdk-aarch32 | CVE #(s): | |||||||||
| Created: | November 8, 2016 | Updated: | February 10, 2017 | ||||||||
| Description: | From the Oracle advisory:
This Critical Patch Update contains 7 new security fixes for Oracle Java SE. All of these vulnerabilities may be remotely exploitable without authentication, i.e., may be exploited over a network without requiring user credentials. | ||||||||||
| Alerts: |
| ||||||||||
kernel: three vulnerabilities
| Package(s): | kernel | CVE #(s): | CVE-2015-8746 CVE-2015-8844 CVE-2016-3699 | ||||||||||||||||||||||||||||
| Created: | November 3, 2016 | Updated: | November 9, 2016 | ||||||||||||||||||||||||||||
| Description: | From the CVE entries:
fs/nfs/nfs4proc.c in the NFS client in the Linux kernel before 4.2.2 does not properly initialize memory for migration recovery operations, which allows remote NFS servers to cause a denial of service (NULL pointer dereference and panic) via crafted network traffic. (CVE-2015-8746) The signal implementation in the Linux kernel before 4.3.5 on powerpc platforms does not check for an MSR with both the S and T bits set, which allows local users to cause a denial of service (TM Bad Thing exception and panic) via a crafted application. (CVE-2015-8844) The Linux kernel, as used in Red Hat Enterprise Linux 7.2 and Red Hat Enterprise MRG 2 and when booted with UEFI Secure Boot enabled, allows local users to bypass intended Secure Boot restrictions and execute untrusted code by appending ACPI tables to the initrd. (CVE-2016-3699) | ||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||
kernel: two vulnerabilities
| Package(s): | kernel | CVE #(s): | CVE-2016-9084 CVE-2016-9083 | ||||||||||||||||||||||||||||||||||||||||
| Created: | November 8, 2016 | Updated: | November 9, 2016 | ||||||||||||||||||||||||||||||||||||||||
| Description: | From the Red Hat bugzilla:
CVE-2016-9084: The use of a kzalloc with an integer multiplication allowed an integer overflow condition to be reached in vfio_pci_intrs.c. CVE-2016-9083: The vfio driver allows direct user access to devices. The VFIO_DEVICE_SET_IRQS ioctl for vfio PCI devices has a state machine confusion bug where specifying VFIO_IRQ_SET_DATA_NONE along with another bit in VFIO_IRQ_SET_DATA_TYPE_MASK in hdr.flags allows integer overflow checks to be skipped for hdr.start/hdr.count. This might allow memory corruption later in vfio_pci_set_msi_trigger() with user access to an appropriate vfio device file, but it seems difficult to usefully exploit in practice. | ||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||
libreswan: denial of service
| Package(s): | libreswan | CVE #(s): | CVE-2016-5361 | ||||||||||||
| Created: | November 3, 2016 | Updated: | December 15, 2016 | ||||||||||||
| Description: | From the Red Hat advisory:
A traffic amplification flaw was found in the Internet Key Exchange version 1 (IKEv1) protocol. A remote attacker could use a libreswan server with IKEv1 enabled in a network traffic amplification denial of service attack against other hosts on the network by sending UDP packets with a spoofed source address to that server. | ||||||||||||||
| Alerts: |
| ||||||||||||||
libvirt: privilege escalation
| Package(s): | libvirt | CVE #(s): | CVE-2015-5160 | ||||||||||||
| Created: | November 3, 2016 | Updated: | November 11, 2016 | ||||||||||||
| Description: | From the Red Hat advisory:
It was found that the libvirt daemon, when using RBD (RADOS Block Device), leaked private credentials to the process list. A local attacker could use this flaw to perform certain privileged operations within the cluster. | ||||||||||||||
| Alerts: |
| ||||||||||||||
libwebp: integer overflows
| Package(s): | libwebp | CVE #(s): | CVE-2016-9085 | ||||||||||||||||||||
| Created: | November 4, 2016 | Updated: | January 24, 2017 | ||||||||||||||||||||
| Description: | From the Red Hat bugzilla:
Multiple integer overflows were found in libwebp library. | ||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||
libxslt: code execution
| Package(s): | libxslt | CVE #(s): | CVE-2016-4738 | ||||||||||||
| Created: | November 7, 2016 | Updated: | November 23, 2016 | ||||||||||||
| Description: | From the Debian advisory:
A heap overread bug was found in libxslt, which can cause arbitrary code execution or denial of service. | ||||||||||||||
| Alerts: |
| ||||||||||||||
mariadb: unspecified vulnerability
| Package(s): | mariadb mysql | CVE #(s): | CVE-2016-5630 | ||||||||||||||||||||||||||||
| Created: | November 9, 2016 | Updated: | November 9, 2016 | ||||||||||||||||||||||||||||
| Description: | From the CVE entry:
Unspecified vulnerability in Oracle MySQL 5.6.31 and earlier and 5.7.13 and earlier allows remote administrators to affect availability via vectors related to Server: InnoDB. | ||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||
nvidia-graphics-drivers-367: privilege escalation
| Package(s): | nvidia-graphics-drivers-367 | CVE #(s): | CVE-2016-7382 CVE-2016-7389 | ||||||||||||
| Created: | November 3, 2016 | Updated: | January 10, 2017 | ||||||||||||
| Description: | From the Ubuntu advisory:
It was discovered that the NVIDIA graphics drivers incorrectly sanitized user mode inputs. A local attacker could use this issue to possibly gain root privileges. | ||||||||||||||
| Alerts: |
| ||||||||||||||
openjpeg2: code execution
| Package(s): | openjpeg2 | CVE #(s): | CVE-2016-8332 | ||||||||||||||||||||||||
| Created: | November 3, 2016 | Updated: | November 9, 2016 | ||||||||||||||||||||||||
| Description: | From the CVE entry:
A buffer overflow in OpenJPEG 2.1.1 causes arbitrary code execution when parsing a crafted image. An exploitable code execution vulnerability exists in the jpeg2000 image file format parser as implemented in the OpenJpeg library. A specially crafted jpeg2000 file can cause an out of bound heap write resulting in heap corruption leading to arbitrary code execution. For a successful attack, the target user needs to open a malicious jpeg2000 file. The jpeg2000 image file format is mostly used for embedding images inside PDF documents and the OpenJpeg library is used by a number of popular PDF renderers making PDF documents a likely attack vector. | ||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||
oracle-jre-bin: unspecified vulnerability
| Package(s): | oracle-jre-bin | CVE #(s): | CVE-2016-5568 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | November 4, 2016 | Updated: | November 9, 2016 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the CVE entry:
Unspecified vulnerability in Oracle Java SE 6u121, 7u111, and 8u102 allows remote attackers to affect confidentiality, integrity, and availability via vectors related to AWT. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
pacemaker: privilege escalation
| Package(s): | pacemaker | CVE #(s): | CVE-2016-7035 | ||||||||||||||||||||||||||||||||||||||||
| Created: | November 3, 2016 | Updated: | December 15, 2016 | ||||||||||||||||||||||||||||||||||||||||
| Description: | From the Red Hat advisory:
An authorization flaw was found in Pacemaker, where it did not properly guard its IPC interface. An attacker with an unprivileged account on a Pacemaker node could use this flaw to, for example, force the Local Resource Manager daemon to execute a script as root and thereby gain root access on the machine. | ||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||
pacemaker: denial of service
| Package(s): | pacemaker | CVE #(s): | CVE-2016-7797 | ||||||||||||||||||||
| Created: | November 3, 2016 | Updated: | December 15, 2016 | ||||||||||||||||||||
| Description: | From the Red Hat advisory:
It was found that the connection between a pacemaker cluster and a pacemaker_remote node could be shut down using a new unauthenticated connection. A remote attacker could use this flaw to cause a denial of service. | ||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||
python-imaging: two vulnerabilities
| Package(s): | python-imaging | CVE #(s): | CVE-2016-9189 CVE-2016-9190 | ||||||||||||||||
| Created: | November 8, 2016 | Updated: | November 18, 2016 | ||||||||||||||||
| Description: | From the CVE entries:
Pillow before 3.3.2 allows context-dependent attackers to obtain sensitive information by using the "crafted image file" approach, related to an "Integer Overflow" issue affecting the Image.core.map_buffer in map.c component. (CVE-2016-9189) Pillow before 3.3.2 allows context-dependent attackers to execute arbitrary code by using the "crafted image file" approach, related to an "Insecure Sign Extension" issue affecting the ImagingNew in Storage.c component. (CVE-2016-9190) | ||||||||||||||||||
| Alerts: |
| ||||||||||||||||||
qemu: multiple vulnerabilities
| Package(s): | qemu | CVE #(s): | CVE-2016-9101 CVE-2016-9102 CVE-2016-9103 CVE-2016-9104 CVE-2016-9105 CVE-2016-9106 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | November 3, 2016 | Updated: | November 9, 2016 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Debian LTS advisory:
CVE-2016-9101: Quick Emulator(Qemu) built with the i8255x (PRO100) NIC emulation support is vulnerable to a memory leakage issue. It could occur while unplugging the device, and doing so repeatedly would result in leaking host memory affecting, other services on the host. A privileged user inside guest could use this flaw to cause a DoS on the host and/or potentially crash the Qemu process on the host. CVE-2016-9102 CVE-2016-9105 CVE-2016-9106: Quick Emulator(Qemu) built with the VirtFS, host directory sharing via Plan 9 File System(9pfs) support, is vulnerable to a several memory leakage issues. A privileged user inside guest could use this flaws to leak the host memory bytes resulting in DoS for other services. CVE-2016-9103: Quick Emulator(Qemu) built with the VirtFS, host directory sharing via Plan 9 File System(9pfs) support, is vulnerable to an information leakage issue. It could occur by accessing xattribute value before it's written to. A privileged user inside guest could use this flaw to leak host memory bytes. CVE-2016-9104: Quick Emulator(Qemu) built with the VirtFS, host directory sharing via Plan 9 File System(9pfs) support, is vulnerable to an integer overflow issue. It could occur by accessing xattributes values. A privileged user inside guest could use this flaw to crash the Qemu process instance resulting in DoS. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
resteasy-base: code execution
| Package(s): | resteasy-base | CVE #(s): | CVE-2016-7050 | ||||||||||||||||
| Created: | November 3, 2016 | Updated: | December 15, 2016 | ||||||||||||||||
| Description: | From the Red Hat advisory:
It was discovered that under certain conditions RESTEasy could be forced to parse a request with SerializableProvider, resulting in deserialization of potentially untrusted data. An attacker could possibly use this flaw to execute arbitrary code with the permissions of the application using RESTEasy. | ||||||||||||||||||
| Alerts: |
| ||||||||||||||||||
spip: multiple vulnerabilities
| Package(s): | spip | CVE #(s): | CVE-2016-7980 CVE-2016-7981 CVE-2016-7982 CVE-2016-7998 CVE-2016-7999 | ||||
| Created: | November 3, 2016 | Updated: | November 9, 2016 | ||||
| Description: | From the Debian LTS advisory:
CVE-2016-7980: Nicolas Chatelain of Sysdream Labs discovered a cross-site request forgery (CSRF) vulnerability in the valider_xml action of SPIP. This allows remote attackers to make use of potential additional vulnerabilities such as the one described in CVE-2016-7998. CVE-2016-7981: Nicolas Chatelain of Sysdream Labs discovered a reflected cross-site scripting attack (XSS) vulnerability in the validater_xml action of SPIP. An attacker could take advantage of this vulnerability to inject arbitrary code by tricking an administrator to open a malicious link. CVE-2016-7982: Nicolas Chatelain of Sysdream Labs discovered a file enumeration / path traversal attack in the the validator_xml action of SPIP. An attacker could use this to enumerate files in an arbitrary directory on the file system. CVE-2016-7998: Nicolas Chatelain of Sysdream Labs discovered a possible PHP code execution vulnerability in the template compiler/composer function of SPIP. In combination with the XSS and CSRF vulnerabilities described in this advisory, a remote attacker could take advantage of this to execute arbitrary PHP code on the server. CVE-2016-7999: Nicolas Chatelain of Sysdream Labs discovered a server side request forgery in the valider_xml action of SPIP. Attackers could take advantage of this vulnerability to send HTTP or FTP requests to remote servers that they don't have direct access to, possibly bypassing access controls such as a firewall. | ||||||
| Alerts: |
| ||||||
subscription-manager: information disclosure
| Package(s): | subscription-manager | CVE #(s): | CVE-2016-4455 | ||||||||
| Created: | November 3, 2016 | Updated: | January 10, 2017 | ||||||||
| Description: | From the Red Hat advisory:
It was found that subscription-manager set weak permissions on files in /var/lib/rhsm/, causing an information disclosure. A local, unprivileged user could use this flaw to access sensitive data that could potentially be used in a social engineering attack. | ||||||||||
| Alerts: |
| ||||||||||
sudo: information disclosure
| Package(s): | sudo | CVE #(s): | CVE-2016-7091 | ||||||||||||
| Created: | November 3, 2016 | Updated: | December 15, 2016 | ||||||||||||
| Description: | From the Red Hat advisory:
It was discovered that the default sudo configuration preserved the value of INPUTRC from the user's environment, which could lead to information disclosure. A local user with sudo access to a restricted program that uses readline could use this flaw to read content from specially formatted files with elevated privileges provided by sudo. | ||||||||||||||
| Alerts: |
| ||||||||||||||
tomcat: multiple vulnerabilities
| Package(s): | tomcat | CVE #(s): | CVE-2016-0762 CVE-2016-5018 CVE-2016-6794 CVE-2016-6796 CVE-2016-6797 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | November 7, 2016 | Updated: | November 23, 2016 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Mageia advisory:
The Realm implementations did not process the supplied password if the supplied user name did not exist. This made a timing attack possible to determine valid user names. Note that the default configuration includes the LockOutRealm which makes exploitation of this vulnerability harder (CVE-2016-0762). A malicious web application was able to bypass a configured SecurityManager via a Tomcat utility method that was accessible to web applications (CVE-2016-5018). When a SecurityManager is configured, a web application's ability to read system properties should be controlled by the SecurityManager. Tomcat's system property replacement feature for configuration files could be used by a malicious web application to bypass the SecurityManager and read system properties that should not be visible (CVE-2016-6794). A malicious web application was able to bypass a configured SecurityManager via manipulation of the configuration parameters for the JSP Servlet (CVE-2016-6796). The ResourceLinkFactory did not limit web application access to global JNDI resources to those resources explicitly linked to the web application. Therefore, it was possible for a web application to access any global JNDI resource whether an explicit ResourceLink had been configured or not (CVE-2016-6797). | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Page editor: Jake Edge
Next page:
Kernel development>>