| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| The Linux kernel version 3.3-rc1 and later is affected by a vulnerability lies in the processing of incoming L2CAP commands - ConfigRequest, and ConfigResponse messages. This info leak is a result of uninitialized stack variables that may be returned to an attacker in their uninitialized state. By manipulating the code flows that precede the handling of these configuration messages, an attacker can also gain some control over which data will be held in the uninitialized stack variables. This can allow him to bypass KASLR, and stack canaries protection - as both pointers and stack canaries may be leaked in this manner. Combining this vulnerability (for example) with the previously disclosed RCE vulnerability in L2CAP configuration parsing (CVE-2017-1000251) may allow an attacker to exploit the RCE against kernels which were built with the above mitigations. These are the specifics of this vulnerability: In the function l2cap_parse_conf_rsp and in the function l2cap_parse_conf_req the following variable is declared without initialization: struct l2cap_conf_efs efs; In addition, when parsing input configuration parameters in both of these functions, the switch case for handling EFS elements may skip the memcpy call that will write to the efs variable: ... case L2CAP_CONF_EFS: if (olen == sizeof(efs)) memcpy(&efs, (void *)val, olen); ... The olen in the above if is attacker controlled, and regardless of that if, in both of these functions the efs variable would eventually be added to the outgoing configuration request that is being built: l2cap_add_conf_opt(&ptr, L2CAP_CONF_EFS, sizeof(efs), (unsigned long) &efs); So by sending a configuration request, or response, that contains an L2CAP_CONF_EFS element, but with an element length that is not sizeof(efs) - the memcpy to the uninitialized efs variable can be avoided, and the uninitialized variable would be returned to the attacker (16 bytes). |
| The Erlang otp TLS server answers with different TLS alerts to different error types in the RSA PKCS #1 1.5 padding. This allows an attacker to decrypt content or sign messages with the server's private key (this is a variation of the Bleichenbacher attack). |
| sound/core/timer.c in the Linux kernel before 4.11.5 is vulnerable to a data race in the ALSA /dev/snd/timer driver resulting in local users being able to read information belonging to other users, i.e., uninitialized memory contents may be disclosed when a read and an ioctl happen at the same time. |
| An information disclosure vulnerability in the Android media framework (libstagefright). Product: Android. Versions: 7.0, 7.1.1, 7.1.2. Android ID: A-64836941. |
| In Apache Struts 2.3.7 through 2.3.33 and 2.5 through 2.5.12, if an application allows entering a URL in a form field and built-in URLValidator is used, it is possible to prepare a special URL which will be used to overload server process when performing validation of the URL. NOTE: this vulnerability exists because of an incomplete fix for S2-047 / CVE-2017-7672. |
| A remote code execution vulnerability exists when Windows Hyper-V Network Switch running on a host server fails to properly validate input from an authenticated user on a guest operating system, aka "Hyper-V Remote Code Execution Vulnerability." This CVE ID is unique from CVE-2017-0162, CVE-2017-0163, and CVE-2017-0181. |
| A remote code execution vulnerability exists when Windows Hyper-V Network Switch running on a Windows 10 or Windows Server 2016 host server fails to properly validate input from an authenticated user on a guest operating system, aka "Hyper-V Remote Code Execution Vulnerability." This CVE ID is unique from CVE-2017-0162, CVE-2017-0163, and CVE-2017-0180. |
| An information disclosure vulnerability in the Android system (rild). Product: Android. Versions: 4.4.4, 5.0.2, 5.1.1, 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2. Android ID: A-37896655. |
| An information disclosure vulnerability in the Android media framework (libeffects). Product: Android. Versions: 4.4.4, 5.0.2, 5.1.1, 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2, 8.0. Android ID: A-63526567. |
| The kernel-mode drivers in Windows Server 2008 SP2 and R2 SP1, Windows 7 SP1 and Windows Server 2012 Gold allow a local authenticated attacker to execute a specially crafted application to obtain kernel information, aka "Win32k Information Disclosure Vulnerability." |
| When a cluster is operating in secure mode, a user with read privileges for specific data regions can use the gfsh command line utility to execute queries. In Apache Geode before 1.2.1, the query results may contain data from another user's concurrently executing gfsh query, potentially revealing data that the user is not authorized to view. |
| A remote code execution vulnerability in the Android media framework. Product: Android. Versions: 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2. Android ID: A-34231163. |
| A elevation of privilege vulnerability in the Android framework. Product: Android. Versions: 5.0.2, 5.1.1, 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2. Android ID: A-37478824. |
| A remote code execution vulnerability in the Android media framework (libmpeg2). Product: Android. Versions: 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2. Android ID: A-37561455. |
| An information disclosure vulnerability in the MediaTek command queue driver could enable a local malicious application to access data outside of its permission levels. This issue is rated as High because it could be used to access sensitive data without explicit user permission. Product: Android. Versions: N/A. Android ID: A-35142799. References: M-ALPS03161531. |
| An information disclosure vulnerability in the Qualcomm Wi-Fi driver could enable a local malicious application to access data outside of its permission levels. This issue is rated as High because it could be used to access sensitive data without explicit user permission. Product: Android. Versions: Kernel-3.10, Kernel-3.18. Android ID: A-34327795. References: QC-CR#2005832. |
| An elevation of privilege vulnerability in the Qualcomm Secure Channel Manager driver could enable a local malicious application to execute arbitrary code within the context of the kernel. This issue is rated as High because it first requires compromising a privileged process. Product: Android. Versions: Kernel-3.10, Kernel-3.18. Android ID: A-35401052. References: QC-CR#1081711. |
| An Improper Input Validation issue was discovered in ABB FOX515T release 1.0. An improper input validation vulnerability has been identified, allowing a local attacker to provide a malicious parameter to the script that is not validated by the application, This could enable the attacker to retrieve any file on the server. |
| All versions of the NVIDIA Windows GPU Display Driver contain a vulnerability in the kernel mode layer handler for DxgkDdiEscape where it may access paged memory while holding a spinlock, leading to a denial of service. |
| In res/res_rtp_asterisk.c in Asterisk 11.x before 11.25.2, 13.x before 13.17.1, and 14.x before 14.6.1 and Certified Asterisk 11.x before 11.6-cert17 and 13.x before 13.13-cert5, unauthorized data disclosure (media takeover in the RTP stack) is possible with careful timing by an attacker. The "strictrtp" option in rtp.conf enables a feature of the RTP stack that learns the source address of media for a session and drops any packets that do not originate from the expected address. This option is enabled by default in Asterisk 11 and above. The "nat" and "rtp_symmetric" options (for chan_sip and chan_pjsip, respectively) enable symmetric RTP support in the RTP stack. This uses the source address of incoming media as the target address of any sent media. This option is not enabled by default, but is commonly enabled to handle devices behind NAT. A change was made to the strict RTP support in the RTP stack to better tolerate late media when a reinvite occurs. When combined with the symmetric RTP support, this introduced an avenue where media could be hijacked. Instead of only learning a new address when expected, the new code allowed a new source address to be learned at all times. If a flood of RTP traffic was received, the strict RTP support would allow the new address to provide media, and (with symmetric RTP enabled) outgoing traffic would be sent to this new address, allowing the media to be hijacked. Provided the attacker continued to send traffic, they would continue to receive traffic as well. |
