This thread is private but it will eventually be public. Last night all SecureDrop instances automatically upgraded to version 1.7.0 display the following error message when trying to reach the URL to upload documents (this one is for NRK).
The notifications sent by OSSEC reveal the problem:
OSSEC HIDS Notification. 2021 Jan 27 08:01:38 Received From: (app) X.X.X.X->/var/log/syslog Rule: 1002 fired (level 2) -> "Unknown problem somewhere in the system." Portion of the log(s): Jan 27 08:01:38 app python: AttributeError: module 'config' has no attribute 'SESSION_EXPIRATION_MINUTES'
And the manual fix is straightforward:
- From the Admin usb key
- Open a terminal
- ssh app
- echo ‘SESSION_EXPIRATION_MINUTES = 120’ | sudo tee -a /var/www/securedrop/config.py
- sudo apt-get install -f
After this fix is applied, the SecureDrop is back (see Al Jazeera or JMM for instance). At the time of this message (9:50am CEST) some SecureDrop installations are not yet ugpraded and still run 1.6.0 as displayed on their landing page:
All SecureDrop instances in the FPF directory are monitored and FPF staff have received a message about the error. Every contact person for SecureDrop also received this:
The monitoring system operated by Freedom of the Press Foundation (Icinga) was unable to establish a connection to this SecureDrop instance via its public .onion address. Icinga makes repeated connection attempts before sending this notice. Your SecureDrop may be offline, or the Tor network may be experiencing congestion. Icinga will send a notice with the subject line "RECOVERY" when the service is reachable again. If you would like to request advice, or if you want to stop receiving Icinga alerts, please contact us: - via email@example.com - see https://securedrop.org/sites/default/files/fpf-email.asc for our GPG key - via the SecureDrop support portal, if you have an account - see https://support.freedom.press
Although I fixed the problems wherever I could as described above, I also filed an issue at https://support.freedom.press to share the fix. I’m 100% sure FPF staff quickly figured it out but it’s polite to do so.
The manual fix is easy but I’m not sure how it can be fixed with a package upgrade because the bug failed the post installation of the 1.7.0 package. I did not research it but I don’t see how unattended upgrades can recover automatically from a situation where
apt-get install -f is required. If that’s not possible, every SecureDrop administrator will have to manually apply the fix, meaning some of them may be down for an extended period of time.
Which brings me to my question and food for thought for both of you (and the reason why I did not post this publicly): How could this situation be exploited by an adversary ?