header-logo
Suggest Exploit
explore-vulnerabilities

Explore Vulnerabilities

Version
Year

Explore all Exploits:

RCE for PHPMailer < 5.2.20 with Exim MTA

PHPMailer < 5.2.18 Remote Code Execution (CVE-2016-10033), PHPMailer < 5.2.20 Remote Code Execution (CVE-2016-10045) - escapeshellarg() bypass, SwiftMailer <= 5.4.5-DEV Remote Code Execution (CVE-2016-10074), Zend Framework / zend-mail < 2.4.11 - Remote Code Execution (CVE-2016-10034)

nt!NtNotifyChangeDirectoryFile System Call Disclosure of Uninitialized Pool Memory

We have discovered that the nt!NtNotifyChangeDirectoryFile system call discloses portions of uninitialized pool memory to user-mode clients, due to output structure alignment holes. On our test Windows 10 32-bit workstation, an example layout of the output buffer is as follows: Where 00 denote bytes which are properly initialized, while ff indicate uninitialized values copied back to user-mode. The output data is returned in a list of FILE_NOTIFY_INFORMATION structures. If we map the above shadow bytes to the structure definition, it turns out that the uninitialized bytes correspond to the alignment hole between the end of the FileName string and the beginning of the adjacent FILE_NOTIFY_INFORMATION structure, if that string is of an odd length (and therefore not 4-byte aligned). The issue can be reproduced by running the attached proof-of-concept program on a system with the Special Pools mechanism enabled for ntoskrnl.exe. Then, it is clearly visible that bytes at the aforementioned offsets are equal to the markers inserted by Special Pools, and would otherwise contain leftover data that was previously stored in that memory region.

nt!NtQueryVolumeInformationFile System Call Discloses Portions of Uninitialized Pool Memory to User-Mode Clients

We have discovered that the nt!NtQueryVolumeInformationFile system call discloses portions of uninitialized pool memory to user-mode clients, due to output structure alignment holes. On our test Windows 10 32-bit workstation, an example layout of the output buffer is as follows: Where 00 denote bytes which are properly initialized, while ff indicate uninitialized values copied back to user-mode. The output data is returned in a FILE_FS_VOLUME_INFORMATION structure. If we map the above shadow bytes to the structure definition, it turns out that the uninitialized byte corresponds to an alignment hole after the SupportsObjects field. The issue can be reproduced by running the attached proof-of-concept program on a system with the Special Pools mechanism enabled for ntoskrnl.exe. Then, it is clearly visible that bytes at the aforementioned offsets are equal to the markers inserted by Special Pools, and would otherwise contain leftover data that was previously stored in that memory region.

IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS IOCTL in volmgr.sys discloses portions of uninitialized pool memory to user-mode clients

We have discovered that the handler of the IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS IOCTL in volmgr.sys discloses portions of uninitialized pool memory to user-mode clients, due to output structure alignment holes. On our test Windows 7 32-bit workstation, an example layout of the output buffer is as follows: Where 00 denote bytes which are properly initialized, while ff indicate uninitialized values copied back to user-mode. The output data is returned in a VOLUME_DISK_EXTENTS structure [1], which in turn contains a list of DISK_EXTENT structures [2]. If we map the above shadow bytes to the structure definitions, it turns out that the uninitialized bytes correspond to alignment holes after the NumberOfDiskExtents and DiskNumber fields (both of type DWORD, but there is an 8-byte alignment due to other LARGE_INTEGER fields). The concrete number of leaked bytes depends on the number of entries returned by the IOCTL. Repeatedly triggering the vulnerability could allow local authenticated attackers to defeat certain exploit mitigations (kernel ASLR) or read other secrets stored in the kernel address space.

win32k!NtGdiEnumFonts System Call Handler Disclosure

The win32k!NtGdiEnumFonts system call handler discloses very large portions of uninitialized pool memory to user-mode clients. This issue can be reproduced by running the attached proof-of-concept program on a system with the Special Pools mechanism enabled for win32k.sys. It is then visible that a significant number of the bytes are equal to the markers inserted by Special Pools, and would otherwise contain leftover data that was previously stored in that memory region.

win32k!NtGdiGetOutlineTextMetricsInternalW System Call Buffer Overflow

The win32k!NtGdiGetOutlineTextMetricsInternalW system call corresponds to the documented GetOutlineTextMetrics API function, and is responsible for returning information about the outline text metrics associated with a specific Device Context. The output data is passed to the client via a OUTLINETEXTMETRIC structure, which contains fields of various basic types (LONG, WCHAR, BYTE, ...), as well as other embedded structures. Due to the mixture of fields of various widths, the structure has several padding holes which do not correspond to any specific fields, but are required for the correct alignment of the data inside. Since the kernel-mode buffer is not pre-initialized upon allocation, and the holes are also not explicitly initialized in the system call, they end up containing junk data (from previous pool allocations), which is then leaked to the user-mode application.

Freeware Advanced Audio Coder (FAAC) multiple vulnerabilities

The wav_open_read function in frontend/input.c in Freeware Advanced Audio Coder (FAAC) 1.28 can cause a denial of service(large loop) via a crafted wav file. The faacEncOpen function in libfaac/frame.c in Freeware Advanced Audio Coder (FAAC) 1.28 can cause a denial of service(invalid memory read and application crash) via a crafted wav file.

Cross-Site Request Forgery in WonderCMS

WonderCMS is a free open source Content Management System. In other words, WonderCMS is a free website builder. WonderCMS doesn't require any configuration and can be simply unzipped and uploaded to your hosting provider. The database is a text file which you can copy, move, backup and restore easily. An attacker can exploit this vulnerability by crafting a malicious HTML form and submitting it to the vulnerable application. This form can be used to modify the content of the website.

Recent Exploits: