Hacker News Reader

Comment by waihtis | Hacker News Reader

Im not well versed in mobile environments. Presumedly breaking out of the Chrome sandbox would land you within the underlying OS. Can you not build persistence there without abusing further vulns?

View on HN

There's nested sandboxes for browsers in mobile environments. There's the inner layer which the web content is running in, but then the browser itself is sandboxed so it can't do things like access OS APIs it doesn't have permission for, install apps that run in the background, etc. This is why the iOS example needed 3 exploits chained. The fact that a similar example worked on Android, which also has app sandboxing, implies there should be an exploit chain but we've only been told of the first.

There's also SELinux on Android.

But browsers, especially Chrome, have lots of permissions (including geolocation, accessing SD card, accessing user's personal data, camera and microphone etc.). You don't need to do anything if you can run under browser's privileges.

None of the mentioned privileges should net you a persistence though, so there's clearly still another vulnerability.

But smartphones are rarely rebooted so maybe you don't need persistence that much?

You still want priv escalation if you're trying to spy on someone. The content process can't see anything you're doing in other apps, and the browser can only access a very restricted view of the storage

Living in memory or living off the land is generally a good idea, but you still want a chain of exploits anyways

Above says access to SD card. I think that means write ability. Which means persistence.

Persistence means you can write to something that'll cause your malware to run again after reboot, but external storage isn't enough to do that without another exploit in the boot path, right?

Android has clamped down hard on access to the SD card. Chrome certainly doesn't have the special All Files Access, and on my device it doesn't even have Photos or Music, since I never use those permissions with Chrome, and Android regularly turns off permissions that haven't been used recently

that sounds like terrible joke

sandbox in sandbox in sandbox in sandbox in sandbox in sandbox in sandbox

and stuff still manages to escape

That’s the thing about sand. It’s course and rough and irritating and it gets everywhere.

But there is always time for a glass of good wine!

Defence in depth. Now you need a working chain of 3 exploits instead of one. It's about raising the bar, perfect security is impossible.

The Buffalo buffalo buffalo... thing

https://en.m.wikipedia.org/wiki/Buffalo_buffalo_Buffalo_buff...

Gotcha, thank you.

On Android, you usually need three exploits.

1. Chrome code execution (gain foothold inside Chrome process).

2. Sandbox escape (gain code execution outside the Chrome sandbox, with the privileges of the Chrome process, which aren’t very useful except to stage another exploit).

3. Local privilege escalation, usually a kernel bug or similar, to elevate to root where you can break the process “sandbox” and establish persistence.

Reply on news.ycombinator.com