Operation Triangulation: What You Get When Attack iPhones of Researchers
This presentation was also the first time we had publicly disclosed the details of all exploits and vulnerabilities that were used in the attack. We discover and analyze new exploits and attacks using these on a daily basis, and we have discovered and reported more than thirty in-the-wild zero-days in Adobe, Apple, Google, and Microsoft products, but this is definitely the most sophisticated attack chain we have ever seen.
npm search RCE? - Escape Sequence Injection
In a previous post I went over a vulnerability I discovered in iTerm2 that allowed code execution in the shell by leveraging the output of a command. Today, We’ll focus on the other side of that interaction, the application running underneath the terminal.
"[31m"?! ANSI Terminal security in 2023 and finding 10 CVEs
This paper reflects work done in late 2022 and 2023 to audit for vulnerabilities in terminal emulators, with a focus on open source software. The results of this work were 10 CVEs against terminal emulators that could result in Remote Code Execution (RCE), in addition various other bugs and hardening opportunities were found. The exact context and severity of these vulnerabilities varied, but some form of code execution was found to be possible on several common terminal emulators across the main client platforms of today.
Getting RCE in Chrome with incomplete object initialization in the Maglev compiler
Getting RCE in Chrome with incorrect side effect in the JIT compiler
In this post, I’ll exploit CVE-2023-3420, a type confusion in Chrome that allows remote code execution (RCE) in the renderer sandbox of Chrome by a single visit to a malicious site.
The WebP 0day
This means that someone, somewhere, had been caught using an exploit for this vulnerability. But who discovered the vulnerability and how was it being used? How does the vulnerability work? Why wasn’t it discovered earlier? And what sort of impact does an exploit like this have?
There are still a lot of details that are missing, but this post attempts to explain what we know about the unusual circumstances of this bug, and provides a new technical analysis and proof-of-concept trigger for CVE-2023-4863 (“the WebP 0day“).
I have discovered a number of security vulnerabilities in Bluesky and atproto. Each time I’ve found something new, I’ve chosen to report it to Bluesky at firstname.lastname@example.org, as requested at https://bsky.app/.well-known/security.txt, and provide them with details. Bluesky has responded to only one of these reports, one time, 4 days after submission, saying “We appreciate the report, and we’ll be taking a closer look at the issue.”. They did not follow up on that report and they have not responded to any of my other reports.
The Internet Worm Program: An Analysis
This report gives a detailed description of the components of the worm program—data and functions. It is based on study of two completely independent reverse-compilations of the worm and a version disassembled to VAX assembly language. Almost no source code is given in the paper because of current concerns about the state of the ‘‘immune system’’ of Internet hosts, but the description should be detailed enough to allow the reader to understand the behavior of the program.
And some modern commentary: https://infosec.exchange/@hovav/110950949212380779
Smashing the state machine: the true potential of web race conditions
HTTP request processing isn’t atomic - any endpoint might be sending an application through invisible sub-states. This means that with race conditions, everything is multi-step. The single-packet attack solves network jitter, making it as though every attack is on a local system. This exposes vulnerabilities that were previously near-impossible to detect or exploit.
What should happen if the processor speculatively executed a vzeroupper, but then discovers that there was a branch misprediction? Well, we will have to revert that operation and put things back the way they were… maybe we can just unset that z-bit?
If we return to the analogy of malloc and free, you can see that it can’t be that simple - that would be like calling free() on a pointer, and then changing your mind!
That would be a use-after-free vulnerability, but there is no such thing as a use-after-free in a CPU… or is there?
CVE-2023-38408: Remote Code Execution in OpenSSH's forwarded ssh-agent
While browsing through ssh-agent’s source code, we noticed that a remote attacker, who has access to the remote server where Alice’s ssh-agent is forwarded to, can load (dlopen()) and immediately unload (dlclose()) any shared library in /usr/lib on Alice’s workstation (via her forwarded ssh-agent, if it is compiled with ENABLE_PKCS11, which is the default).
Surprisingly, by chaining four common side effects of shared libraries from official distribution packages, we were able to transform this very limited primitive (the dlopen() and dlclose() of shared libraries from /usr/lib) into a reliable, one-shot remote code execution in ssh-agent (despite ASLR, PIE, and NX). Our best proofs of concept so far exploit default installations of Ubuntu Desktop plus three extra packages from Ubuntu’s “universe” repository. We believe that even better results can be achieved (i.e., some operating systems might be exploitable in their default installation):
CAN Injection: keyless car theft
This is a detective story about how a car was stolen - and how it uncovered an epidemic of high-tech car theft.
Now that people know how a relay attack works generally possible to defeat it: car owners keep their keys in a metal box (blocking the radio message from the car) and some car makers now supply keys that go to sleep if motionless for a few minutes (and so won’t receive the radio message from the car). Faced with this defeat but being unwilling to give up a lucrative activity, thieves moved to a new way around the security: by-passing the entire smart key system. They do this with a new attack: CAN Injection.
The Most Dangerous Codec in the World: Finding and Exploiting Vulnerabilities in H.264 Decoders
Modern video encoding standards such as H.264 are a marvel of hidden complexity. But with hidden complexity comes hidden security risk. Decoding video in practice means interacting with dedicated hardware accelerators and the proprietary, privileged software components used to drive them. The video decoder ecosystem is obscure, opaque, diverse, highly privileged, largely untested, and highly exposed—a dangerous combination.
We introduce and evaluate H26FORGE, domain-specific infrastructure for analyzing, generating, and manipulating syntactically correct but semantically spec-non-compliant video files. Using H26FORGE, we uncover insecurity in depth across the video decoder ecosystem, including kernel memory corruption bugs in iOS, memory corruption bugs in Firefox and VLC for Windows, and video accelerator and application processor kernel memory bugs in multiple Android devices.
Exploiting aCropalypse: Recovering Truncated PNGs
double-free vulnerability in OpenSSH server 9.1 (CVE-2023-25136)
Exploiting this vulnerability will not be easy: modern memory allocators provide protections against double frees, and the impacted sshd process is unprivileged and heavily sandboxed.
Quick update: we were able to gain arbitrary control of the “rip” register through this bug (i.e., we can jump wherever we want in sshd’s address space) on an unpatched installation of OpenBSD 7.2 (which runs OpenSSH 9.1 by default). This is by no means the end of the story: this was only step 1, bypass the malloc and double-free protections.
The curious tale of a fake Carrier.app
Six privilege escalation exploits are bundled with this app. Five are well-known, publicly available N-day exploits for older iOS versions. The sixth is not like those others at all. This blog post is the story of the last exploit and the month-long journey to understand it.
CVE-2022-23088: Exploiting A Heap Overflow In The Freebsd Wi-Fi Stack
In April of this year, FreeBSD patched a 13-year-old heap overflow in the Wi-Fi stack that could allow network-adjacent attackers to execute arbitrary code on affected installations of FreeBSD Kernel. This bug was originally reported to the ZDI program by a researcher known as m00nbsd and patched in April 2022 as FreeBSD-SA-22:07.wifi_meshid. The researcher has graciously provided this detailed write-up of the vulnerability and a proof-of-concept exploit demonstrating the bug.
Hertzbleed is a new family of side-channel attacks: frequency side channels. In the worst case, these attacks can allow an attacker to extract cryptographic keys from remote servers that were previously believed to be secure.
Hertzbleed takes advantage of our experiments showing that, under certain circumstances, the dynamic frequency scaling of modern x86 processors depends on the data being processed. This means that, on modern processors, the same program can run at a different CPU frequency (and therefore take a different wall time) when computing, for example, 2022 + 23823 compared to 2022 + 24436.
Lend Me Your Ear: Passive Remote Physical Side Channels on PCs
We show that built-in sensors in commodity PCs, such as microphones, inadvertently capture electromagnetic side-channel leakage from ongoing computation. Moreover, this information is often conveyed by supposedly-benign channels such as audio recordings and common Voice-over-IP applications, even after lossy compression.
We analyze the computation-dependent leakage captured by internal microphones, and empirically demonstrate its efficacy for attacks. In one scenario, an attacker steals the secret ECDSA signing keys of the counterparty in a voice call. In another, the attacker detects what web page their counterparty is loading. In the third scenario, a player in the Counter-Strike online multiplayer game can detect a hidden opponent waiting in ambush, by analyzing how the 3D rendering done by the opponent’s computer induces faint but detectable signals into the opponent’s audio feed.
The More You Know, The More You Know You Don’t Know
This is our third annual year in review of 0-days exploited in-the-wild [2020, 2019]. Each year we’ve looked back at all of the detected and disclosed in-the-wild 0-days as a group and synthesized what we think the trends and takeaways are. The goal of this report is not to detail each individual exploit, but instead to analyze the exploits from the year as a group, looking for trends, gaps, lessons learned, successes, etc.