Malware techiques via Linux Chrome and its effects, non-root

Question

Is it possible to visit a website with Chrome on Ubuntu and have that site execute shell code on my machine without explicitly downloading anything nor click on some Chrome execute question/popup? If so, can you explain using a specific example?

I read a few nice articles:

I also read articles of how Linux defaults to non-root / non-admin privileges and its benefits. But isn't that pointless if I'm concerned about a malicious user seeing my personal data in my home dir? ($HOME/*)

What I want protection from:

Not able to retrieve my files under $HOME
Not able to identify key strokes / key logger while using a different Chrome tab, or using any of my Ubuntu apps like /usr/bin/ssh

I believe at least once Chrome's sandbox has been broken. I'm not sure exactly what that then implies.

The above Ubuntu post says Chrome's sandboxing "prevents your system from automatically executing bad code onto your system." Does he mean that if Chrome's sandbox is bypassed, the malicious user can still save a file in, for example, my ~/Downloads dir? Furthermore is he saying that, because Chrome is smart enough, Chrome itself will never try to execute a binary/bash script on its own?

These posts are nice but I'm trying to understand the mechanics behind the scenes, and a very specific example would help clear that up for me.

Thank you.

score 0 · Answer 1 · answered Mar 28 '18 at 22:03

This question looks like it is actually multiple questions asked at once, and the questions are a bit vague. You might get better answers if you break your post up into a few separate more focused questions.

Is it possible to visit a website with Chrome on Ubuntu and have that site execute code on my machine without explicitly downloading anything nor click on some Chrome execute question/popup? If so, can you explain using a specific example?

Here the question is vague. What do you mean by "execute code"? Of course, your browser will execute a bunch of code every time you access almost every website. Every website sends a bunch of JavaScript code to your browser and your browser executes that code using your CPU (via the JS virtual machine implemented by the browser).

Since this seems fairly obvious, it is not clear to me exactly what you are asking about.

What I want protection from:

Not able to retrieve my files under $HOME

In the absence of an exploit to break out of the sandbox you should be pretty well protected here. It would be a huge problem if the browser could read or write files in your home directory. If you find a way to do this probably you can make some money from a bug bounty. But I guess it would entail first finding a way to break out of the sandbox.

Not able to identify key strokes / key logger

Key strokes entered into the browser, like in a form? Again this part of the question is a bit unclear. You would not normally be protected against javascript on the page reading keystrokes entered into a form on the browser page (even prior to form submission). Is this the kind of keystroke you are worried about, or do you mean keystrokes entered into a different application when the browser is running in the background? In this case, again, it would be a major problem if javascript could access those latter keystrokes, so again this would require to break out of the sandbox via some exploit.

Sadly, JavaScript can access those keystrokes, albeit imperfectly and indirectly. Every time you press a key, an interrupt fires and a flush+reload (or JavaScript equivalent, see AnC) side-channel attack can detect that. Knowing just when the interrupt fires is enough to piece together certain keyboard inputs through statistical analysis of key flight and dwell times. It is far harder to pull such an attack off if JIT is disabled, though, because you'll be limited to using `performance.now()` for timing (or maybe CSS animations?). — forest, Mar 28 '18 at 22:50
Thanks for the response @hft. By "execute code" I mean outside the browser's engine, such as shell code, like running /bin/ls or send any other instruction to the shell. And regarding the Chrome sandbox, I think in past times it's been broken and people given some nice bounties, right? So assuming that's true, can that lead to shell code being executed? — Nathanal Lenner, Mar 28 '18 at 23:40
Yes, the sandbox has been broken in the past and will be in the future, but it is not so easy... There is a standing reward of up to $15000 dollars for anyone who find a bug that allows for escape from any sandbox layer in Chrome. But anyways, yes, breaking out of the sandbox in one form or another could allow you to execute code outside the browser's engine. — hft, Mar 29 '18 at 01:27
@NathanalLenner, while it is theoretically possible, it is very unlikely to occur. It would require the attacker having a very valuable zero day exploit. — Neil Smithline, Mar 29 '18 at 03:21

score 0 · Answer 2 · answered Mar 29 '18 at 15:40

If there are no implementation or design flaws in Chrome, then it's not possible for malicious code to execute outside the confines of Chrome's sandbox.

However, Chrome is complex software and new security bugs are frequently found and fixed.

I also read articles of how Linux defaults to non-root / non-admin privileges and its benefits. But isn't that pointless if I'm concerned about a malicious user seeing my personal data in my home dir? ($HOME/*)

If malicious code manages to run with the full privileges of your user account, then your files can no longer be considered safe. But the data of other users are protected (unless you have root privileges):

Chrome's sandbox only isolates a compromised process (running malicious code) from the local system. It does not provide a fundamental isolation of one website from another. If an attacker manages to compromise the process that hosts a malicious page ^{(this takes efforts, but it is not impossible)}, then the web page can access private data from other websites (think of a malicious advertisement that steals your online banking credentials).
The paper "The “Web/Local” Boundary Is Fuzzy: A Security Study of Chrome’s Process-based Sandboxing" (PDF) shows a concrete example of a realistic attack that is not mitigated by the sandbox.

The class of bugs that result in arbitrary access to other origins is called universal cross-site scripting (UXSS), and Chrome's bug tracker has several examples of UXSS ^{(this list is incomplete)}.

What I want protection from:

Not able to retrieve my files under $HOME

Not able to identify key strokes / key logger while using a different Chrome tab, or using any of my Ubuntu apps like /usr/bin/ssh

This is only possible if an attacker abuse the privileges of your user. The browser has multiple layers of protection, the sandbox is just one of them. Breaking through all of those layers typically requires multiple zero-day vulnerabilities. As a normal user, you will likely not be targeted by such attacks, so if you keep your browser up-to-date, the risks are small.

If you don't trust these protections, then you can add another layer of isolation, such as:

Running the browser in a virtual machine (VM).
Running the browser as a separate user.
Running the browser in a container.
Running the browser in another sandbox, such as firejail.
Running the browser under a Mandatory Access Control (MAC) policy, e.g. through AppArmor.

With a VM or a separate user, your personal files are sufficiently isolated (barring bugs in the OS or VM). The other options require a good configuration in order to be secure, and are otherwise not effective or usable (an attacker only needs one hole to escape the sandbox).

Malware techiques via Linux Chrome and its effects, non-root

2 Answers2