Opened 5 months ago

Closed 5 months ago

Last modified 5 months ago

#29158 closed defect (fixed)

Add fix for DSA 4371-1 (apt vulnerability)

Reported by: boklm Owned by: tbb-team
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: TorBrowserTeam201901R, tbb-rbm, tbb-backported
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Debian announced yesterday an important security update for apt:
https://lists.debian.org/debian-security-announce/2019/msg00010.html

In projects/debootstrap-image we are downloading an Ubuntu 18.04.1 image, and doing an apt-get update -y in it before installing some packages using an affected apt version.

To avoid this we could download updated apt packages and install them using dpkg -i.

We should also check if the use of debootstrap is affected by the issue.

Child Tickets

Change History (14)

comment:1 Changed 5 months ago by boklm

Keywords: TorBrowserTeam201901R added; TorBrowserTeam201901 removed
Status: newneeds_review

comment:2 Changed 5 months ago by gk

What happens inside the containers if we are installing, say, build dependencies? Are we good here? I guess I was wondering about the apt-get calls in container-image/config.

comment:3 Changed 5 months ago by watt

EOLed wheezy?!

comment:4 in reply to:  2 Changed 5 months ago by boklm

Keywords: TorBrowserTeam201901 added; TorBrowserTeam201901R removed
Status: needs_reviewneeds_revision

Replying to gk:

What happens inside the containers if we are installing, say, build dependencies? Are we good here? I guess I was wondering about the apt-get calls in container-image/config.

After checking, debootstrap is not installing packages from security.debian.org. So we are using a vulnerable apt version in container-image/config.

I think we can fix that by manually installing new apt packages inside the chroots after creating them with debootstrap in projects/debootstrap-image/config. I will work on a new version of the patch doing that.

comment:5 in reply to:  3 Changed 5 months ago by boklm

Replying to watt:

EOLed wheezy?!

For wheezy, I think we can use the update provided by Freexian:
https://deb.freexian.com/extended-lts/updates/ela-76-1-apt/

Until we do #26238.

comment:6 Changed 5 months ago by gk

The 32bit situation for Linux looks bleak. BUT: I thought we should start soon with #26323 anyway. I think this bug is a reason to start now-ish with that effort. I guess we could try to squeeze it into 8.5. boklm: what do you think?

comment:7 in reply to:  6 Changed 5 months ago by boklm

Replying to gk:

The 32bit situation for Linux looks bleak. BUT: I thought we should start soon with #26323 anyway. I think this bug is a reason to start now-ish with that effort. I guess we could try to squeeze it into 8.5. boklm: what do you think?

Yes, I think it should be possible to do #26323 soon.

The new apt package is not available yet for i386 at this time:
http://deb.freexian.com/extended-lts/pool/main/a/apt/

However maybe they will add it later as looking at the file modification time it seems it is not the first time that the i386 package comes later. Otherwise we can maybe rebuild the package ourself.

I started working on a patch installing the apt updated packages into the containers:
https://gitweb.torproject.org/user/boklm/tor-browser-build.git/commit/?h=bug_29158_v3&id=4672030e7308f852836092ddcfdce76ae90f797b

It is currently installing the packages on stretch too, however since yesterday they made a stretch point release, so it should not be needed anymore (but maybe we can add a check to verify that the correct version was installed).

comment:8 Changed 5 months ago by boklm

Keywords: TorBrowserTeam201901R added; TorBrowserTeam201901 removed
Status: needs_revisionneeds_review

There is a patch for review in branch bug_29158_v4:
https://gitweb.torproject.org/user/boklm/tor-browser-build.git/commit/?h=bug_29158_v4&id=f9cbcb92e13bea3792733dd89d6efab4d62be7e2

We are now checking the version of the apt package installed.

It is still missing the fix for wheezy-i386 which I think could be done in a separate commit.

comment:9 Changed 5 months ago by gk

Status: needs_reviewneeds_information

So, we need 4 packages to fix the vulnerability on Debian systems. Why do we only need 2 for Ubuntu?
What is the plan for 32bit Wheezy? commit cd1874ffe37bc50bda7ea2fefadd9637d93b360b ? I am feeling a bit reluctant to taking trusty packages tbh...

comment:10 in reply to:  9 Changed 5 months ago by boklm

Replying to gk:

So, we need 4 packages to fix the vulnerability on Debian systems. Why do we only need 2 for Ubuntu?

I looked at the Ubuntu image we download, and there was only 2 apt packages included inside this image. For the Debian ones, I looked at the apt packages installed by debootstrap, and there was those 4 packages.

What is the plan for 32bit Wheezy? commit cd1874ffe37bc50bda7ea2fefadd9637d93b360b ? I am feeling a bit reluctant to taking trusty packages tbh...

The commit using trusty packages was just a test to see if that could work, but it doesn't work.
I think the plan is to do #26323 to be able to stop using 32bit Wheezy.

comment:11 Changed 5 months ago by gk

Resolution: fixed
Status: needs_informationclosed

Okay, sounds good. This got merged into master with commit 15e8c5389b76e5fd8634a35c5bff1a5a7192a818. #26323 will address the 32bit Wheezy issue.

comment:13 in reply to:  12 Changed 5 months ago by boklm

Replying to boklm:

In branch bug_29158_maint-8.0_v2, I backorted patches for #29158, #29181 and #29235 on maint-8.0:
https://gitweb.torproject.org/user/boklm/tor-browser-build.git/commit/?h=bug_29158_maint-8.0_v2&id=d036a293dcd041d3ed4d02453b85aa03cfed23fa

And I checked that a release build of https-everywhere is working correctly.

comment:14 Changed 5 months ago by gk

Keywords: tbb-backported added

Thanks, looks good to me and pushed to maint-8.0. I'll note the commits in the respective bugs. The bugfix for this ticket is available in commit 528f683266709865780e75b14755715f44f04d5a.

Note: See TracTickets for help on using tickets.