A pretty classic string escaping bug in GhostScript, one common and buggy edge case when escaping characters in a buffer is to not properly account for escapes that happen at the very limit of the destination buffer.As was the case here, despite checking that the limit of the buffer was not reached on every iteration, when a character was found that should be escaped, it would write to the destination buffer write, first with the escape character (`0x01`) and then again with an XOR'd version of the character to be escaped...
A fun bug, likely stemming from misunderstanding the return value from an `snprintf` call. Unfortunately (for us, good for security) only seems to be useful for a denial of service attack.
I thought this was an excellent post when it came to explaining the exploitation strategy, and has it dealt with encrypted pointers the exploitation was pretty cool to see documented. However I did have some problems following on the actual vulnerability details.
An exploit chain that targets Samsung's TEEgris OS running in the ARM TrustZone secure world.TEEgris consists of a secure kernel and trustlets that run on the userspace side, which Android in the non-secure world can communicate with via Secure Monitor Calls (SMCs)...
A 19-year-old bug in XNUs Data Link Interface Layer or DLIL that lead to an out-of-bounds write on the heap.The root cause is that `ifnet_attach()` will get the next interface `index` as a 32-bit integer and downcast it to a `uint16_t` when saving the index...
Multiple vulnerabilities were announced in Git, the most interesting to me though are the integer overflows in parsing `.gitattributes` leading to out-of-bounds reads and writes.
The last time we covered a "how to exploit a null-deref in the modern era" post we were...disappointed (and potentially attacked by North Korea but that's another story), this one is legit. Rather than focusing on the null-deref as the core memory corruption though, it abuses the handling of the null-dereference with a kernel oops and the side-effects of the oops to overflow a reference count.
The root of the issue is that XSLTC (turns XSLT into a Java Class to be executed for better performance) does not account for that fact that the `constant_pool_count` in a Java class is only 16bits. An attacker can create an XSLT document containing too many constants, all of which will be written to the class file, but the count will be truncated to 16bits, leading to some of those constants being interpreted as part of the classfile containing things like field and method descriptions for the class.
An integer overflow in SQLite's `sqlite3_str_vappendf`, large inputs when dealing with `q` `Q` or `w` format specifiers (unique to SQLite's implementation of `printf` used to escape quotes).In calculating the maximum buffer once escapes have been added the size may overflow to a negative value leading to SQLite using a 70byte (by default) stack allocated buffer...
An integer overflow in the official SHA-3 implementation as used by PHP, Python, Ruby and I'm sure other places.When updating a block that already has some data in it, it will try to calculate if the new partial block bytes will go out of bounds, it makes the classic mistake of adding the current index and the length of new data, then just checking if it is lower than a bounding value...
A couple integer overflows in the the Windows Kernel through the registry, the core problem being that a 16bit integer is used for the `Count` field storing the number of subkeys inside an index.Under normal circumstances, when adding new subkeys the registry will automatically divide itself so you won't have more than ~1000 subkeys, but you can import arbitrarily formatted indexes, using this you can craft one with 65535 keys...