A buffer overflow vulnerability exists in FreeFloat FTP Server due to improper bounds checking of user-supplied input when handling the ABOR command. An attacker can exploit this vulnerability to execute arbitrary code in the context of the application.
A buffer overflow vulnerability exists in FreeFloat FTP Server 1.0 when handling the RMD command. An attacker can send a specially crafted RMD command with an overly long string, which can cause a stack-based buffer overflow, overwriting the saved return address and allowing arbitrary code execution.
The vulnerability exists due to insufficient sanitization of user-supplied input in 'username' and 'password' parameters of 'login.php' script. A remote attacker can bypass authentication and gain access to the application.
This exploit is a buffer overflow vulnerability in the delete command of PCmanftpd 2.0.7. The vulnerability is triggered when a malicious user sends an overly long string to the delete command. This causes a buffer overflow, overwriting the EIP and allowing the execution of arbitrary code. The exploit was tested on Windows 7 Enterprise x64 HUN/ENG.
There is a missing bounds check in inner loop of the escape handler for 0x7000014 that leads to a stack buffer overflow. The attached PoC gives the following crashing context (Win 10 x64, 372.54): DRIVER_OVERRAN_STACK_BUFFER (f7). A driver has overrun a stack-based buffer. This overrun could potentially allow a malicious user to gain control of this machine.
The DxgkDdiEscape handler for 0x70000d5 lacks bounds checks, which leads to overflow of the global buffer, and pool overflows when it's copied back into the escape data.
The DxgkDdiEscape handler for escape 0x100009a lacks proper bounds checks, leading to a buffer overflow on the allocated pool buffer. There is a check that total_size > 0x10, which calls some kind of a debug/logging function (do_debug_thingo in my pseudocode), but it does not actually stop processing of the escape. There is also a potential integer overflow in the calculation of |total_size|.
The DxgkDdiEscape handler for 0x5000027 accepts a user provided pointer, but does no checks on it before using it. This can lead to a buffer overflow vulnerability. The PoC provided causes a read on said pointer, but based on inspecting where this pointer is passed it seems like there is at least 1 code path that can result in a write (not confirmed).
The DxgkDdiEscape handler for 0x7000170 lacks proper bounds checks for the variable size input escape data, and relies on a user provided size as the upper bound for writing output. To reproduce, compile the PoC as a x64 binary (requires linking with setupapi.lib, and WDK for D3DKMTEscape), and run. It may require some changes as for it to work as the escape data must contain the right values (e.g. a field that appears to be gpu bus device function).
The DxgkDdiEscape handler for escape code 0x100010b takes in a user mode event handle from userspace, and calls ObReferenceObjectByHandle on it, writing the object pointer to |Object|. Note that the kernel implementation of ObReferenceObjectByHandle always begins with writing NULL to this pointer regardless of whether or not the handle is valid. |Object| is calculated using a user provided index that is not bounds checked, leading to OOB write of either NULL or the KEVENT pointer.
Services By CQR