world writable files in /var/lib/apt/lists

Bug #1304657 reported by Jamie Strandboge
256
This bug affects 1 person
Affects Status Importance Assigned to Milestone
apt (Ubuntu)
Fix Released
High
Michael Vogt
Trusty
Fix Released
High
Michael Vogt

Bug Description

When performing installation audits, I noticed on the image from 2014-04-07 the following after a livecd install:

$ ls -l /var/lib/apt/lists|grep 'rw\-rw\-rw'
-rw-rw-rw- 1 root root 29759 Apr 8 09:10 Ubuntu%2014.04%20LTS%20%5fTrusty%20Tahr%5f%20-%20Daily%20amd64%20(20140407)_dists_trusty_main_binary-amd64_Packages
-rw-rw-rw- 1 root root 0 Apr 8 09:10 Ubuntu%2014.04%20LTS%20%5fTrusty%20Tahr%5f%20-%20Daily%20amd64%20(20140407)_dists_trusty_main_binary-i386_Packages
-rw-rw-rw- 1 root root 1199 Apr 8 09:10 Ubuntu%2014.04%20LTS%20%5fTrusty%20Tahr%5f%20-%20Daily%20amd64%20(20140407)_dists_trusty_restricted_binary-amd64_Packages
-rw-rw-rw- 1 root root 0 Apr 8 09:10 Ubuntu%2014.04%20LTS%20%5fTrusty%20Tahr%5f%20-%20Daily%20amd64%20(20140407)_dists_trusty_restricted_binary-i386_Packages

This also happens on the server install from the same date:
$ ls -l /var/lib/apt/lists|grep 'rw\-rw\-rw'
-rw-rw-rw- 1 root root 1702199 Apr 8 09:09 Ubuntu-Server%2014.04%20LTS%20%5fTrusty%20Tahr%5f%20-%20Daily%20amd64%20(20140407)_dists_trusty_main_binary-amd64_Packages
-rw-rw-rw- 1 root root 0 Apr 8 09:09 Ubuntu-Server%2014.04%20LTS%20%5fTrusty%20Tahr%5f%20-%20Daily%20amd64%20(20140407)_dists_trusty_main_binary-i386_Packages
-rw-rw-rw- 1 root root 0 Apr 8 09:09 Ubuntu-Server%2014.04%20LTS%20%5fTrusty%20Tahr%5f%20-%20Daily%20amd64%20(20140407)_dists_trusty_restricted_binary-amd64_Packages
-rw-rw-rw- 1 root root 0 Apr 8 09:09 Ubuntu-Server%2014.04%20LTS%20%5fTrusty%20Tahr%5f%20-%20Daily%20amd64%20(20140407)_dists_trusty_restricted_binary-i386_Packages

I installed the image from 2014-04-07, installed today and noticed the above.

Related branches

tags: added: rls-t-incoming
Revision history for this message
Steve Langasek (vorlon) wrote :

is this reproducible with apt-cdrom and inserting an ISO into the drive post-install, or is it only reproduced when installing from the ISO?

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

Ok, on a longtime trusty-amd64 livecd install, I confirmed that these files didn't exist. I updated to newest trusty (it was slightly out of date) and they still didn't exist. I then attached the iso to the VM, booted, had the VM mount in Unity, then did:
$ sudo apt-cdrom --cdrom '/media/jamie/Ubuntu 14.04 LTS amd64' --no-auto-detect --no-mount add
$ sudo apt-get update
$ ls -l /var/lib/apt/lists/ |grep 'rw-rw-rw'
-rw-rw-rw- 1 root root 29759 Apr 8 16:25 Ubuntu%2014.04%20LTS%20%5fTrusty%20Tahr%5f%20-%20Daily%20amd64%20(20140407)_dists_trusty_main_binary-amd64_Packages
-rw-rw-rw- 1 root root 0 Apr 8 16:25 Ubuntu%2014.04%20LTS%20%5fTrusty%20Tahr%5f%20-%20Daily%20amd64%20(20140407)_dists_trusty_main_binary-i386_Packages
-rw-rw-rw- 1 root root 1199 Apr 8 16:25 Ubuntu%2014.04%20LTS%20%5fTrusty%20Tahr%5f%20-%20Daily%20amd64%20(20140407)_dists_trusty_restricted_binary-amd64_Packages
-rw-rw-rw- 1 root root 0 Apr 8 16:25 Ubuntu%2014.04%20LTS%20%5fTrusty%20Tahr%5f%20-%20Daily%20amd64%20(20140407)_dists_trusty_restricted_binary-i386_Packages

I then commented out the entry in /etc/apt/sources.list, ran apt-get update and the above files disappeared.

Revision history for this message
Steve Langasek (vorlon) wrote :

Michael, can you please look at this for 14.04?

Changed in apt (Ubuntu):
assignee: nobody → Michael Vogt (mvo)
importance: Undecided → High
status: New → Triaged
Michael Vogt (mvo)
Changed in apt (Ubuntu):
status: Triaged → In Progress
Revision history for this message
Michael Vogt (mvo) wrote :

It appears that git commit 7335eebea6dd43581d4650a8818b06383ab89901 introduced the bug, i.e. the fchmod() call there. This was done in Tue Aug 27 2013. Ironically it was meant to improve the security of apt by replacing mktemp() with mkostemp() - oh well. No stable version of ubuntu is affected (and none for Debian) - the change was introduced in apt 0.9.11.2.

The issue is caused by the confusingly named paramter "Perm" in FileFd::Open() which is not actually the Permission bits but the mode bits of open(). So 666 means something entirely different here in fchmod() than in open().

Revision history for this message
Michael Vogt (mvo) wrote :

This is fixed in https://github.com/mvo5/apt/commit/128b98c4538095bfa427d4860b48025de1ac9436 but I would like to get Davids review before the upload (just in case).

tags: removed: rls-t-incoming
Michael Vogt (mvo)
Changed in apt (Ubuntu Trusty):
status: In Progress → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package apt - 1.0.1ubuntu2

---------------
apt (1.0.1ubuntu2) trusty; urgency=low

  * fix symlink of etc/apt/apt.conf.d/01autoremove when runnning in
    the auto-pkg-test environment
 -- Michael Vogt <email address hidden> Thu, 10 Apr 2014 14:24:25 +0200

Changed in apt (Ubuntu Trusty):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.