Attacking Android Binder

https://androidoffsec.withgoogle.com/posts/attacking-android-binder-analysis-and-exploitation-of-cve-2023-20938/

by campuscodi • 2 years ago

96 40 2 years ago

androidoffsec.withgoogle.com

tripdout• 2 years ago

I'd love to have this in-depth level of knowledge of kernel inner workings. Super interesting writeup.

Binder is actually something that was designed for BeOS and PalmOS, so ironically it is not very tied to Linux and IMHO one of these technologies that Google uses to abstract themselves from Linux.

(It still has something to do with the early implementations since I recognize some of the #define names..)

pjmlp3• 2 years ago

It also provides a way for a pseudo-microkernel like architecture despite Linux, as many services run on their own process talking with the Linux kernel via Binder.

a-dub• 2 years ago

that's right. i believe an internet famous 90s female beos engineer was behind it. diane hakbod?

lmz• 2 years ago

Or maybe they were referring to the exploitation parts needing to know about kernel allocator behavior etc.

giancarlostoro• 2 years ago

Which makes me wonder how does one read up on kernel internals outside of just perusing all the code, how do you get all the wonderful history that is just lost unless you talk to someone who worked on it or find an insightful comment on HN. The one thing version control should emphasize more of is a way to go back through commits and let people (probably approved people) comb through and comment the code in a metadata way that the version control software can display without affecting commits. Would be neat to peruse code, hover (if you have a good editor / IDE ;) and see commentary by others on said code.

doodlesdev• 2 years ago

And again an extremely serious, device-compromising vulnerability, arises from a use-after-free. When will we learn?

I don't think I'll ever be able to trust modern devices until we finally abandon memory-unsafe languages. It's such low hanging fruit at this point I don't understand anymore why OS developers keep investing their time in other parts of the threat model of operating systems if memory usage vulnerabilities keep arising that completely destroy the existence of any security layer in the system.

Was Google's plan to replace Android with Fuchsia? Is there any plan to get rid of these vulnerabilities (specially use-after-free) at scale on Android like the Chrome project has attempted with the MiraclePtr project?

pjmlp3• 2 years ago

It is ongoing,

https://source.android.com/docs/setup/build/rust/building-ru...

cyberax• 2 years ago

There's actually a reimplementation of Binder in Rust, for Linux: https://lwn.net/Articles/953116/

Nereuxofficial• 2 years ago

And furthermore, it is by a Google employee with plans to merge it into Android as far as i know

chc42• 2 years ago

Fuchsia's kernel is written in C++. It's much more a microkernel design, and so device drivers usually run as userspace processes and some of them are Rust, but the core kernel is not written in a memory safe language.

resource_waste• 2 years ago

It wasnt found in the wild... unlike Pegasus.

refulgentis3• 2 years ago

Was Google's plan to replace Android with Fuchsia?

One of the oddities of BigCo and diffusion of responsibility / abdication of intent is, I'm not sure there's one single person who could accurately answer this.

I hate coming out and saying it because I'm a xoogler, and I'm worried people will think I'm breaking new territory by saying this, but it's known outside Google at this point: no. Never say never, but, it's as close to no as you can get.

Given:

- Nest Hubs were/are the only shipping Fuchsia product and are de facto deprecated for Pixel tablet

- Assistant is de facto deprecated for Gemini (Assistant was responsible for Nest Hub's UI, which hasn't seen even minor updates in years)

- what I see occurring on Google's Blind re: multiple Chrome OS engineers confirming they were told to chill out and wait for reprioritization, and a handful expressing it is dead and they're expecting to be transferred to Android desktop work

- Flutter and Fuchsia have both been reported to have firings, whereas Android has had none reported.

- Hiroshi Lockheimer left recently, so now the hardware head owns Android/Chrome OS/Fuchsia.

This all plays along well with what Sundar spends his time on and drags on, and on, and on: about efficiency and focus, meaning, please cull 5-10% of your workers yearly and you're not getting new headcount soon if ever. Because profit margins because Wall Street.

Thus, it looks like a hard decision by a genius leader to turn Assistant, Chrome OS, and Fuchsia into ghost towns staffed by a skeleton crew and reallocate headcount to keeping Android untouched/growing.

I'd be very surprised if Fuchsia ever shipped on anything new Google sells other than things clearly too resource-constrained for Android (speakers and non-ARM chips, i.e nest hubs)

freedomben• 2 years ago

Thanks, that's super interesting. Adding some simple grapevine anecdata, I've been told that even shipping Fuchsia on Nest hubs was more of a solution in search of a problem.

saagarjha3• 2 years ago

Fuchsia saw cuts but still has people working on it.

intexpress• 2 years ago

Was Google's plan to replace Android with Fuchsia?

I think the idea was that Fuchsia might replace Linux (so Android, ChromeOS, and various other OS things at Google would have a dependency on Fuchsia, instead of having a dependency on Linux)

But that seems unlikely now.

I think Fuchsia is pretty much dead, unless someone outside of Google starts using Fuchsia for something (e.g. Facebook almost used Fuchsia a few years ago)

vitiral3• 2 years ago

Large parts of the OS and services like binder DEFINE memory safety. They twiddle the bits to setup the MMU, as well as the functions and data structures for the allocator/etc. Binder, as I understand, is an interface that accepts internal pointers.

There is no automatic memory safety from a language like Rust here. It's not so simple.

Now, perhaps some part of the system could be defined in a memory safe language. That might be good. But not this part.

chc42• 2 years ago

Well, sort of. There definitely have been bugs in Binder related to it incorrectly mapping physical pages, which it needs to be doing as part of its core behavior, and is essentially a logic bug with memory safety implications that Rust fundementally can't defend against. The bug highlighted in the article, and the vast majority of other historical Binder bugs, aren't that though: they are "normal" object lifecycle bugs, related to improper locking, resource cleanup, and error handling. Those bugs very much could be prevented almost entirely with Rust or any other memory safe resource management. In fact, they have rewritten Binder in Rust, with it being the example driver usecase for the Rust-in-Linux push.

userbinator2• 2 years ago

Keep advocating for security, until it turns against you.

Insecurity is freedom.

kaba02• 2 years ago

What an insanely dumb take.

vitiral3• 2 years ago

The motivation for this design is that a client can send a transaction and then wait for a response with one ioctl syscall. In contrast, IPC with sockets requires two syscalls, send and recv.

What a great motivation. Oh wait, then you write your literal operating system and all services in Java of all languages.

I find Android's architecture so frustrating, all the wrong design decisions

kaba02• 2 years ago

Then maybe learn a bit about it, before you decide based on bullshit whether you like it or not? Not that anyone would care about your opinion even then, when you can’t even get right such a basic thing as what it’s written in — then you surely are an expert of the topic.

vitiral3• 2 years ago

I'm aware that binder itself isn't written in Java of that's what you mean (?)

kelnos• 2 years ago

Yeah, I read that and did a double-take. That seems like a pretty silly micro-optimization. Binder is indeed widely used on Android, but I wouldn't expect in tight loops or critical paths. Sure, syscalls aren't cheap, but I can't see this odd interface saving much. Just seems like a recipe for confusion and bugs.

p_l3• 2 years ago

It is very much used in tight loops and critical paths, including graphics, audio, video, etc.

pjmlp3• 2 years ago

Without companies like Google, the best the community is able to deliver is to keep cloning 1970's UNIX in C, ever and ever again.

Attacking Android Binder

Related Stories