The vulnerability is caused due to the usage of vulnerable collection of libraries that are part of DCMTK Toolkit, specifically the parser for the DICOM Upper Layer Protocol or DUL. Stack/Heap Buffer overflow/underflow can be triggered when sending and processing wrong length of ACSE data structure received over the network by the DICOM Store-SCP service. An attacker can overflow the stack and the heap of the process when sending large array of bytes to the presentation context item length segment of the DICOM standard, potentially resulting in remote code execution and/or denial of service scenario.
The vulnerability is caused due to the usage of vulnerable collection of libraries that are part of DCMTK Toolkit, specifically the parser for the DICOM Upper Layer Protocol or DUL. Stack/Heap Buffer overflow/underflow can be triggered when sending and processing wrong length of ACSE data structure received over the network by the DICOM Store-SCP service. An attacker can overflow the stack and the heap of the process when sending large array of bytes to the presentation context item length segment of the DICOM standard, potentially resulting in remote code execution and/or denial of service scenario.
This PoC exploit allows privilege escalation from 'nagios' system account, or an account belonging to 'nagios' group, to root (root shell). Attackers could obtain such an account via exploiting another vulnerability, e.g. CVE-2016-9565 linked below.
A specially crafted web-page can trigger a use-after-free vulnerability in Microsoft Internet Explorer 9. During a method call, the this object can be freed and then continues to be used by the code that implements the method. An attacker would need to get a target user to open a specially crafted web-page. Disabling JavaScript should prevent an attacker from triggering the vulnerable code path. By switching the a document's designMode property to on in a deferred script, MSIE 9 can be made to reload a web page using CMarkup::ReloadInCompatView. This method calls CDoc::CompatViewRefresh, which indirectly calls CScriptCollection::~CScriptCollection, which releases the CMarkup object used as this in CMarkup::ReloadInCompatView. Immediately after returning to CMarkup::ReloadInCompatView, the code will use the (now freed) CMarkup object. I did not immediately find a way to control the free memory, so I decided to look for a way to use the freed memory. I noticed that the freed CMarkup object was immediately followed by a CMarkupPointer object. This object contains a pointer to a CMarkup object, which is still valid. By overwriting the pointer in the CMarkupPointer object, I was able to control the CMarkup object that was used after the free.
This PoC exploit can allow well-positioned attackers to extract and write arbitrary files on the Nagios server which can lead to arbitrary code execution on Nagios deployments that follow the official Nagios installation guidelines.
When apt-get updates a repository that uses an InRelease file (clearsigned Release files), this file is processed as follows: First, the InRelease file is downloaded to disk. In a subprocess running the gpgv helper, 'apt-key verify' (with some more arguments) is executed through the following callchain. ExecGPGV() splits the clearsigned file into payload and signature using SplitClearSignedFile(), calls apt-key on these two files to perform the cryptographic signature verification, then discards the split files and only retains the clearsigned original. SplitClearSignedFile() ignores leading and trailing garbage. Afterwards, in the parent process, the InRelease file has to be loaded again so that its payload can be processed. At this point, the code isn't aware anymore whether the Release file was clearsigned or split-signed, so the file is opened using OpenMaybeClearSignedFile(), which first attempts to parse the file as a clearsigned (InRelease) file and extract the payload, then falls back to treating the file as the file as a split-signed (Release) file if the file format couldn't be recognized. The weakness here is: If an attacker can create an InRelease file that is parsed as a proper split-signed file during signature validation, but then isn't recognized by OpenMaybeClearSignedFile(), the 'leading garbage' that was ignored by the signature validation is interpreted as repository metadata, bypassing the signing scheme. It first looks as if it would be impossible to create a file that is recognized as split-signed by ExecGPGV(), but isn't recognized by OpenMaybeClearSignedFile(), because both use the same function, SplitClearSignedFile(), for parsing the file. However, multiple executions of SplitClearSignedFile() on the same data can actually have different no results, depending on the data.
Adobe Animate suffers from a Buffer Overflow when creating .FLA files with ActionScript Classes that use overly long Class names. This causes memory corruption leading to possible arbitrary code execution upon opening a maliciously created .Fla Flash file.
As a part of the KNOX extensions available on Samsung devices, Samsung provides a TrustZone trustlet which allows the generation of OTP tokens. The tokens themselves are generated in a TrustZone application within the TEE (UID: fffffffff0000000000000000000001e), which can be communicated with using the 'OTP' service, published by 'otp_server'. Many of the internal commands supported by the trustlet must either unwrap or wrap a token. They do so by calling the functions 'otp_unwrap' and 'otp_wrap', correspondingly. Both functions copy the internal token data to a local stack based buffer before attempting to wrap or unwrap it. However, this copy operation is performed using a length field supplied in the user's buffer (the length field's offset changes according to the calling code-path), which is not validated at all. This means an attacker can supply a length field larger than the stack based buffer, causing the user-controlled token data to overflow the stack buffer. There is no stack cookie mitigation in MobiCore trustlets. On the device I'm working on (SM-G925V), the 'OTP' service can be accessed from any user, including from the SELinux context 'untrusted_app'. Successfully exploiting this vulnerability should allow a user to elevate privileges to the TrustZone TEE.
The OTP service provided by Samsung devices allows a client to provide a buffer from the Non-secure World (NWD) to be sent to the Secure-World (SW). However, the service does not validate the request length field at all, allowing an attacker to specify any value. This length field is then used in a 'memcpy' call in order to copy the data from the parcel to an internal heap-allocated buffer, resulting in a buffer overflow vulnerability.
This vulnerability allows a remote attacker to test for the existence of files on the target system without authentication.
Services By CQR