Down the Rabbit-Hole...
> I often find it valuable to write simple test cases confirming things work the way I think they do. Sometimes I can’t explain the results, and getting to the bottom of those discrepancies can reveal new research opportunities. This is the story of one of those discrepancies; and the security rabbit-hole it led me down.
> Any application, any user - even sandboxed processes - can connect to any CTF session. Clients are expected to report their thread id, process id and HWND, but there is no authentication involved and you can simply lie. Secondly, there is nothing stopping you pretending to be a CTF service and getting other applications - even privileged applications - to connect to you.
> Even without bugs, the CTF protocol allows applications to exchange input and read each other’s content. However, there are a lot of protocol bugs that allow taking complete control of almost any other application.
Regarding disclosure: https://bugs.chromium.org/p/project-zero/issues/detail?id=1859#c10
Bzip2 And The Cve That Wasn’t
> Compiling with the GCC sanitizers and then fuzzing the resulting binaries might find real bugs. But not all such bugs are security issues. When a CVE is filed there is some pressure to treat such an issue with urgency and push out a fix as soon as possible. But taking your time and making sure an issue can be replicated/exploited without the binary being instrumented by the sanitizer is often better.
I don’t think anything went wrong here, but some interesting details.
Design and Evolution of C-Reduce
> Since 2008, my colleagues and I have developed and maintained C-Reduce, a tool for programmatically reducing the size of C and C++ files that trigger compiler bugs. C-Reduce also usually does a credible job reducing test cases in languages other than C and C++; we’ll return to that later.
Part 2: https://blog.regehr.org/archives/1679
KPMG Audit Professionals Manipulated the Scoring of Training Exams
In today’s edition of edit a URL and go to jail...
> KPMG sent participants in training programs a hyperlink that directed them to the applicable exams. Embedded in the hyperlink was an instruction to the server that specified the score necessary to pass the exam. Thus, the characters “MasteryScore=70” meant participants were required to answer at least 70 percent of the answers accurately to pass the exam. By changing the number in the hyperlink, audit professionals could change the score required to pass.
> 58. For a period of time up to November 2015, certain audit professionals, including one partner, altered the URLs for their exams to lower the scores required to pass. Twenty-eight of these auditors did so on four or more occasions. Certain audit professionals lowered the required score to the point of passing exams while answering less than 25 percent of the questions correctly.
Also: 25%??? Come on guys, that’s worse than random chance!
Provoking browser quirks with behavioural fuzzing
> The first bug I want to talk about is how to close a HTML comment in a different way. If you read the HTML specification you’ll know that you can close a comment with --> or --!> but what about another way? This is a great question to start off fuzzing with. You just then need to generate some code that answers that question.
Reverse-engineering Broadcom wireless chipsets
> In this blogpost I provided an account of various activities during my 6 months as an intern at Quarkslab, my project involved understanding the Linux kernel drivers, analyzing Broadcom firmware, reproducing publicly known vulnerabilities, working on an emulator to run portions of firmware, fuzzing and finding 5 vulnerabilities (CVE-2019-8564, CVE-2019-9500, CVE-2019-9501, CVE-2019-9502, CVE-2019-9503). Two of those vulnerabilities are present both in the Linux kernel and firmware of affected Broadcom chips. The most common exploitation scenario leads to a remote denial of service. Although it is technically challenging to achieve, exploitation for remote code execution should not be discarded as the worst case scenario.
Don’t miss the disclosure timeline at the end.
The Fuzzing Hype-Train: How Random Testing Triggers Thousands of Crashes
> Despite massive efforts, finding and reproducing bugs is incredibly hard. Fuzzing is an efficient way of discovering security critical bugs by triggering exceptions such as crashes, memory corruption, or assertion failures automatically (or with a little help) and comes with a witness (proof of the vulnerability) that allows developers to reproduce the bug and fix it.
Notes on fuzzing ImageMagick and GraphicsMagick
> Given the gaping chasm between what was expected and the massive success of OSS-Fuzz on ImageMagick and GraphicsMagick I thought it would be helpful to review what factors I thought were contributing to OSS-Fuzz finding so many vulnerabilities and other bugs:
Remotely compromise devices by using bugs in Marvell Avastar Wi-Fi: from zero knowledge to zero-click RCE
> With this research, I’m going to answer the question that has had to be answered for quite a time: to what extent is Marvell WiFi FullMAC SoC (not) secure. Since the wireless devices with the analyzed chip aren’t fully researched by the community yet, they may contain a tremendous volume of unaudited code, which may result in severe security issues swarming devices equipped with WLAN cards.
How to write a rootkit without really trying
> We open-sourced a fault injection tool, KRF, that uses kernel-space syscall interception. You can use it today to find faulty assumptions (and resultant bugs) in your programs. Check it out!
> This post covers intercepting system calls from within the Linux kernel, via a plain old kernel module. We’ll go through a quick refresher on syscalls and why we might want to intercept them and then demonstrate a bare-bones module that intercepts the read(2) syscall.
MicroWalk: A Framework for Finding Side Channels in Binaries
> In this work, we propose a novel technique based on Dynamic Binary Instrumentation and Mutual Information Analysis to efficiently locate and quantify memory based and control-flow based microarchitectural leakages. We develop a software framework named MicroWalk for side-channel analysis of binaries which can be extended to support new classes of leakage. For the first time, by utilizing MicroWalk, we perform rigorous leakage analysis of two widely-used closed-source cryptographic libraries: Intel IPP and Microsoft CNG. We analyze 15 different cryptographic implementations consisting of 112 million instructions in about 105 minutes of CPU time. By locating previously unknown leakages in hardened implementations, our results suggest that MicroWalk can efficiently find microarchitectural leakages in software binaries.
Vectorized Emulation: Hardware accelerated taint tracking at 2 trillion instructions per second
> In this blog I’m going to introduce you to a concept I’ve been working on for almost 2 years now. Vectorized emulation. The goal is to take standard applications and JIT them to their AVX-512 equivalent such that we can fuzz 16 VMs at a time per thread. The net result of this work allows for high performance fuzzing (approx 40 billion to 120 billion instructions per second [the 2 trillion clickbait number is theoretical maximum]) depending on the target, while gathering differential coverage on code, register, and memory state.
> Further since we’re running emulated code we are able to run a soft MMU implementation which has byte-level permissions. This gives us stronger-than-ASAN memory protections, making bugs fail faster and cleaner.
How I’ve found vulnerability in a popular Rust crate (and you can too)
> I have recently discovered a zero-day vulnerability in a fairly popular and well-designed Rust crate. In this article I’m going to discuss how I did it and why it wasn’t discovered earlier, and introduce a new tool, libdiffuzz, that I’ve created for the job. A recently discovered vulnerability in Rust standard library makes a cameo appearance.
Fuzzing the OpenBSD Kernel
> Fuzzing the OpenBSD kernel using the syzkaller kernel fuzzer.
> A driver for tracking kernel code coverage.
> Enabled on a per thread basis.
> The kernel program counter is tracked during syscalls made by the same thread.
> Not a strict requirement for syzkaller but improves its ability to generate interesting programs.
Fuzzing the .NET JIT Compiler
> I recently came across the excellent ‘Fuzzlyn’ project, created as part of the ‘Language-Based Security’ course at Aarhus University. As per the project description Fuzzlyn is a: … fuzzer which utilizes Roslyn to generate random C# programs
Fault Analysis on RSA Signing
> This spring and summer, as an intern at Trail of Bits, I researched modeling fault attacks on RSA signatures. I looked at an optimization of RSA signing that uses the Chinese Remainder Theorem (CRT) and induced calculation faults that reveal private keys. I analyzed fault attacks at a low level rather than in a mathematical context. After analyzing both a toy program and the mbed TLS implementation of RSA, I identified bits in memory that leak private keys when flipped.
Chaff Bugs: Deterring Attackers by Making Software Buggier
> In this paper, we introduce a new defensive technique called chaff bugs, which instead target the bug discovery and exploit creation stages of this process. Rather than eliminating bugs, we instead add large numbers of bugs that are provably (but not obviously) non-exploitable. Attackers who attempt to find and exploit bugs in software will, with high probability, find an intentionally placed non-exploitable bug and waste precious resources in trying to build a working exploit.
I don’t know about this.
Exploiting a Windows 10 PagedPool off-by-one overflow
> My contribution to the above result was a flag for the “Searchme” task authored by Eat, Sleep, Pwn, Repeat. It involved the exploitation of an off-by-one buffer overflow of a PagedPool allocation made by a vulnerable kernel driver loaded in Windows 10 64-bit. Shortly after the CTF, the original author (@_niklasb) published the source code of the driver and the corresponding exploit (see niklasb/elgoog on GitHub and discussion on Twitter), which revealed that my solution was partially unintended. Niklas used the off-by-one to corrupt allocation metadata and performed some pool feng-shui to get overlapping pool chunks. On the other hand, I achieved a similar outcome through a data-only attack without touching any pool metadata, which made the overall exploitation process somewhat simpler. I encourage you to closely analyze Niklas’ exploit, and if you’re interested in my approach, follow along.
Auditing popular crates: how a one-line unsafe has nearly ruined everything
> The good news is I’ve poked at 6 popular crates now, and I’ve got not a single actually exploitable vulnerability. I am impressed. When I poked popular C libraries a few years ago it quickly ended in tears security vulnerabilities. The bad news is I’ve found one instance that was not a security vulnerability by sheer luck, plus a whole slew of denial-of-service bugs.
My username in every service I sign up for now: "undefined"
> Really test those strict equality checks.