Private Tunnel VPN Client 2.8 is vulnerable to a local buffer overflow vulnerability. An attacker can exploit this vulnerability by running the exploit, copying the contents of poc.txt, pasting it in the password field and pressing Login.
Easy MOV Converter is vulnerable to a SEH overwrite vulnerability. By entering a specially crafted string of 1000+ characters into the 'Enter User Name' field, an attacker can overwrite the SEH handler and gain control of the program flow.
The process hardening implemented by the VirtualBox driver can be circumvented to load arbitrary code inside a VirtualBox process giving access to the VBoxDrv driver which can allow routes to EoP from a normal user. VirtualBox uses a number of different techniques to prevent untrusted code accessing the core system drivers. This is because most of VB runs as a non-admin user but the driver provides a number of privileged features such as allocating kernel memory and loading drivers. This process hardening is implemented in both the kernel driver (which prevents things like getting fully privileged handles to a VB process) and in user mode by hooking the library loader to block untrusted DLLs. The trick is bypassing the signature checking process, we can’t just insert our own DLLs, so we must repurpose something which is already trusted, like most of the Microsoft signed binaries in Windows. The simplest attack vector is to use the Scripting Host COM server (scrobj.dll) as it’s already signed and trusted.
This is a vulnerability that affects VirtualBox VMs that use a virtio network adapter (which is a non-standard configuration). It permits the guest kernel to write up to 4GB of controlled data out of bounds in the trusted userland host process. The bug is in the code in src/VBox/Devices/Network/DevVirtioNet.cpp, where an undersized buffer is allocated and memory corruption happens when the attacker-controlled uint32_t is added without overflow check.
This bug report describes two separate issues that, when combined, allow any user on a Linux host system on which VirtualBox is installed to gain code execution in the kernel. The first step of the attack is to get access to the device /dev/vboxdrv, which can normally only be opened by root. In order to be able to open this device, the main VirtualBox binary is setuid root. VirtualBox uses its root privileges to open /dev/vboxdrv, then quickly drops its privileges. However, it retains the open file descriptor to /dev/vboxdrv. Therefore, an attacker can gain access to the device /dev/vboxdrv by injecting code into a VirtualBox userspace process. After dropping privileges, VirtualBox loads various libraries, including QT, that are not designed to run in a setuid context.
Accessing a compromised WMI server over DCOM using System.Management classes or the Powershell Get-WmiObject Cmdlet can lead to the server running arbitrary code on the calling machine leading to RCE. The dangers of using .NET for DCOM are well know, the SRD blog made a post which explicitly said it shouldn’t be used between trust boundaries. Through inspection it’s clear that a number of places the client querys for IManagedObject (for example on the IWbemServices object returned from IWbemLevel1Login::NTLMLogin method) and would be vulnerable. If this interface is being queried it means that a .NET client is trying to create an RCW and will try and create a local copy of a remote serializable object. Therefore in corporate scenarios where some central system is using WMI over DCOM for management and analysis of running systems (and the management code is using the old .NET/PS classes to do the calls) a compromised machine which replaces the WMI service with its own malicious one could get arbitrary code execution on the monitering machine.
Windows 8 and above have a COM service running as the normal user called the Runtime Broker which performs a few services for AppContainer and low IL processes. One of these services is brokering access to the Clipboard which would normally be restricted. I know at minimum this is used in Edge content processes. The broker does prevent things like setting data to the current IDataObject but allows AC applications to set their own IDataObject. To do things like blocking SetData the application provided IDataObject object is wrapped by an OLE32 implementation. We can abuse this functionality by first setting our own IDataObject using SetClipboard then calling GetClipboard to get back the OOP IDataObject wrapper. As this is a wrapper it will never marshal the original IDataObject back to the caller so calling methods on the wrapper will execute code inside the Runtime Broker process running outside the sandbox. If we call something GetData on the OOP wrapper requesting an IStorage object the wrapper will attempt to callback to the IDataObject from the the application to see if that data exists. It does this initially using the GetDataHere method. As this method takes an IN/OUT STGMEDIUM structure it needs to be initialized, it so happens that in this case it will initialize it with an empty READ/WRITE IStorage object. This is passed back to the calling application, however because the default implementation of IStorage does not use custom marshaling (at least for OOP) the IStorage object also never leaves the runtime broker process. We can now do the traditonal IStorage sandbox escape by writing a dll to the IStorage object and then calling LoadLibrary on it.
When cleaning up an ETW session the IEETWCollector service deletes its files and directories as LocalSystem allowing a user to delete arbitrary files or directories on the system. When the IEETWCollection session is closed the service will call CIEEtwSessionData::DeleteSessionFiles which will delete the ETW log file and the directory in which it was stored. The directory is specified by the user during the CIEEtwCollector::CreateCollectionSession call to set up the session. While creating the log directory is done under impersonation (so we can’t create arbitrary directories) the cleanup is not. Therefore we can use symbolic link attacks to redirect the ETL and directory to arbitrary files or directory and when cleanup occurs it will delete them as LocalSystem.
This vulnerability is a Use-After-Free vulnerability in the Spread Operation Optimization in Safari. It occurs when the function |operationSpreadGeneric| is called from a spread operation, and it tries to get a JSGlobalObject from the argument of the spread operation. This can lead to arbitrary code execution when a malicious iframe is loaded.
When creating an object in Javascript, its Structure is created with the constructor's prototype's VM. This could lead to an UXSS condition when Structure::create is called with prototype's vm and globalObject as arguments.
Services By CQR