Getting RCE in Chrome with incomplete object initialization in the Maglev compiler
https://github.blog/2023-10-17-getting-rce-in-chrome-with-incomplete-object-initialization-in-the-maglev-compiler/ [github.blog]
2023-10-18 19:08
tags:
browser
exploit
javascript
jit
security
In this post I’ll exploit CVE-2023-4069, a type confusion vulnerability that I reported in July 2023. The vulnerability—which allows remote code execution (RCE) in the renderer sandbox of Chrome by a single visit to a malicious site—is found in v8, the Javascript engine of Chrome. It was filed as bug 1465326 and subsequently fixed in version 115.0.5790.170/.171.
Getting RCE in Chrome with incorrect side effect in the JIT compiler
https://github.blog/2023-09-26-getting-rce-in-chrome-with-incorrect-side-effect-in-the-jit-compiler/ [github.blog]
2023-09-29 00:06
tags:
browser
exploit
javascript
jit
programming
security
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.
source: R
Building the fastest Lua interpreter.. automatically!
https://sillycross.github.io/2022/11/22/2022-11-22/ [sillycross.github.io]
2022-11-22 23:10
tags:
compiler
jit
lua
perf
programming
I have been working on a research project to make writing VMs easier. The idea arises from the following observation: writing a naive interpreter is not hard (just write a big switch-case), but writing a good interpreter (or JIT compiler) is hard, as it unavoidably involves hand-coding assembly. So why can’t we implement a special compiler to automatically generate a high-performance interpreter (and even the JIT) from “the big switch-case”, or more formally, a semantical description of what each bytecode does?
source: HN
Cranelift, Part 3: Correctness in Register Allocation
https://cfallin.org/blog/2021/03/15/cranelift-isel-3/ [cfallin.org]
2021-03-19 23:12
tags:
compiler
compsci
development
fuzzing
jit
programming
rust
testing
In this post, I will cover how we worked to ensure correctness in our register allocator, regalloc.rs, by developing a symbolic checker that uses abstract interpretation to prove correctness for a specific register allocation result. By using this checker as a fuzzing oracle, and driving just the register allocator with a focused fuzzing target, we have been able to uncover some very interesting and subtle bugs, and achieve a fairly high confidence in the allocator’s robustness.
source: HN
Research based on the .NET Runtime
http://www.mattwarren.org/2019/10/25/Research-based-on-the-.NET-Runtime/ [www.mattwarren.org]
2019-10-27 04:41
tags:
compsci
dotnet
jit
links
paper
Over the last few years, I’ve come across more and more research papers based, in some way, on the ‘Common Language Runtime’ (CLR). So armed with Google Scholar and ably assisted by Semantic Scholar, I put together the list below.
PyPy's new JSON parser
https://morepypy.blogspot.com/2019/10/pypys-new-json-parser.html [morepypy.blogspot.com]
2019-10-08 17:06
tags:
benchmark
jit
perf
programming
python
In the last year or two I have worked on and off on making PyPy’s JSON faster, particularly when parsing large JSON files. In this post I am going to document those techniques and measure their performance impact.
source: HN
"Stubs" in the .NET Runtime
http://www.mattwarren.org/2019/09/26/Stubs-in-the-.NET-Runtime/ [www.mattwarren.org]
2019-09-26 20:14
tags:
article
compiler
csharp
dotnet
jit
programming
‘Stubs’, as they’re known in the runtime (sometimes ‘Thunks’), provide a level of indirection throughout the source code, there’s almost 500 mentions of them!
This post will explore what they are, how they work and why they’re needed.
The Baseline Interpreter: a faster JS interpreter in Firefox 70
https://hacks.mozilla.org/2019/08/the-baseline-interpreter-a-faster-js-interpreter-in-firefox-70/ [hacks.mozilla.org]
2019-08-30 18:17
tags:
browser
javascript
jit
perf
update
The Baseline Interpreter sits between the C++ interpreter and the Baseline JIT and has elements from both. It executes all bytecode instructions with a fixed interpreter loop (like the C++ interpreter). In addition, it uses Inline Caches to improve performance and collect type information (like the Baseline JIT).
source: HN
The story of a V8 performance cliff in React
https://v8.dev/blog/react-cliff [v8.dev]
2019-08-29 18:15
tags:
garbage-collection
javascript
jit
perf
programming
type-system
Previously, we discussed how JavaScript engines optimize object and array access through the use of Shapes and Inline Caches, and we’ve explored how engines speed up prototype property access in particular. This article describes how V8 chooses optimal in-memory representations for various JavaScript values, and how that impacts the shape machinery — all of which helps explain a recent V8 performance cliff in React core.
source: L
Getting Into Browser Exploitation
https://liveoverflow.com/arbitrary-read-and-write-in-webkit-exploit-browser-0x08/ [liveoverflow.com]
2019-07-26 00:24
tags:
browser
exploit
javascript
jit
programming
security
series
Last post in series, toc at the top.
0x00: New Series: Getting Into Browser Exploitation
0x01: Setup and Debug JavaScriptCore / WebKit
0x02: The Butterfly of JSObject
0x03: Just-in-time Compiler in JavaScriptCore
0x04: WebKit RegExp Exploit addrof() walk-through
0x05: The fakeobj() Primitive: Turning an Address Leak into a Memory Corruption
0x06: Revisiting JavaScriptCore Internals: boxed vs. unboxed
0x07: Preparing for Stage 2 of a WebKit exploit
0x08: Arbitrary Read and Write in WebKit Exploit
source: grugq
It’s Time for a Modern Synthesis Kernel
https://blog.regehr.org/archives/1676 [blog.regehr.org]
2019-07-05 01:28
tags:
jit
systems
The promise of kernel-mode runtime code generation is that we can have very fast, feature-rich operating systems by, for example, not including code implementing generic read() and write() system calls, but rather synthesizing code for these operations each time a file is opened. The idea is that at file open time, the OS has a lot of information that it can use to generate highly specialized code, eliding code paths that are provably not going to execute.
A New Bytecode Format for JavaScriptCore
https://webkit.org/blog/9329/a-new-bytecode-format-for-javascriptcore/ [webkit.org]
2019-06-21 23:00
tags:
compiler
javascript
jit
perf
programming
In this post, we will start with a quick overview of JSC’s bytecode, key aspects of the old bytecode format and the optimizations it enabled. Next, we will look into the new format and how it affects interpreter execution. Finally, we will look at the impact of the new format on memory usage and performance and how this rewrite improved type safety in JavaScriptCore.
source: HN
Trashing the Flow of Data
https://googleprojectzero.blogspot.com/2019/05/trashing-flow-of-data.html [googleprojectzero.blogspot.com]
2019-05-12 15:02
tags:
development
exploit
garbage-collection
javascript
jit
malloc
security
In this blog post I want to present crbug.com/944062, a vulnerability in Chrome’s JavaScript compiler TurboFan that was discovered independently by Samuel (saelo@) via fuzzing with fuzzilli, and by myself via manual code auditing. The bug was found in beta and was fixed before it made it into the stable release of Chrome, but I think it’s interesting for a few reasons and decided to write about it. The issue was in TurboFan’s handling of the Array.indexOf builtin and at first it looked like an info leak at best, so it was not clear that you can turn this into an arbitrary write primitive. Besides that, it’s an instance of a common bug pattern in JIT compilers: the code was making assumptions at compile time without inserting the corresponding runtime checks for these assumptions.
As has been shown many times before, often bugs that don’t seem exploitable at first can be turned into an arbitrary read/write. In this case in particular, triggering the garbage collector while our fake pointer was on the stack gave us a very strong exploitation primitive. The V8 team fixed the bug very quickly as usual. But more importantly, they’re planning to refactor the InferReceiverMaps function to prevent similar bugs in the future. When I noticed this function in the past, I was convinced that one of the callers will get it wrong and audited all the call sites. Back then I couldn’t find a vulnerability but a few months later I stumbled over this newly introduced code that didn’t add the right runtime checks. In hindsight, it would have been worthwhile to point out this dodgy API to the team even without vulnerabilities to show for.
A year with Spectre: a V8 perspective
https://v8.dev/blog/spectre [v8.dev]
2019-04-24 15:11
tags:
browser
defense
javascript
jit
programming
security
sidechannel
In theory, it would be sufficient to defeat either of the two components of an attack. Since we do not know of any way to defeat any of the parts perfectly, we designed and deployed mitigations that greatly reduce the amount of information that is leaked into CPU caches and mitigations that make it hard to recover the hidden state.
Fortunately or unfortunately, our offensive research advanced much faster than our defensive research, and we quickly discovered that software mitigation of all possible leaks due to Spectre was infeasible. This was due to a variety of reasons. First, the engineering effort diverted to combating Spectre was disproportionate to its threat level. In V8 we face many other security threats that are much worse, from direct out-of-bound reads due to regular bugs (faster and more direct than Spectre), out-of-bound writes (impossible with Spectre, and worse) and potential remote code execution (impossible with Spectre and much, much worse). Second, the increasingly complicated mitigations that we designed and implemented carried significant complexity, which is technical debt and might actually increase the attack surface, and performance overheads. Third, testing and maintaining mitigations for microarchitectural leaks is even trickier than designing gadgets themselves, since it’s hard to be sure the mitigations continue working as designed. At least once, important mitigations were effectively undone by later compiler optimizations. Fourth, we found that effective mitigation of some variants of Spectre, particularly variant 4, to be simply infeasible in software, even after a heroic effort by our partners at Apple to combat the problem in their JIT compiler.
source: L
Attacking Clientside JIT Compilers
https://raw.githubusercontent.com/struct/research/master/Attacking_Clientside_JIT_Compilers_Paper.pdf [raw.githubusercontent.com]
2019-04-17 21:48
tags:
browser
exploit
javascript
jit
paper
pdf
security
Our research focused on 3 front end compilers and back end JIT engines for which little, or no public security research exists. We explore the potential security impacts of using JIT engines in applications such as web browsers and language runtimes and describe the tools we developed for security researchers to build on our JIT research. We also discuss a case study of a security vulnerability we found in the Firefox SpiderMonkey front end and discuss ways the back end JaegerMonkey JIT can be used to exploit the vulnerability. Finally, we will conclude with discussion on possible techniques for hardening JIT implementations that apply to both browser and language runtime JIT engines.
Per the author, “Despite being written by a much younger, and dumber, me, this paper on JIT engines has aged well.”
source: grugq
Standardizing WASI: A system interface to run WebAssembly outside the web
https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/ [hacks.mozilla.org]
2019-03-28 07:50
tags:
jit
standard
systems
update
wasm
WebAssembly is an assembly language for a conceptual machine, not a physical one. This is why it can be run across a variety of different machine architectures.
Just as WebAssembly is an assembly language for a conceptual machine, WebAssembly needs a system interface for a conceptual operating system, not any single operating system. This way, it can be run across all different OSs.
This is what WASI is — a system interface for the WebAssembly platform.
source: L
JIT-less V8
https://v8.dev/blog/jitless [v8.dev]
2019-03-13 18:31
tags:
browser
javascript
jit
security
update
How does it work? Essentially, V8 switches into an interpreter-only mode based on our existing technology: all JS user code runs through the Ignition interpreter, and regular expression pattern matching is likewise interpreted. WebAssembly is currently unsupported, but interpretation is also in the realm of possibility. V8’s builtins are still compiled to native code, but are no longer part of the managed JS heap, thanks to our recent efforts to embed them into the V8 binary.
Ultimately, these changes allowed us to create V8’s heap without requiring executable permissions for any of its memory regions.
source: HN
Is C# a low-level language?
https://mattwarren.org/2019/03/01/Is-CSharp-a-low-level-language/ [mattwarren.org]
2019-03-01 16:30
tags:
csharp
cxx
dotnet
jit
perf
programming
Specifically, what happens when translating a C++ raytracer and trying to make it fast.
I started by simply porting the un-obfuscated C++ code line-by-line to C#. Turns out that this was pretty straight forward, I guess the story about C# being C++++ is true after all!!
source: L
Spectre is here to stay: An analysis of side-channels and speculative execution
https://arxiv.org/abs/1902.05178 [arxiv.org]
2019-02-16 06:19
tags:
browser
jit
paper
pdf
security
sidechannel
The recent discovery of the Spectre and Meltdown attacks represents a watershed moment not just for the field of Computer Security, but also of Programming Languages. This paper explores speculative side-channel attacks and their implications for programming languages. These attacks leak information through micro-architectural side-channels which we show are not mere bugs, but in fact lie at the foundation of optimization. We identify three open problems, (1) finding side-channels, (2) understanding speculative vulnerabilities, and (3) mitigating them. For (1) we introduce a mathematical meta-model that clarifies the source of side-channels in simulations and CPUs. For (2) we introduce an architectural model with speculative semantics to study recently-discovered vulnerabilities. For (3) we explore and evaluate software mitigations and prove one correct for this model. Our analysis is informed by extensive offensive research and defensive implementation work for V8, the production JavaScript virtual machine in Chrome. Straightforward extensions to model real hardware suggest these vulnerabilities present formidable challenges for effective, efficient mitigation. As a result of our work, we now believe that speculative vulnerabilities on today’s hardware defeat all language-enforced confidentiality with no known comprehensive software mitigations, as we have discovered that untrusted code can construct a universal read gadget to read all memory in the same address space through side-channels. In the face of this reality, we have shifted the security model of the Chrome web browser and V8 to process isolation.
WebAssembly Is Not a Stack Machine
http://troubles.md/posts/wasm-is-not-a-stack-machine/ [troubles.md]
2019-01-31 23:51
tags:
browser
compiler
jit
perf
wasm
web
This poses a problem for optimisation.
source: L