Security Vulnerabilities
- CVEs Published In 2020
Parameter psClass in ednareporting.asmx is vulnerable to unauthenticated SQL injection attacks. Specially crafted SOAP web requests can cause SQL injections resulting in data compromise. An attacker can send unauthenticated HTTP requests to trigger this vulnerability.
The login page in Telmat AccessLog <= 6.0 (TAL_20180415) allows an attacker to get root shell access via Unauthenticated code injection over the network.
The ping page of the administration panel in Telmat AccessLog <= 6.0 (TAL_20180415) allows an attacker to get root shell access via authenticated code injection over the network.
Untis WebUntis before 2020.9.6 allows XSS in multiple functions that store information.
Check Point Security Management's Internal CA web management before Jumbo HFAs R80.10 Take 278, R80.20 Take 160, R80.30 Take 210, and R80.40 Take 38, can be manipulated to run commands as a high privileged user or crash, due to weak input validation on inputs by a trusted management administrator.
The client API authentication mechanism in Pexip Infinity before 10 allows remote attackers to gain privileges via a crafted request.
An incomplete SSL server certification validation vulnerability in the Trend Micro Security 2019 (v15) consumer family of products could allow an attacker to combine this vulnerability with another attack to trick an affected client into downloading a malicious update instead of the expected one. CWE-494: Update files are not properly verified.
An incomplete SSL server certification validation vulnerability in the Trend Micro Security 2019 (v15) consumer family of products could allow an attacker to combine this vulnerability with another attack to trick an affected client into downloading a malicious update instead of the expected one. CWE-295: Improper server certificate verification in the communication with the update server.
An issue was discovered in Xen through 4.14.x. x86 PV guest kernels can experience denial of service via SYSENTER. The SYSENTER instruction leaves various state sanitization activities to software. One of Xen's sanitization paths injects a #GP fault, and incorrectly delivers it twice to the guest. This causes the guest kernel to observe a kernel-privilege #GP fault (typically fatal) rather than a user-privilege #GP fault (usually converted into SIGSEGV/etc.). Malicious or buggy userspace can crash the guest kernel, resulting in a VM Denial of Service. All versions of Xen from 3.2 onwards are vulnerable. Only x86 systems are vulnerable. ARM platforms are not vulnerable. Only x86 systems that support the SYSENTER instruction in 64bit mode are vulnerable. This is believed to be Intel, Centaur, and Shanghai CPUs. AMD and Hygon CPUs are not believed to be vulnerable. Only x86 PV guests can exploit the vulnerability. x86 PVH / HVM guests cannot exploit the vulnerability.
An issue was discovered in Xen through 4.14.x. There is mishandling of the constraint that once-valid event channels may not turn invalid. Logic in the handling of event channel operations in Xen assumes that an event channel, once valid, will not become invalid over the life time of a guest. However, operations like the resetting of all event channels may involve decreasing one of the bounds checked when determining validity. This may lead to bug checks triggering, crashing the host. An unprivileged guest may be able to crash Xen, leading to a Denial of Service (DoS) for the entire system. All Xen versions from 4.4 onwards are vulnerable. Xen versions 4.3 and earlier are not vulnerable. Only systems with untrusted guests permitted to create more than the default number of event channels are vulnerable. This number depends on the architecture and type of guest. For 32-bit x86 PV guests, this is 1023; for 64-bit x86 PV guests, and for all ARM guests, this number is 4095. Systems where untrusted guests are limited to fewer than this number are not vulnerable. Note that xl and libxl limit max_event_channels to 1023 by default, so systems using exclusively xl, libvirt+libxl, or their own toolstack based on libxl, and not explicitly setting max_event_channels, are not vulnerable.