7.1
CWE
264 732
Advisory Published
CVE Published
Updated

CVE-2009-3611

First published: Fri Aug 28 2009(Updated: )

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] <a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543785">http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543785</a>

Credit: secalert@redhat.com

Affected SoftwareAffected VersionHow to fix
Le-Web Backintime=0.9.26
Fedora=10
Fedora=11

Never miss a vulnerability like this again

Sign up to SecAlerts for real-time vulnerability data matched to your software, aggregated from hundreds of sources.

Frequently Asked Questions

  • What is the severity of CVE-2009-3611?

    CVE-2009-3611 is classified as a medium severity vulnerability due to the potential for unauthorized file access and manipulation.

  • How do I fix CVE-2009-3611?

    To fix CVE-2009-3611, update the BackInTime application to a version where this vulnerability has been patched.

  • Which software versions are affected by CVE-2009-3611?

    CVE-2009-3611 affects BackInTime version 0.9.26 and Fedoraproject Fedora versions 10 and 11.

  • What are the consequences of CVE-2009-3611?

    The consequences of CVE-2009-3611 include allowing unauthorized users to manipulate or delete files due to insufficient permission settings.

  • Is there a workaround for CVE-2009-3611?

    A possible workaround for CVE-2009-3611 is to manually adjust file permissions prior to creating snapshots in BackInTime.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2025 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203