Using a symlink on an external drive can also be used to read arbitrary files on the filesystem, as long as the chronos user has permissions (i.e /etc/passwd)

Thanks for the report.

rickyz@: Are you able to triage this?

I just repro'd on M57. Some notes:

1. You'll need to give the symlink a file extension. I was trying first with a bare toprc file name for the symlink but that led to "Save as" adding an implicit ".txt" suffix, so a file named "toprc.txt" was created instead of the write going through the symlink.

2. Make sure the USB drive file system is writable for chronos.

3. The redirection should redirect stdout to stderr, i.e. 1>&2. This is correct in the exploit_top.rc listing, but not in the description.

Regarding security implications, I'm setting medium severity as this is useful to gain arbitrary code execution as a local user (which shouldn't happen in verified mode). This is potentially useful to attack other Chrome OS users by manipulating chronos-writable state on disk. There is no known/obvious remote vector to invoke the privilege escalation, so severity/impact are limited.

Regarding response, I think we have several things to tackle:

1. Command execution via top: top shouldn't execute any external commands.
2. Arbitrary file access via symlinks: Symlinks in an accessible FS location (such as storage media, /home/chronos/user/Downloads) allow access to FS locations intended to be non-accessible.

I'll file separate bugs for these.

rickyz@ is no longer with the team, and I'll soon disappear on paternity leave, so I'll tentatively re-assign this to vapier@ who knows this stuff and can find suitable owners for the individual mitigation work bugs.

Adding dskaram@ FYI for enterprise/EDU since this exploit may be used to circumvent enterprise user policy.

this is missing the step of being able to actually set up the .toprc symlink in the first place in /home/chronos/.  so you'd need an existing exploit that can create arbitrary symlinks in the filesystem first.  i'm not seeing that step listed in the summary anywhere (and creating the symlink in dev mode doesn't count).

I used a USB stick formatted with ext4 with an absolute symlink to /home/chronos/user/.toprc in the root of the filesystem.

ok, thanks for clarifying for me

I've just noticed that the exploit rc file can be minimized to just

top's Config File (Linux processes with windows)
pipe    hack    /bin/bash -c 'reset; exec /bin/bash 1>&2'

which makes it more universal and you don't have to make the extra round trip to use the auto-generated .toprc

vapier: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

vapier: Uh oh! This issue still open and hasn't been updated in the last 28 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Mike?

afaik, mnissler@ was using this as a tracker bug and the issues were being handled in the blocked-on bugs.  so we weren't doing any direct work here.

Is it possible for me to have read access to the two blocked-on bugs? I'm interested in keeping track of the fixes.

the crosh fixes are in M56+ now ( issue 677934 ), so that one's not interesting

i've cc-ed you on the other one though

Thanks

Closing this here since it is being tracked with blocking bugs.

Does this combination of bugs qualify for the Bug Bounty program?

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

i don't have any insight into the bug bounty.  maybe Jorge knows the contacts.

Andrew is our VRP contact.

Yep, the reward panel should certainly consider these bugs. It will go up to the panel in a few weeks.

Apologies if this is already under control, but it looks like this issue was automatically marked ineligible (possibly because it's WontFix Blocked On?). Is this a decision made by the panel or changed in error?

Andrew can confirm what happened here.

Ahh, drat - yea, I forgot sheriffbot would try to be quite so "helpful" :-)

I've added reward-topanel to both of the blocking issues instead.  Thanks for spotting!