header-logo
Suggest Exploit
explore-vulnerabilities

Explore Vulnerabilities

Version
Year

Explore all Exploits:

iOS/MacOS kernel UaF due to lack of locking in host_self_trap

The task struct has a lock (itk_lock_data, taken via the itk_lock macros) which is supposed to protect the task->itk_* ports. The host_self_trap mach trap accesses task->itk_host without taking this lock leading to a use-after-free given the following interleaving of execution: Thread A: host_self_trap: read current_task()->itk_host // Thread A reads itk_host Thread B: task_set_special_port: *whichp = port; // Thread B replaces itk_host with eg MACH_PORT_NULL itk_unlock(task); if (IP_VALID(old)) ipc_port_release_send(old); // Thread B drops last ref on itk_host Thread A: host_self_trap: passes the port to ipc_port_copy_send // uses the free'd port host_self_trap should use one of the canonical accessors for the task's host port, not just directly read it.

IOService::matchPassive Race Condition

IOService::matchPassive is called when trying to match a request dictionary against a candidate IOService. If a candidate IOService does match against the dictionary but the dictionary also specifies an 'IOParentMatch' key then we reach the following code (in IOService.cpp:) OSNumber* alternateRegistryID = OSDynamicCast(OSNumber, where->getProperty(kIOServiceLegacyMatchingRegistryIDKey)); if(alternateRegistryID != NULL) { if(aliasServiceRegIds == NULL) { aliasServiceRegIds = OSArray::withCapacity(sizeof(alternateRegistryID)); } aliasServiceRegIds->setObject(alternateRegistryID); } getProperty is an IORegistryEntry API which directly calls the getObject method of the OSDictionary holding the entry's properties. getProperty, unlike copyProperty, doesn't take a reference on the value of the property which means that there is a short window between where->getProperty(kIOServiceLegacyMatchingRegistryIDKey) and aliasServiceRegIds->setObject(alternateRegistryID) when if another thread sets a new value for the IOService's 'IOServiceLegacyMatchingRegistryID' registry property the alternateRegistryID OSNumber can be freed. This race condition can be won quite easily and can lead to a virtual call being performed on a free'd object.

Kernel Address Leak in Samsung KNOX v2.6

The 'pm_qos' module exposes an interface to kernel space for specifying QoS dependencies. In order to aid in debugging this interface, the module exposes a 'debugfs' interface, available under '/sys/kernel/debug/pm_qos'. This file is world-readable, and allows any user to query the current QOS constraints. The code which prints out each constraint is available under the 'pm_qos_debug_show_one' function in the file 'kernel/power/qos.c'. As seen above, the function prints out the QOS constraint entries (which are static variables stored in the kernel's BSS). To avoid leaking the BSS addresses to unprivileged users, the function uses the format specifier '%pk'. Note that the 'k' character in this format specifier is lowercase, instead of the correct specifier - '%pK' (using an uppercase 'K'). As format specifiers are case-sensitive, the 'vsnprintf' implementation simply ignores the lowercase 'k' - therefore always printing the pointer above. For devices with Samsung KNOX v2.6 (e.g., Galaxy S7 and Galaxy S7 Edge), this allows an attacker to bypass KASLR. This is since t-base (the KNOX security kernel) is loaded at a fixed address, and the attacker can simply read the address of the 'pm_qos' module from the debugfs interface.

PEAR HTTP_UPLOAD Arbitrary File Upload

The HTTP_Upload package is vulnerable to an arbitrary file upload vulnerability. The package comes with an "upload_example.php" file to test the package, when uploading a "restricted" PHP file user will get message like "Unauthorized file transmission". However, the "upload_example.php" will accept any file extension, even if it is not in the "Upload.php" list of allowed extensions. This is due to the fact that the "Upload.php" code does not properly check for case sensitive file extensions. An attacker can exploit this vulnerability to upload malicious files to the server, which can be used to gain remote code execution.

Setgid Binary Creater

The program CreateSetgidBinary.c allows to create the suitable setgid binary circumventing the kernel protection. Currently creating an empty setgid executable in /var/cache/man would work but writing as user man will remove the setgid flag silently. Hence let root itself write binary code to it keeping the flags. But that is not so simple: Writing an interpreter header would be simple, but start of interpreter in kernel will drop the setgid capability immediately. Hence an ELF binary has to be written. The shellcode from below is just 155 bytes to perform setresgid and execute a shell. We need a SUID binary to write arbitrary data to stdout with similar method already used in SuidBinariesAndProcInterface. But they do not just echo, they may perform some kind of transformation, e.g. use basename of arg0 for printing. To avoid transformation do not use SUID binary directly but let ld-linux fault and write out user supplied data without modifications. The faulting can triggered easily using LowMemoryProgramCrashing from previous work. I did not find any SUID binary writing out null-bytes, so they cannot provide the mandatory null-bytes within the ELF header on stdout/stderr. But kernel will help here, just seek beyond end of file before invoking SUID binary, thus filling gap with 0-bytes. The SUID binaries do not write only arg0 but also some error message, thus appending unneeded data to the growing file. As kernel does not allow truncation without losing the setgid flag, the file has to be truncated before the SUID binary is invoked.

Recent Exploits: