New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 768003 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Last visit 15 days ago
Closed: Dec 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Add a CopyDirectory variant that avoids copying into non-regular files

Project Member Reported by ejcaruso@chromium.org, Sep 22 2017

Issue description

If an attacker arranges a destination directory to have a symlink or fifo that it controls the other end of, CopyDirectory might copy files from the source into unintended locations. This represents a behavioral change in CopyDirectory so we can't just change it directly but should instead make this variant and then migrate people to it.
 
What do you think of my idea about having a variant that only copies into an empty directory? Then you can create base::File with FLAG_CREATE for the destination files, and fail if any file already existed.
That also works. I'll have to look at callers and see if they are copying into nonempty directories (say, copying into a directory they had copied into before).
Only copying into an empty directory has a slightly higher requirement, but is also a bit safer since in that it won't overwrite any existing files. Do you have time to look at existing CopyDirectory() callers and see how many of them meet this requirement? One could just stick a CHECK(base::IsDirectoryEmpty()) call in front of every CopyDirectory() call, send it to the try bots and see what happens.
I thought you did that and saw failures? Either way I'm fine doing that if we make a new variant, and it would be a lot easier to reason about. If someone is relying on that behavior (and they might be, since it's explicitly stated in the header comment) then we might also want this variant to get some intermediate level of guarantees about what it's doing, though.
Oh ya, I did. Looking at the failures:

- CopyLevelDBToProfile() is test only.
- PreinstalledSigninExtensionsDeviceCloudPolicyBrowserTest is test only.
- web_app::WebAppShortcutCreator::CreateShortcutsIn() on Mac fails.

And that's it, so at least with the tests on the Chromium side, there's only 1 non-test caller that needs a non-empty dir.
Project Member

Comment 6 by bugdroid1@chromium.org, Dec 16 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/128f0ddbe714c4a682d3c21466d42471b7ebccef

commit 128f0ddbe714c4a682d3c21466d42471b7ebccef
Author: Eric Caruso <ejcaruso@chromium.org>
Date: Sat Dec 16 01:32:49 2017

file_util: add CopyDirectoryExcl

This is a variant of CopyDirectory which refuses to overwrite
files that already exist in the destination directory.

Bug:  768003 
Test: existing + new unit tests
Change-Id: I29ba308158d13b90f21928b76104eb671ab8a728
Reviewed-on: https://chromium-review.googlesource.com/754266
Commit-Queue: Eric Caruso <ejcaruso@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/master@{#524556}
[modify] https://crrev.com/128f0ddbe714c4a682d3c21466d42471b7ebccef/base/files/file_util.h
[modify] https://crrev.com/128f0ddbe714c4a682d3c21466d42471b7ebccef/base/files/file_util_posix.cc
[modify] https://crrev.com/128f0ddbe714c4a682d3c21466d42471b7ebccef/base/files/file_util_unittest.cc
[modify] https://crrev.com/128f0ddbe714c4a682d3c21466d42471b7ebccef/base/files/file_util_win.cc

Status: Fixed (was: Assigned)
I suppose I should open some bugs to port CopyDirectory users to CopyDirectoryExcl on Chrome and also on Chrome OS, whenever libchrome rolls.

Sign in to add a comment