Bug 520210 - (CVE-2009-3611) CVE-2009-3611 backintime: makes all files world-readable in snapshot when removing it
CVE-2009-3611 backintime: makes all files world-readable in snapshot when rem...
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
high Severity high
: ---
: ---
Assigned To: Red Hat Product Security
impact=important,source=debian,report...
: Reopened, Security
Depends On: 520212
Blocks:
  Show dependency treegraph
 
Reported: 2009-08-28 18:43 EDT by Vincent Danen
Modified: 2009-10-15 03:51 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-30 00:16:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Vincent Danen 2009-08-28 18:43:10 EDT
A Debian bug report [1] indicates that backintime chmods files to mode 0777 prior to removing them via removing a snapshot.  What makes this worse is that if those files exist in subsequent snapshots, the permissions on those files is also mode 0777 which allows anyone to manipulate/delete the files in the backup.

Looking at this further, if I set the backintime backup directory to, say /srv/backups/$USER, and were to have multiple users on the system, each user would be able to see the other's backup files.  Granted, permissions are mimicked from the source, so if a file is 0644 at the source, it will be in the backup as well.  However, I think it might be prudent if /srv/backups/$USER was also owned $USER:$USER and mode 0700.

The file in question is common/snapshots.py which contains:

316        path = self.get_snapshot_path( snapshot_id )
317        cmd = "chmod -R a+rwx "%s"" %  path
318        self._execute( cmd )
319        cmd = "rm -rfv "%s"" % path
320        self._execute( cmd )

I'm not sure what the logic behind chmoding those files in the first place is.  Obviously the user had to have read-permissions to get the files into the backup in the first place so they should all be owned by the user, meaning chmodding the files is relatively useless.  The debian report suggests changing the chmod call to a find call and just changing the mode of directories, but I'm not convinced that's even necessary if the directories are owned by the user to begin with.

There are also two places where this call is made:

% grep -r 'chmod -R a+rwx' *
common/snapshots.py:            cmd = "chmod -R a+rwx "%s"" %  path
common/snapshots.py:                    self._execute( "chmod -R a+rwx "%s"" %  new_snapshot_path )

so the second invocation likely needs to be changed as well.

This would affect Fedora 10, Fedora 11, and rawhide.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543785
Comment 2 Simon 2009-09-15 09:07:53 EDT
Afaik I can close this with rawhide, right?
Comment 3 Vincent Danen 2009-09-16 10:38:25 EDT
No, this should be closed ERRATA, but it should only be closed when the updates are pushed to stable (currently in testing).  There are no references in the bug that it has been pushed to stable and iirc bodhi should be doing that when it is done.  Please don't close this until the updates are actually pushed to stable.

Thanks.
Comment 4 Fedora Update System 2009-09-25 16:12:57 EDT
backintime-0.9.26-3.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 5 Fedora Update System 2009-09-25 16:13:22 EDT
backintime-0.9.26-3.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.