Hi everyone, here today to talk about my experience hunting native bugs in the Quest.
Hopefully the subtitle "Posing towards memory corruption" is clearer in a moment when we get into the slides :).
My name is Luke - but I go by @datalocaltmp on twitter and dm's are always open
I'm a mobile reverse engineering and vulnerability researcher - specifically focused on Android
And I am also a virtual reality enthusiast - so this project was really a special opportunity.
So today we're going to talk about native bugs in the Quest; and I don't want to assume everyone necessarily knows what that means - so here is the general flow of my talk today.
First we'll go through; what are these native bugs and why are they important?
Then we'll go through where that intersects with the Quest.
I'll cover what tools I use when I do this research and perhaps that is useful for yourselves in your research. primarily these tools are decompilers like Ghidra; dynamic instrumentation tools like frida, and debuggers like lldb and gdb
Finally, I'll go through three unique bugs I've found in the quest - one of which was remotely triggerable. These bugs also represent three different attack scenario's and I think they make good examples for other researchers.
So what is the Android native Layer? I imagine some are familiar but perhaps not everyone.
Note - The quest VR Headset is based on the Android Operating System so many of the paradigms for Android security research apply here.
Here is an image pulled straight from Google's Android documentation.
The highlighted portion of this architecture diagram is the native layer. Though with all abstractions there is quite a bit that is being hidden. But for the most part - this is showing how we have Java API's/System Apps/3rd Party Apps at the layer above the native one.
Keep in mind these native libraries are most-often going to be written in memory unsafe languages - this is where there is a real risk of potent vulnerabilities.
Then then Java apps can talk to the Native layer through the Java native interface (note that all JNI calls will start with Java_)
Note that these libraries can be packaged within the app itself or may be provided by the operating system.
That's all well and good; but what does that mean for the Quest in particular.
Well from the Quest we can see a bunch of native services as well as application process running; if we use frida we can inspect these processes more deeply to see additional native libraries loaded within them.
Foreshadowing later portions of this talk. Lets inspect the ShellEnv process; we can use the process keyword to find native libraries like `libovravatar2p.so` are loaded into the process.
And more foreshadowing. We can see exported function calls from the `libovravatar2p.so` native library that can be called by other native libraries or Java directly (kinda a lie because it isn't named Java_X for JNI definition).
Finally we can kill some of the native services in Quest and see the affects for users - more foreshadowing - if we are able to crash the vr runtime service we can see the Guardian boundary, which is responsible for user safety, can be killed.
That's a super high-level of the Android native layer and where it intersects with the Quest.
Happy to take as many questions now before I continue on with approaching Native research and some case studies.
Great way of starting native research is understanding the attack surface; for quest there are three that I was interested in: 3rd party apps, the bluetooth companion app, and remote messaging components like the built-in social platform and Horizons.
Once I picked an attack surface I would figure out all the ways I could get to native code.
Finally we can kill some of the native services in Quest and see the affects for users - more foreshadowing - if we are able to crash the vr runtime service we can see the Guardian boundary, which is responsible for user safety, can be killed.