Security
State of the Kernel Self Protection Project
At the Linux Security Summit in Toronto, Kees Cook updated attendees on the Kernel Self Protection Project (KSPP), which was announced only nine months ago. KSPP is targeted at adding protections to the kernel to guard against kernel bugs so that those bugs can't lead to a kernel compromise. Progress has been made, but there is lots more to do.
"Security" is a somewhat loaded word, but for the context of the presentation, he is really talking about "self protection", he said. That goes beyond access control (e.g. SELinux), attack surface reduction (e.g. seccomp), bug fixing, protecting user space, and kernel integrity. It is proactive and does rely on kernel integrity, but it is more than that.
![[Kees Cook]](https://static.lwn.net/images/2016/lss-cook-sm.jpg "Kees Cook")
Why KSPP?
There are huge numbers of systems using Linux and the vast majority are running old software. Many will never get updates. As we move forward, we need devices protecting themselves because the lifetime of bugs in the field is much longer than even the long bug lifetimes in the kernel. Things will be getting worse with the "Internet of Things" (IoT); while users may replace phones every few years, a door lock or other IoT device may live for fifteen years or more.
Cook has seen a lot of blame shifting. Once a bug is fixed, it is seen as someone else's problem to get it rolled out. But even if every bug was found and fixes were magically sent to all affected devices, bugs live for a long time in the kernel.
In 2010, Jonathan Corbet looked at the lifetime of security flaws in the kernel and found that the average time between introduction and fix was roughly five years. Cook analyzed the Ubuntu bug tracker for the kernel from 2011 through 2016 and found much the same, though the two critical bugs in that time frame averaged 3.3 years between introduction and fix. He put up a graph of the lifetime of all of those bugs and another that focused on just the critical and high severity bugs (as can be seen in his slides [PDF]). Bugs are clearly living for quite some time in the kernel.
One question he gets a lot is: "isn't this all just theoretical?" If kernel developers are not finding the bugs, maybe others aren't either. But that is "demonstrably untrue", Cook said. Attackers are finding these bugs and they are better at it than the kernel community is. Most attackers do not publicly boast about the zero-day flaws they have found. The window of opportunity for exploiting these bugs is large and not at all theoretical.
Kernel developers are fighting bugs, of course, and finding and fixing them. But they are also accelerating the pace of bug introduction. Bugs exist whether they are known or not and an empty bug tracker does not imply there are no bugs. The bugs are there and kernel developers need to act like they are, he said. Whack-a-mole is not a solution long-term; the current bug finding and fixing should continue, but there needs to be more.
At this point, user space is becoming more difficult to attack, which is making the kernel's attack surface more appealing. Containers are also painting a large target on Linux. In addition, it is important to recognize that lives depend on Linux. That statement makes some people uncomfortable, he said, but kernel bugs have been weaponized by organizations like Hacking Team that sell them to governments that use them to target dissidents and activists.
There is some truth to the statement that security bugs are just normal bugs. "Your security bug may not be my security bug", he said. But kernel developers have little knowledge of what bugs attackers use. Those bugs might even be in code that is not upstream, such as a vendor driver. Self protection could make kernels safer, even for that non-upstream code.
Killing bugs and bug classes
So, killing particular bugs is good, but killing bug classes is much better. That can ensure that those kind of bugs can never occur again, even if they are in out-of-tree code. But it is impossible to kill all bug classes.
So, what is best is to kill off the exploitability of bugs. That needs to be done even if the features make development more difficult. So what is needed is eliminating exploitation targets and methods, as well as removing information leaks and anything else that assists attackers. There will be tradeoffs to maintainability and performance, but those need to be judged on their merits, not just avoided at all costs.
Typical exploits are not simply using one flaw; instead they tend to chain together multiple flaws. In order to do that, they need to know where the targets are, inject or build malicious code, and redirect execution to that code.
There is already a lot of code to do self protection available in grsecurity and PaX. There are also academic papers describing ways for kernels to protect themselves. So a lot of these protections don't need to be invented, they just need to get upstream. There is, he said, a large demand for these kinds of features to be added to the kernel.
To address that, he started KSPP in order to gather people interested in self-protection technologies to discuss, test, and document them. There are other people working on excellent technologies for the kernel to protect user space, but he wants to focus on the kernel protecting itself. Currently, there are around ten organizations and five individuals working on roughly twenty separate technologies. It is not a fast process and he intends to take it "slow and steady".
He listed a number of people that are "under the KSPP umbrella". It shows that there are a lot of people paying attention to these ideas, which he is "extremely grateful" for. It is nice to have a deep pool of people to help, he said.
There are numerous areas of interest to the project. His slides detail multiple bug classes, examples of exploits for the class, the relevant mitigations that have already gone into the kernel (which are highlighted in bold), and the work that is either currently being done or is planned for the future.
For example, there have been protections for stack overflows in the kernel for quite some time. 2.6.30 saw the addition of the GCC -fstack-protector flag, while -fstack-protector-strong was added for 3.14. For the future, Andy Lutomirski has been working on virtually mapped stacks that will allow for guard pages around the kernel stack for further protection.
Other classes he covered include integer over and underflow, heap overflow, format string injection, kernel pointer leaks, uninitialized variables, use after free, direct kernel overwrite, function pointer overwrite, user-space execution from the kernel, accessing user-space memory directly from the kernel, and return-oriented programming (ROP).
Progress
He then went through the kernel releases since KSPP was started and noted the protections that had been added in each. For 4.3, the "Privileged Access Never" (PAN) hardware memory protection feature was emulated for the ARM architecture. That helps protect the kernel from accessing user-space memory inappropriately. Ambient capabilities were added to make Linux capabilities behave as most programmers expected them to. In addition, seccomp support was added for PowerPC in 4.3.
The 4.4 kernel saw the addition of the x86_64 configuration option to allow kernels to be built without support for three legacy virtual system calls at fixed kernel addresses. That is a significant attack surface reduction, Cook said. In 4.5, the address-space layout randomization (ASLR) feature added a way for administrators to control the amount of entropy in the random base address. It is a notable user-space protection feature.
There were numerous protection features added to the 4.6 kernel. Most were adding protections to various types of memory for different architectures. Read-only data (RODATA) became the default for ARMv7+ and arm64, while its use became mandatory for x86. The basic infrastructure for marking data as read-only after initialization (__ro_after_init) was added. x86 got execute-only memory and arm64 got support for kernel ASLR (KASLR) on the text and module base addresses.
The MIPS architecture got KASLR support for text and modules in 4.7. In addition, the SLAB memory allocator got support for randomizing its free list. The extended BPF just-in-time (JIT) compiler added constant blinding, which helps prevent exploits from using the JIT code to accomplish its purposes.
In 4.8, Cook expects quite a few features to land. KASLR on x86_64 will be able to use the full range of physical memory and randomization of the kernel memory base address will be added. The SLUB allocator will get free-list randomization. The GCC plugin infrastructure will be added with some example plugins that do not have much security impact. But it will allow grabbing plugins from grsecurity/PaX and using them on the kernel. Hardened usercopy should also make the cut, as will the changes to put ptrace() handling before seccomp handling to avoid a loophole where ptrace() can be used to avoid the seccomp rules.
Looking into his crystal ball, Cook sees several features that seem likely for the 4.9 kernel. The latent_entropy GCC plugin, which will provide more entropy at startup time, is one. Another is the virtually allocated stack work mentioned earlier. Some linked-list hardening patches and PAN emulation for arm64 round out his list.
Challenges
The biggest challenge for the project is the culture on both the kernel and security sides. The kernel side is quite conservative. It took sixteen years (and five or six different developer's attempts) to get a simple, clean solution for symbolic link restrictions upstream. It is going to require kernel developers to pay more attention to these kinds of protections. But those trying to upstream these features need to have patience and understand how kernel development is done.
One of the challenges is explaining the rationale for a particular feature. In order to get it upstream, other developers will have to understand it. Code is not written for the kernel itself, it is written for the other kernel developers, Cook said, so it is critical to make it understandable to them.
As with most projects, people are needed for KSPP. Dedicated developers, testers, reviewers, backporters (to vendor kernels), and so on are all needed. When a set of patches is posted, having them be greeted with silence is the worst outcome. He encouraged those interested to get involved.
[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
The vulnerabilities in the Shadow Brokers data dump are definitely not NOBUS-level. They are run-of-the-mill vulnerabilities that anyone -- another government, cybercriminals, amateur hackers -- could discover, as evidenced by the fact that many of them were discovered between 2013, when the data was stolen, and this summer, when it was published. They are vulnerabilities in common systems used by people and companies all over the world.
So what are all these vulnerabilities doing in a secret stash of NSA code that was stolen in 2013? Assuming the Russians were the ones who did the stealing, how many US companies did they hack with these vulnerabilities? This is what the Vulnerabilities Equities Process is designed to prevent, and it has clearly failed.
Böck: Multiple vulnerabilities in RPM – and a rant
Hanno Böck performed some fuzz testing on the dpkg and RPM package managers and reported the results; it seems that one of the projects has been rather more responsive than the other in fixing these issues. "The development process of RPM seems to be totally chaotic, it's neither clear where one reports bugs nor where one gets the latest code and security bugs don't get fixed within a reasonable time. There's been some recent events that make me feel especially worried about this..." It seems that some of the maintenance issues with RPM may not have improved greatly since they were reported here ten years ago.
Apache OpenOffice CVE-2016-1513 hotfix released
LWN covered a memory corruption vulnerability (CVE-2016-1513) in Apache OpenOffice that was disclosed before a fix was available. Now a hotfix for the problem has been released. "The official Apache OpenOffice security bulletin was announced on July 21, 2016. Affected is Apache OpenOffice 4.1.2 and older on all platforms and all languages. OpenOffice.org versions are also affected. The Apache OpenOffice project recommends to update to the latest version 4.1.2 and then to download and install the Zip file from the table below. Please follow the installation instructions in the respective Readme file." (Thanks to Cesar Eduardo Barros)
New vulnerabilities
borgbackup: directory traversal
| Package(s): | borgbackup | CVE #(s): | |||||||||
| Created: | August 30, 2016 | Updated: | August 31, 2016 | ||||||||
| Description: | From the borgbackup changelog:
borg serve: fix security issue with remote repository access, #1428 If you used e.g. –restrict-to-path /path/client1/ (with or without trailing slash does not make a difference), it acted like a path prefix match using /path/client1 (note the missing trailing slash) - the code then also allowed working in e.g. /path/client13 or /path/client1000. As this could accidentally lead to major security/privacy issues depending on the pathes you use, the behaviour was changed to be a strict directory match. That means –restrict-to-path /path/client1 (with or without trailing slash does not make a difference) now uses /path/client1/ internally (note the trailing slash here!) for matching and allows precisely that path AND any path below it. So, /path/client1 is allowed, /path/client1/repo1 is allowed, but not /path/client13 or /path/client1000. If you willingly used the undocumented (dangerous) previous behaviour, you may need to rearrange your –restrict-to-path pathes now. We are sorry if that causes work for you, but we did not want a potentially dangerous behaviour in the software (not even using a for-backwards-compat option). | ||||||||||
| Alerts: |
| ||||||||||
freeipa: denial of service
| Package(s): | freeipa | CVE #(s): | CVE-2016-5404 | ||||||||||||||||||||||||||||||||
| Created: | August 30, 2016 | Updated: | September 6, 2016 | ||||||||||||||||||||||||||||||||
| Description: | From the Red Hat bugzilla:
Summary: a user with 'retrieve certificate' permission can revoke any certificate. The 'revoke certificate' permission is not required. Detail: the 'cert_revoke' command does check for the 'revoke certificate' permission, however, if an access error is raised, it then invokes the 'cert_show' command. The rational was to re-use a "self-service" check that is part of the 'cert_show' command, however, it is sufficient that 'cert_show' execute successfully for 'cert_revoke' to recover from the access error and continue. Therefore, anyone with 'retrieve certificate' permission can revoke *any* certificate. Impact: anyone with 'retrieve certificate' permission can cause various kinds of DoS by revoking any cert they want. | ||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||
mediawiki: multiple vulnerabilities
| Package(s): | mediawiki | CVE #(s): | CVE-2016-6331 CVE-2016-6332 CVE-2016-6333 CVE-2016-6334 CVE-2016-6335 CVE-2016-6336 CVE-2016-6337 | ||||||||||||||||
| Created: | August 26, 2016 | Updated: | September 16, 2016 | ||||||||||||||||
| Description: | From the Arch Linux advisory:
- CVE-2016-6331 (permission bypass): Check read permission when loading page content in ApiParse. Prevents leaking page contents for extensions that deny read rights to certain pages via a userCan hook, but still allow the user to have read rights in general. - CVE-2016-6332 (permission bypass): Make $wgBlockDisablesLogin also restrict logged in permissions. Does both Title and user related methods, so it catches things that only call $wgUser->isAllowed( 'read' ), as well as giving a nicer error message for things that use $title->userCan(). Otherwise, the user can still do stuff and read pages if they have an ongoing session. - CVE-2016-6333 (cross-site scripting): Escape '<' and ']]>' in inline <style> blocks. This is to prevent people from closing the <style> tag, and then doing arbitrary js-y things. In particular, this is needed for when previewing user css pages. This does not escape '>' since its used as the child selector in css, and generally speaking, '>' is safe inside the contents of elements. - CVE-2016-6334 (cross-site scripting): rawurldecode was being run on unclosed internal links which could allow an attacker to insert arbitrary html into the page. - CVE-2016-6335 (information disclosure): API: Generate head items in the context of the given title. $context->getOutput() returns an OutputPage tied to the main RequestContext at the root of the chain, not to the modified context we're actually using. - CVE-2016-6336 (permission bypass): Do not allow undeleting a revision deleted file if it is the top file. This prevents admins being able to view suppressed files, by simply deleting them, and then undeleting only the file revision that they want to view. - CVE-2016-6337 (permission bypass): Move 'UserGetRights' call before application of Session::getAllowedUserRights(). This prevents hook functions from accidentally adding rights that should be denied based on the session grants. If some extension really needs to be able to override session grants, add a new hook where the old call was, with documentation explicitly warning about the security implications. | ||||||||||||||||||
| Alerts: |
| ||||||||||||||||||
openvpn: information disclosure
| Package(s): | openvpn | CVE #(s): | CVE-2016-6329 | ||||||||||||||||
| Created: | August 26, 2016 | Updated: | November 1, 2016 | ||||||||||||||||
| Description: | From the Red Hat bugzilla:
Ciphers with 64-bit block sizes used in CBC mode were found to be vulnerable to birthday attack when key renegotiation doesn't happen frequently or at all in long running connections. Blowfish cipher as used in OpenVPN by default is vulnerable to this attack, that allows remote attacker to recover partial plaintext information (XOR of two plaintext blocks). | ||||||||||||||||||
| Alerts: |
| ||||||||||||||||||
php: multiple vulnerabilities
| Package(s): | php | CVE #(s): | CVE-2016-7124 CVE-2016-7125 CVE-2016-7126 CVE-2016-7127 CVE-2016-7128 CVE-2016-7129 CVE-2016-7130 CVE-2016-7131 CVE-2016-7132 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | August 31, 2016 | Updated: | September 6, 2016 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | PHP 5.6.25 fixes many issues. See the changelog for details.
See the CVE assignments for more information. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
phpMyAdmin: multiple vulnerabilities
| Package(s): | phpMyAdmin | CVE #(s): | CVE-2016-6606 CVE-2016-6607 CVE-2016-6608 CVE-2016-6609 CVE-2016-6610 CVE-2016-6611 CVE-2016-6612 CVE-2016-6613 CVE-2016-6614 CVE-2016-6615 CVE-2016-6616 CVE-2016-6617 CVE-2016-6618 CVE-2016-6619 CVE-2016-6620 CVE-2016-6621 CVE-2016-6622 CVE-2016-6623 CVE-2016-6624 CVE-2016-6625 CVE-2016-6626 CVE-2016-6627 CVE-2016-6628 CVE-2016-6629 CVE-2016-6630 CVE-2016-6631 CVE-2016-6632 CVE-2016-6633 | ||||||||||||||||||||||||||||||||||||||||
| Created: | August 29, 2016 | Updated: | February 6, 2017 | ||||||||||||||||||||||||||||||||||||||||
| Description: | From the openSUSE advisory:
* Weaknesses with cookie encryption see PMASA-2016-29 (CVE-2016-6606, CWE-661) * Multiple XSS vulnerabilities see PMASA-2016-30 (CVE-2016-6607, CWE-661) * Multiple XSS vulnerabilities see PMASA-2016-31 (CVE-2016-6608, CWE-661) * PHP code injection see PMASA-2016-32 (CVE-2016-6609, CWE-661) * Full path disclosure see PMASA-2016-33 (CVE-2016-6610, CWE-661) * SQL injection attack see PMASA-2016-34 (CVE-2016-6611, CWE-661) * Local file exposure through LOAD DATA LOCAL INFILE see PMASA-2016-35 (CVE-2016-6612, CWE-661) * Local file exposure through symlinks with UploadDir see PMASA-2016-36 (CVE-2016-6613, CWE-661) * Path traversal with SaveDir and UploadDir see PMASA-2016-37 (CVE-2016-6614, CWE-661) * Multiple XSS vulnerabilities see PMASA-2016-38 (CVE-2016-6615, CWE-661) * SQL injection vulnerability as control user see PMASA-2016-39 (CVE-2016-6616, CWE-661) * SQL injection vulnerability see PMASA-2016-40 (CVE-2016-6617, CWE-661) * Denial-of-service attack through transformation feature see PMASA-2016-41 (CVE-2016-6618, CWE-661) * SQL injection vulnerability as control user see PMASA-2016-42 (CVE-2016-6619, CWE-661) * Verify data before unserializing see PMASA-2016-43 (CVE-2016-6620, CWE-661) * SSRF in setup script see PMASA-2016-44 (CVE-2016-6621, CWE-661) * Denial-of-service attack with $cfg['AllowArbitraryServer'] = true and persistent connections see PMASA-2016-45 (CVE-2016-6622, CWE-661) * Denial-of-service attack by using for loops see PMASA-2016-46 (CVE-2016-6623, CWE-661) * Possible circumvention of IP-based allow/deny rules with IPv6 and proxy server see PMASA-2016-47 (CVE-2016-6624, CWE-661) * Detect if user is logged in see PMASA-2016-48 (CVE-2016-6625, CWE-661) * Bypass URL redirection protection see PMASA-2016-49 (CVE-2016-6626, CWE-661) * Referrer leak see PMASA-2016-50 (CVE-2016-6627, CWE-661) * Reflected File Download see PMASA-2016-51 (CVE-2016-6628, CWE-661) * ArbitraryServerRegexp bypass see PMASA-2016-52 (CVE-2016-6629, CWE-661) * Denial-of-service attack by entering long password see PMASA-2016-53 (CVE-2016-6630, CWE-661) * Remote code execution vulnerability when running as CGI see PMASA-2016-54 (CVE-2016-6631, CWE-661) * Denial-of-service attack when PHP uses dbase extension see PMASA-2016-55 (CVE-2016-6632, CWE-661) * Remove code execution vulnerability when PHP uses dbase extension see PMASA-2016-56 (CVE-2016-6633, CWE-661) | ||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||
quagga: information disclosure
| Package(s): | quagga | CVE #(s): | CVE-2016-4036 | ||||||||||||
| Created: | August 26, 2016 | Updated: | August 31, 2016 | ||||||||||||
| Description: | From the Debian advisory:
Tamás Németh discovered that sensitive configuration files in /etc/quagga were world-readable despite containing sensitive information. | ||||||||||||||
| Alerts: |
| ||||||||||||||
rails: cross-site scripting
| Package(s): | rails | CVE #(s): | CVE-2016-6316 | ||||||||||||||||||||||||||||||||
| Created: | August 26, 2016 | Updated: | September 13, 2016 | ||||||||||||||||||||||||||||||||
| Description: | From the Debian advisory:
Andrew Carpenter of Critical Juncture discovered a cross-site scripting vulnerability affecting Action View in rails, a web application framework written in Ruby. Text declared as "HTML safe" will not have quotes escaped when used as attribute values in tag helpers. | ||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||
rubygem-actionpack: unsafe query generation
| Package(s): | rubygem-actionpack | CVE #(s): | CVE-2016-6317 | ||||||||||||||||||||
| Created: | August 30, 2016 | Updated: | August 31, 2016 | ||||||||||||||||||||
| Description: | From the Red Hat bugzilla:
Due to the way Active Record interprets parameters in combination with the way that JSON parameters are parsed, it is possible for an attacker to issue unexpected database queries with "IS NULL" or empty where clauses. This issue does *not* let an attacker insert arbitrary values into an SQL query, however they can cause the query to check for NULL or eliminate a WHERE clause when most users wouldn't expect it. | ||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||
tiff: multiple vulnerabilities
| Package(s): | tiff | CVE #(s): | CVE-2016-5315 CVE-2016-5321 CVE-2016-5322 CVE-2016-5323 | ||||||||||||||||||||||||||||||||||||
| Created: | August 31, 2016 | Updated: | August 31, 2016 | ||||||||||||||||||||||||||||||||||||
| Description: | From the Debian LTS advisory:
Several vulnerabilities were found in the tiff library, potentially causing denial of services to applications using it. | ||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||
tryton-server: two vulnerabilities
| Package(s): | tryton-server | CVE #(s): | CVE-2016-1241 CVE-2016-1242 | ||||||||
| Created: | August 31, 2016 | Updated: | January 2, 2017 | ||||||||
| Description: | From the Debian advisory:
Two vulnerabilities have been discovered in the server for the Tryton application platform, which may result in information disclosure of password hashes or file contents. | ||||||||||
| Alerts: |
| ||||||||||
typo3-cms-4_5: two vulnerabilities
| Package(s): | typo3-cms-4_5 | CVE #(s): | CVE-2014-9508 CVE-2015-2047 | ||||
| Created: | August 29, 2016 | Updated: | August 31, 2016 | ||||
| Description: | From the CVE entries:
The frontend rendering component in TYPO3 4.5.x before 4.5.39, 4.6.x through 6.2.x before 6.2.9, and 7.x before 7.0.2, when config.prefixLocalAnchors is set and using a homepage with links that only contain anchors, allows remote attackers to change URLs to arbitrary domains for those links via unknown vectors. (CVE-2014-9508) The rsaauth extension in TYPO3 4.3.0 through 4.3.14, 4.4.0 through 4.4.15, 4.5.0 through 4.5.39, and 4.6.0 through 4.6.18, when configured for the frontend, allows remote attackers to bypass authentication via a password that is casted to an empty value. (CVE-2015-2047) | ||||||
| Alerts: |
| ||||||
webkitgtk4: multiple vulnerabilities
| Package(s): | webkitgtk4 | CVE #(s): | CVE-2016-4622 CVE-2016-4624 CVE-2016-4591 CVE-2016-4590 | ||||||||||||||||||||
| Created: | August 29, 2016 | Updated: | September 1, 2016 | ||||||||||||||||||||
| Description: | From the CVE entries:
WebKit in Apple iOS before 9.3.3, Safari before 9.1.2, and tvOS before 9.2.2 allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted web site, a different vulnerability than CVE-2016-4589, CVE-2016-4623, and CVE-2016-4624. (CVE-2016-4622) WebKit in Apple iOS before 9.3.3, Safari before 9.1.2, and tvOS before 9.2.2 allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted web site, a different vulnerability than CVE-2016-4589, CVE-2016-4622, and CVE-2016-4623. (CVE-2016-4624) WebKit in Apple iOS before 9.3.3, Safari before 9.1.2, and tvOS before 9.2.2 mishandles the location variable, which allows remote attackers to access the local filesystem via unspecified vectors. (CVE-2016-4591) WebKit in Apple iOS before 9.3.3 and Safari before 9.1.2 mishandles about: URLs, which allows remote attackers to bypass the Same Origin Policy via a crafted web site. (CVE-2016-4590) | ||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||
Page editor: Jake Edge
Next page:
Kernel development>>