Ordinarily, updates to the SecureDrop servers are performed automatically within 24 hours of a release. After the release of SecureDrop 0.11.0 on December 11, our monitoring service indicated that some SecureDrop instances were not updated as expected.
Instances known to be impacted were set up before SecureDrop version 0.4 (released July 25, 2017).
A duplicate entry in the Application Server’s
/etc/hosts file was fixed with the release of SecureDrop 0.4. The fix required that the
./securedrop-admin install command be run from the Admin Workstation to reinstall the server configurations. This was not stated in the release notes at the time, and we apologize for the oversight. On instances where
./securedrop-admin install had not been run since the 0.4 release, the duplicate entry caused an error during the automated package update.
To find out if your instance is one of those affected by this issue, check the version string displayed in the footer of the Source Interface. It should include “0.11.0.”
If your instance is still running version 0.10.0, you will need to perform the following manual steps to complete the update:
Once a Tor connection has been established, open a terminal and log into the Application Server with the command
Make a backup copy of the
cp /etc/hosts hosts.bak
/etc/hostsfile in your text editor of choice, e.g.:
sudo nano /etc/hosts
You will likely see duplicate entries in the hosts file for the Monitor Server, in the format:
<monIP> mon securedrop-monitor-server-alias
<monIP>is the IP address of your Monitor Server. If you do not see duplicate entries, please contact us immediately.
Provided you see duplicate entries of this type, remove them, leaving only a single entry for the Monitor Server. Then save the file and exit the editor.
Use the following command to trigger the scheduled update:
sudo cron-apt -i -s
This will update all affected packages. As the tor package will also be updated by this command, the tor proxy on the Application Server will restart and your SSH session may hang or be disconnected. This will also cause a very brief outage of your SecureDrop instance. This is expected behavior. Wait for 5 minutes and reconnect using the
ssh appcommand from the Admin Workstation. Then, use the following command to verify the installed version of the application:
apt-cache policy securedrop-app-code
The command output should include:
If any of these steps fail, please make a note of any error output and contact us either via email at firstname.lastname@example.org (GPG encrypted), or contact us via the support portal if you have an account there:
If you have questions, please do not hesitate to reach out. Please note that the Freedom of the Press Foundation team will be on holiday break from December 24 to January 1, and we will only be able to respond to emergencies during that period.
Questions and Answers
Is my instance secure if I do not perform this upgrade?
SecureDrop 0.11.0 contains a security fix for SSH logins. Since two-factor authentication for console logins was removed in SecureDrop 0.8.0, password authentication was not explicitly disabled for SSH logins. By default, SSH access also requires a Tor ATHS token, providing security in depth in case an insecure password was configured for SSH logins. As a precaution, and to ensure that your instance can be correctly updated with subsequent releases, we recommend updating as soon as possible.
To be clear, until you perform this manual fix, your SecureDrop servers will not be able to install automatic upgrades.
Is there a risk of an outage from performing this upgrade?
We have tested this procedure and are unaware of scenarios in which an outage is likely to arise, beyond a very brief period of unavailability during the upgrade. That said, any version upgrade carries risks. If you choose to defer the upgrade before the holidays, we highly recommend performing it as soon thereafter as possible.