| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Dell EMC PowerStore versions prior to 1.0.3.0.5.xxx contain a file permission Vulnerability. A locally authenticated attacker could potentially exploit this vulnerability, leading to the information disclosure of certain system directory. |
| Dell EMC PowerStore versions prior to 1.0.3.0.5.007 contain a Plain-Text Password Storage Vulnerability in PowerStore X & T environments. A locally authenticated attacker could potentially exploit this vulnerability, leading to the disclosure of certain user credentials. The attacker may be able to use the exposed credentials to access the vulnerable application with privileges of the compromised account. |
| Dell EMC PowerStore versions prior to 1.0.3.0.5.007 contain a Plain-Text Password Storage Vulnerability in PowerStore X & T environments. A locally authenticated attacker could potentially exploit this vulnerability, leading to the disclosure of certain user credentials. The attacker may be able to use the exposed credentials to access the vulnerable application with privileges of the compromised account. |
| Dell EMC PowerStore versions prior to 1.0.3.0.5.007 contain a Plain-Text Password Storage Vulnerability in PowerStore T environments. A locally authenticated attacker could potentially exploit this vulnerability, leading to the disclosure of certain user credentials. The attacker may be able to use the exposed credentials to access the vulnerable application with privileges of the compromised account. |
| Dell EMC PowerStore versions prior to 1.0.3.0.5.006 contain an OS Command Injection vulnerability in PowerStore X environment . A locally authenticated attacker could potentially exploit this vulnerability, leading to the execution of arbitrary OS command on the PowerStore underlying OS. Exploiting may lead to a system take over by an attacker. |
| Dell Wyse Management Suite versions prior to 3.1 contain an open redirect vulnerability. A remote unauthenticated attacker could potentially exploit this vulnerability to redirect application users to arbitrary web URLs by tricking the victim users to click on maliciously crafted links. The vulnerability could be used to conduct phishing attacks that cause users to unknowingly visit malicious sites. |
| Dell Wyse Management Suite versions prior to 3.1 contain a stored cross-site scripting vulnerability. A remote authenticated malicious user with low privileges could exploit this vulnerability to store malicious HTML or JavaScript code under the device tag. When victim users access the submitted data through their browsers, the malicious code gets executed by the web browser in the context of the vulnerable application. |
| Dell Wyse Management Suite versions prior to 3.1 contain a stored cross-site scripting vulnerability. A remote authenticated malicious user with high privileges could exploit this vulnerability to store malicious HTML or JavaScript code while creating the Enduser. When victim users access the submitted data through their browsers, the malicious code gets executed by the web browser in the context of the vulnerable application. |
| DELL EMC Avamar Server, versions 19.1, 19.2, 19.3, contain an OS Command Injection Vulnerability in Fitness Analyzer. A remote unauthenticated attacker could potentially exploit this vulnerability, leading to the execution of arbitrary OS commands on the application's underlying OS with high privileges. This vulnerability is considered critical as it can be leveraged to completely compromise the vulnerable application as well as the underlying operating system. Dell recommends customers to upgrade at the earliest opportunity. |
| Dell EMC Avamar Server, versions 19.1, 19.2, 19.3, contain a Path Traversal Vulnerability in PDM. A remote user could potentially exploit this vulnerability, to gain unauthorized write access to the arbitrary files stored on the server filesystem, causing deletion of arbitrary files. |
| DELL EMC Avamar Server, versions 19.1, 19.2, 19.3, contain a SQL Injection Vulnerability in Fitness Analyzer. A remote unauthenticated attacker could potentially exploit this vulnerability, leading to the execution of certain SQL commands on the application's backend database, causing unauthorized read and write access to application data. Exploitation may lead to leakage or deletion of sensitive backup data; hence the severity is Critical. Dell EMC recommends customers to upgrade at the earliest opportunity. |
| Dell Wyse ThinOS 8.6 and prior versions contain an insecure default configuration vulnerability. A remote unauthenticated attacker could potentially exploit this vulnerability to access the writable file and manipulate the configuration of any target specific station. |
| Dell Wyse ThinOS 8.6 and prior versions contain an insecure default configuration vulnerability. A remote unauthenticated attacker could potentially exploit this vulnerability to gain access to the sensitive information on the local network, leading to the potential compromise of impacted thin clients. |
| Dell EMC Unity, Unity XT, and UnityVSA versions prior to 5.0.4.0.5.012 contain a Denial of Service vulnerability on NAS Servers with NFS exports. A remote authenticated attacker could potentially exploit this vulnerability and cause Denial of Service (Storage Processor Panic) by sending specially crafted UDP requests. |
| Dell EMC Unity, Unity XT, and UnityVSA versions prior to 5.0.4.0.5.012 contains a plain-text password storage vulnerability. A user credentials (including the Unisphere admin privilege user) password is stored in a plain text in a system file. A local authenticated attacker with access to the system files may use the exposed password to gain access with the privileges of the compromised user. |
| An issue was discovered in Xen XAPI before 2020-12-15. Certain xenstore keys provide feedback from the guest, and are therefore watched by toolstack. Specifically, keys are watched by xenopsd, and data are forwarded via RPC through message-switch to xapi. The watching logic in xenopsd sends one RPC update containing all data, any time any single xenstore key is updated, and therefore has O(N^2) time complexity. Furthermore, message-switch retains recent (currently 128) RPC messages for diagnostic purposes, yielding O(M*N) space complexity. The quantity of memory a single guest can monopolise is bounded by xenstored quota, but the quota is fairly large. It is believed to be in excess of 1G per malicious guest. In practice, this manifests as a host denial of service, either through message-switch thrashing against swap, or OOMing entirely, depending on dom0's configuration. (There are no quotas in xenopsd to limit the quantity of keys that result in RPC traffic.) A buggy or malicious guest can cause unreasonable memory usage in dom0, resulting in a host denial of service. All versions of XAPI are vulnerable. Systems that are not using the XAPI toolstack are not vulnerable. |
| An issue was discovered in Xen through 4.14.x. Nodes in xenstore have an ownership. In oxenstored, a owner could give a node away. However, node ownership has quota implications. Any guest can run another guest out of quota, or create an unbounded number of nodes owned by dom0, thus running xenstored out of memory A malicious guest administrator can cause a denial of service against a specific guest or against the whole host. All systems using oxenstored are vulnerable. Building and using oxenstored is the default in the upstream Xen distribution, if the Ocaml compiler is available. Systems using C xenstored are not vulnerable. |
| An issue was discovered in Xen 4.6 through 4.14.x. When acting upon a guest XS_RESET_WATCHES request, not all tracking information is freed. A guest can cause unbounded memory usage in oxenstored. This can lead to a system-wide DoS. Only systems using the Ocaml Xenstored implementation are vulnerable. Systems using the C Xenstored implementation are not vulnerable. |
| An issue was discovered in Xen through 4.14.x. When a Xenstore watch fires, the xenstore client that registered the watch will receive a Xenstore message containing the path of the modified Xenstore entry that triggered the watch, and the tag that was specified when registering the watch. Any communication with xenstored is done via Xenstore messages, consisting of a message header and the payload. The payload length is limited to 4096 bytes. Any request to xenstored resulting in a response with a payload longer than 4096 bytes will result in an error. When registering a watch, the payload length limit applies to the combined length of the watched path and the specified tag. Because watches for a specific path are also triggered for all nodes below that path, the payload of a watch event message can be longer than the payload needed to register the watch. A malicious guest that registers a watch using a very large tag (i.e., with a registration operation payload length close to the 4096 byte limit) can cause the generation of watch events with a payload length larger than 4096 bytes, by writing to Xenstore entries below the watched path. This will result in an error condition in xenstored. This error can result in a NULL pointer dereference, leading to a crash of xenstored. A malicious guest administrator can cause xenstored to crash, leading to a denial of service. Following a xenstored crash, domains may continue to run, but management operations will be impossible. Only C xenstored is affected, oxenstored is not affected. |
| An issue was discovered in Xen through 4.14.x. Xenstored and guests communicate via a shared memory page using a specific protocol. When a guest violates this protocol, xenstored will drop the connection to that guest. Unfortunately, this is done by just removing the guest from xenstored's internal management, resulting in the same actions as if the guest had been destroyed, including sending an @releaseDomain event. @releaseDomain events do not say that the guest has been removed. All watchers of this event must look at the states of all guests to find the guest that has been removed. When an @releaseDomain is generated due to a domain xenstored protocol violation, because the guest is still running, the watchers will not react. Later, when the guest is actually destroyed, xenstored will no longer have it stored in its internal data base, so no further @releaseDomain event will be sent. This can lead to a zombie domain; memory mappings of that guest's memory will not be removed, due to the missing event. This zombie domain will be cleaned up only after another domain is destroyed, as that will trigger another @releaseDomain event. If the device model of the guest that violated the Xenstore protocol is running in a stub-domain, a use-after-free case could happen in xenstored, after having removed the guest from its internal data base, possibly resulting in a crash of xenstored. A malicious guest can block resources of the host for a period after its own death. Guests with a stub domain device model can eventually crash xenstored, resulting in a more serious denial of service (the prevention of any further domain management operations). Only the C variant of Xenstore is affected; the Ocaml variant is not affected. Only HVM guests with a stubdom device model can cause a serious DoS. |
