PSA: Symlink traversal on stateful to stop working on a Chrome OS image near you

[Mattias Nissler]

Hi folks,

This is a heads-up that I'm planning to submit https://chromium-review.googlesource.com/c/472908/ this week, which blocks symlink traversal on the stateful file system.

What?

 * Attempts to open or otherwise access files using paths that contain symlinks will be blocked and result in EPERM.

 * This affects /mnt/stateful_partition and /var. No changes for /home and encrypted user file systems (yet - might look into that later).

 * Linked CL sets up exceptions for existing usage of symlinks I'm aware of (see below).

 * Symlinks are still allowed to be created and readlink() works (provided only the last component of the path in question is a symlink). You can thus manually resolve symlinks should that be needed.

Why?

 * Both full Chrome system exploits that have been reported to us from external researchers [1][2] made use of symlinks on stateful to re-gain control of the device after reboot, thus defeating verified boot.

 * Other approaches to address the problem would require all code (init scripts, system daemons) to be extremely careful to make sure they're not writing data to a file system location other than the intended one. In particular, O_NOFOLLOW isn't sufficient as it only affects the final path component. It's just impractical to "fix" all code to exercise the required level of caution.

If you own a piece of code that depends on symlink traversal, you might be covered already by the exceptions I've added:

 * /mnt/stateful_partition/dev_image aka /usr/local

 * /var/log

 * /var/lib/timezone

 * /var/cache/echo

 * /var/cache/vpd

We can add more exceptions as needed. I also have arranged things such that when the kernel blocks a symlink from being traversed, a kernel warning is generated that'll get submitted as a crash report. I intend to monitor reports and address any stray symlink usage to ensure a smooth rollout for our users.

Let me know if you have questions or concerns!

Thanks,

Mattias

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=351788

[2] https://bugs.chromium.org/p/chromium/issues/detail?id=648971

[mor...@google.com]

Hi folks,

Giving a quick heads up that this code has been merged. In addition to the information provided above, please note the following:

- We are now also blocking opening of FIFOs on the stateful partition, as FIFOs have also been abused to achieve persistent exploitation [1].

- We have added a couple more project-specific exceptions to the symlink blocking policy, most notably making an exception for /var/spool.

Thanks,

Micah

[1]: https://bugs.chromium.org/p/chromium/issues/detail?id=766253

[Junichi Uekawa (上川純一)]

Hi,

This is breaking our tests, can we revert this ?

b/74868050

--
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en

---
You received this message because you are subscribed to the Google Groups "Chromium OS dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-dev+unsubscribe@chromium.org.

--

Junichi Uekawa
Google

[Mattias Nissler]

For later reference, reverted per https://chromium-review.googlesource.com/c/chromiumos/platform2/+/963881

Sorry for the breakage - we didn't have any indication that there'd be remaining problems, but we're also not too surprised to find some stragglers... Is there anything that can be done by the respective teams to surface breakage like this to the change author earlier in the process?

Anyhow, we will fix the fallout and make another attempt.

On Thu, Mar 15, 2018 at 4:32 AM, Mu Lin <m...@google.com> wrote:

jetstream can not boot with the change

b/74460454

On Wed, Mar 14, 2018 at 8:29 PM Mike Frysinger <vap...@google.com> wrote:

we currently have support for whitelisting symlink paths but not fifos.  we can probably comment out the "block_fifo" code path and see if the symlink blockage sticks.

-mike

--
You received this message because you are subscribed to the Google Groups "chromeos-security" group.
To view this discussion on the web visit https://groups.google.com/a/google.com/d/msgid/chromeos-security/CADgJSGG9d2syKPSanGeKYBnBQqBGhRCqRhT4nS6LpK4_FFSSRQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "chromeos-security" group.
To view this discussion on the web visit https://groups.google.com/a/google.com/d/msgid/chromeos-security/CAAbOScnm98jaF1jehABmTA4KpQoU6cxrhEdHBSRhjTxdKyVP%3DQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "chromeos-security" group.

To view this discussion on the web visit https://groups.google.com/a/google.com/d/msgid/chromeos-security/CALDvkJ-MZLF10uS1Sxquk8LuZ%3DmiU75PPLJK3VVqC%2B6VP4O%2B8w%40mail.gmail.com.

--

Mattias Nissler | Software Engineer | mnis...@google.com

Google Germany GmbH

ABC-Str. 19

20345 Hamburg

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde.

    

This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.