We can create user and give admin privilege to user which we have made without login. Because this app does not check the session on this request. We can download another file with change value on filename parameter and also we can send this request without login.
This module exploits a stack-based buffer overflow vulnerability in the web interface of VX Search Enterprise v9.5.12, caused by improper bounds checking of the request path in HTTP GET requests sent to the built-in web server. This module has been tested successfully on Windows 7 SP1 x86.
HIServices.framework is used by a handful of deamons and implements its own CFObject serialization mechanism. The entrypoint to the deserialization code is AXUnserializeCFType; it reads a type field and uses that to index an array of function pointers for the support types. From a cursory inspection it's clear that these methods don't expect to parse untrusted data. The first method, cfStringUnserialize, trusts the length field in the serialized representation and uses that to byte-swap the string without any bounds checking leading to me to believe that this is a heap overflow vulnerability.
CAMediaTimingFunctionBuiltin is a class in QuartzCore. Its initWithCoder: method reads an Int 'index' then passes that to builtin_function. If rax is non-null it's returned as an objective-c object pointer and the objective-c retain selector is sent to it. Serialized poc in attached file with an index of 12345678.
Using lldb inside a simple hello_world app for iOS, it was discovered that there are over 600 classes which could be deserialized. The TextInput framework which is loaded has a class TIKeyboardLayout. The initWithCoder: implementation has code which reads binary data from the NSCoder, divides the length by 8 and passes that to ensureFrameCapacity which passes it to calloc with an item size of 8. This has the effect of mallocing the original size rounded down to the nearest multiple of 8. The memcpy then uses the original length (not rounded down) causing a controlled heap buffer overflow.
Via NSUnarchiver, an attacker can read NSBuiltinCharacterSet with a controlled serialized state. It reads a controlled int using decodeValueOfObjCType:'i' then either passes it to CFCharacterSetGetPredefined or uses it directly to manipulate __NSBuiltinSetTable. Neither path has any bounds checking and the index is used to maniupulate c arrays of pointers.
Sending a crafted NSArchiver object to any process that calls NSArchive unarchive method will result in a buffer overflow, allowing for ROP. The unarchiving of NSCharacterSet will call NSCharacterSetCFCharacterSetCreateWithBitmapRepresentation. If a large bitmap is passed, it can get to the call multiple times, leading to writing a pointer to semi-controlled data one qword below the heap allocation _nonBMPPlanes.
When the eBPF verifier runs in verbose mode, it dumps all processed instructions to a user-accessible buffer in human-readable form using print_bpf_insn(). For instructions with class BPF_LD and mode BPF_IMM, it prints the raw 32-bit value. This is done in do_check(), after replace_map_fd_with_map_ptr() has executed. replace_map_fd_with_map_ptr() stores the lower half of a raw pointer in all instructions with class BPF_LD, mode BPF_IMM and size BPF_DW (map references). So when verbose verification is performed on a program with a map reference, the lower half of the pointer to the map becomes visible to the user.
This vulnerability allows unentitled root to read kernel frame pointers, which might be useful in combination with a kernel memory corruption bug. By design, the syscall stack_snapshot_with_config() permits unentitled root to dump information about all user stacks and kernel stacks. While a target thread, along with the rest of the system, is frozen, machine_trace_thread64() dumps its kernel stack. machine_trace_thread64() walks up the kernel stack using the chain of saved RBPs. It dumps the unslid kernel text pointers together with unobfuscated frame pointers.
The XNU kernel, when compiled for a x86-64 CPU, can run 32-bit x86 binaries in compatibility mode. 32-bit binaries use partly separate syscall entry and exit paths. To return to userspace, unix_syscall() in bsd/dev/i386/systemcalls.c calls thread_exception_return() (in osfmk/x86_64/locore.s), which in turn calls return_from_trap, which is implemented in osfmk/x86_64/idt64.s. return_from_trap() normally branches into return_to_user relatively quickly, which then, depending on the stack segment selector, branches into either L_64bit_return or L_32bit_return. While the L_64bit_return path restores all userspace registers, the L_32bit_return path only restores the registers that are accessible in compatibility mode; the registers r8 to r15 are not restored. This is bad because, although switching to compatibility mode makes it impossible to directly access r8..r15, the register contents are preserved, and switching back to 64-bit mode makes the 64-bit registers accessible again. An unprivileged 32-bit process can leak kernel register contents as follows: make a normal 32-bit syscall, switch to 64-bit mode (e.g. by loading the 64-bit user code segment using iret), store the contents of r8..r15, switch back to compatibility mode (e.g. by loading the 32-bit user code segment using iret).