How a double-free bug in WhatsApp turns to RCE
> In this blog post, I’m going to share about a double-free vulnerability that I discovered in WhatsApp for Android, and how I turned it into an RCE.
> Double-free vulnerability in DDGifSlurp in decoding.c in libpl_droidsonroids_gif
Position Independent Code (PIC) in shared libraries
> This article explained what position independent code is, and how it helps create shared libraries with shareable read-only text sections. There are some tradeoffs when choosing between PIC and its alternative (load-time relocation), and the eventual outcome really depends on a lot of factors, like the CPU architecture on which the program is going to run.
How to make compressed file quines, step by step
> Much of the credit goes to folks much smarter than myself (they will be introduced); this tutorial is meant to curate previous work and literature as much as it is for myself to educate you. The goal here is to allow for any curious, technically-minded newcomer to make sense of all the concepts involved in creating compression quines.
How (not) to sign a JSON object
This covers a lot of ground. I liked this quote, even though there’s much more to the post.
> Canonicalization is a quagnet, which is a term of art in vulnerability research meaning quagmire and vulnerability magnet. You can tell it’s bad just by how hard it is to type ‘canonicalization’.
A better zip bomb
> This article shows how to construct a non-recursive zip bomb that achieves a high compression ratio by overlapping files inside the zip container. “Non-recursive” means that it does not rely on a decompressor’s recursively unpacking zip files nested within zip files: it expands fully after a single round of decompression. The output size increases quadratically in the input size, reaching a compression ratio of over 28 million (10 MB → 281 TB) at the limits of the zip format. Even greater expansion is possible using 64-bit extensions. The construction uses only the most common compression algorithm, DEFLATE, and is compatible with most zip parsers.
Unraveling the JPEG
> JPEG images are everywhere in our digital lives, but behind the veil of familiarity lie algorithms that remove details that are imperceptible to the human eye. This produces the highest visual quality with the smallest file size—but what does that look like? Let’s see what our eyes can’t see!
> This article is about how to decode a JPEG image. In other words, it’s about what it takes to convert the compressed data stored on your computer to the image that appears on the screen. It’s worth learning about not just because it’s important to understand the technology we all use everyday, but also because, as we unravel the layers of compression, we learn a bit about perception and vision, and about what details our eyes are most sensitive to. It’s also just a lot of fun to play with images this way.
ufs - Expand time_t support to 48 bits
> Fix time overflow issues in the original 32-bit UFS code in two ways. First, treat the original 32-bit seconds fields as unsigned.Second, utilize the spare fields to expand these fields to 48 bits each. Retain the nanosecond-grain accuracy of the nsec fields.
The Road to OCIv2 Images: What's Wrong with Tar?
> My first instinct was to title this article “Tar Considered Harmful”, but I had a feeling that the peanut gallery would cringe at such a title. However, this article is very much a foundational discussion of tar and how it fundamentally fails in the use-case of container images (which will outline what we really want from a container image format). There have been some other articles that touch on the issues I go over here, but I hope I can provide a more cohesive insight into the issues with tar. Then again, some folks believe that tar is the best format for container images. I hope this first article will serve as a decent rebuttal.
> Now, don’t misunderstand what I’m saying – my point here is not “it’s old, so it’s bad.” tar is the obvious choice for an archive format, due to its long history and ubiquity, and writing a custom format with no justification would be a borderline reckless thing to do. However, tar‘s history is important to understanding how it got to the state it’s in today. This section will be quite long-winded (there’s forty-something years of history to distil into a single blog post), but you can skip to the end.
More than you really wanted to know about patch
> Back in the 1980’s somebody invented diff -u (“unified diff format“) as a more human readable alternative o the <old >new lines format you get without the -u, and then Larry Wall whipped up a program to reverse the process and use saved diff -u output to modify a file (which was mind-blowing at the time). As far as I can tell the format wasn’t really meant for that, and was made to work with heuristics and hitting it with a rock, but Larry _did_ go on to invent Perl...
TAR versus Portability
> There is no standard version of the tar program.
Ruby 2.x Universal RCE Deserialization Gadget Chain
> This blog post details exploitation of arbitrary deserialization for the Ruby programming language and releases the first public universal gadget chain to achieve arbitrary command execution for Ruby 2.x. This will be described in the following sections which detail deserialization issues and related work, discovery of usable gadget chains, and finally exploitation of ruby serialization.
Case studies in Rich Header analysis and hunting
> I highly recommend reading it but the TL;DR is that at some point Microsoft introduced a function into their linker which embeds a “signature” in the DOS Stub, right after the DOS executable, but before the NT Header. You’ve probably seen it a thousand times when looking at files and never realized it existed. Back in the early 2000’s, when the existence of the header was known for a while, everyone originally assumed it included unique data to identify systems or people, such as with a GUID, and it spawned numerous conspiracy theories - they even nick named it “the Devil’s Mark”. Eventually someone got around to actually reverse engineering (RE) the linker and figured out how the structure of information was being generated and what it actually reflected. Turns out the tin-foils were half-right. The blog post linked above in the Tweet shows what is actually in them and, while not truly unique to a system or person, it can still serve for some identifying purposes to a certain degree. My interest was peaked!
A tale of RPMs
> If you don’t want to read the following, feel free to skip it. The TL;DR is that it’s an awful idea to read the RPM DB directly without using the RPM libs and I eventually gave up. I did manage to access it without executing the RPM command, but then again I’ve just used the RPM libs.
> Sometimes, a government agency will post a PDF that doesn’t contain searchable text. Most often, it’s a scan of a printout. Why? Don’t the NSA, the Department of Justice, etc., know how to convert Word (or whatever) directly to PDF? It turns out that they know more than some of their critics do. The reason? With a piece of paper, you know much more about what you’re actually disclosing.
> The EFAIL attacks exploit vulnerabilities in the OpenPGP and S/MIME standards to reveal the plaintext of encrypted emails. In a nutshell, EFAIL abuses active content of HTML emails, for example externally loaded images or styles, to exfiltrate plaintext through requested URLs. To create these exfiltration channels, the attacker first needs access to the encrypted emails, for example, by eavesdropping on network traffic, compromising email accounts, email servers, backup systems or client computers. The emails could even have been collected years ago.
C with ABC!
> In this paper, I describe a new compiler for the C89 programming language.
A paper and a compiler!
On Validating Inputs
> If the input language is sufficiently complex — which is all too likely in the real world — it might be impossible to write a safe validator. In this case, we have a paradox: the RP can only trust itself to validate its inputs, but cannot safely do so.
Apache Groovy Deserialization: A Cunning Exploit Chain to Bypass a Patch
> In January 2017, the Zero Day Initiative (ZDI) published an advisory for Apache Groovy, ZDI-17-044/CVE-2016-6814. This vulnerability, reported to us in late 2016 by Sam Thomas of Pentest Limited, is a rather deft patch bypass for an earlier vulnerability that was also submitted via the ZDI program.
> The technique the researcher used for this patch bypass highlights the treacherous nature of deserialization vulnerabilities.
XXE - Things Are Getting Out of Band
A pretty nice overview of XXE and exfiltration.
New Android vulnerability allows attackers to modify apps without affecting their signatures
> The Janus vulnerability stems from the possibility to add extra bytes to APK files and to DEX files. On the one hand, an APK file is a zip archive, which can contain arbitrary bytes at the start, before its zip entries (actually more generally, between its zip entries). The JAR signature scheme only takes into account the zip entries. It ignores any extra bytes when computing or verifying the application’s signature. On the other hand, a DEX file can contain arbitrary bytes at the end, after the regular sections of strings, classes, method definitions, etc. A file can, therefore, be a valid APK file and a valid DEX file at the same time.