-
Notifications
You must be signed in to change notification settings - Fork 696
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upgrade apt without following redirects on first install, fix CVE-2019-3462 #4061
Conversation
Upgrade apt without following redirects in order to mitigate the apt RCE vulnerability at install time. Install-fpf-repo is the first role using apt called during the install process.
Use upstream images that contain a fix to the apt vulnerability
372c05a
to
7206c92
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Confirmed via apt-cache policy apt
that versions of apt installed in the following environments are not vulnerable to CVE-2019-3462:
✅ 1.0.1ubuntu2.19
is installed on trusty staging VMs, and the trusty-based dev container and the builder container
✅ 1.2.29ubuntu0.1 is installed for the xenial dev container and xenial staging VMs
✅ 1.4.9 is installed in the admin container
Additionally:
✅ fresh install on trusty and xenial staging VMs occurs without issue
✅ apt options specified in the added Ansible task mitigate the vuln
Pushed a new builder image to registry that is now based on upsteam trusty image that contains fixes for CVE-2019-3462
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Install logic
- Initial apt update uses the correct flags that mitigate the vulnerability [0]
- The install completes without error
- This also works in Xenial: `molecule converge -s {libvirt,virtualbox}-staging-xenial
Container updates
- The trusty-based builder container contains an updated apt package and the upstream hash is valid.
- The xenial-based dev container contains an updated apt package and the upstream hash is valid.
- The trusty-based dev container contains an updated apt package and the upstream hash is valid.
- The stretch-based admin container contains an updated apt package and the upstream hash is valid.
- The trusy-based dev container was uploaded to container registry.
# redirects are followed when updating apt via apt. | ||
- name: Upgrade apt without following redirects | ||
shell : | | ||
apt -o Acquire::http::AllowRedirect=false update |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason we don't "fail fast" by using set -e
or &&
here so that if the update fails, we don't even attempt the latter steps?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good point, added &&
This task may fail if the servers are behind some kind of corporate proxy that attempts to redirect traffic to local mirrors. I just attempted this at a cafe with a captive portal and got the following errors.
Note all the 302's in |
good points @heartsucker, I've pushed a commit to this branch that adds an assert statement which provides a more admin friendly message in lieu of docs updates, let me know if this addresses your concerns. As far as I know there is no workaround (apart from either using editing the apt list manually or changing networks). I propose we update the docs once this problem arises. |
088823f
to
0a6bc4e
Compare
- Fail faster when upgrading apt. - Provide a more descriptive message if apt traffic is redirected.
0a6bc4e
to
cf84a81
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, approving for the point release (ran through these tasks on trusty once more for good measure)
Yeah this was basically the only way to fix this. Agree on that as the solution. |
Status
Ready for review
Description of Changes
Fixes #4058 .
Changes proposed in this pull request:
Testing
Install logic
Container updates
Deployment
Existing installs
Existing installs have already been updated using cron-apt
New installs
This PR should fix the issue for new installs. Since Ubuntu ISOs will not contain the apt fixes, we change the install logic to update apt before performing any type of other apt operations
Checklist
If you made changes to
securedrop-admin
:make -C admin test
) pass in the admin development containerIf you made changes to the system configuration:
If you made non-trivial code changes:
[0] https://justi.cz/security/2019/01/22/apt-rce.html