Hi everyone,
Many of you may have heard of the recent severe OpenSSL vulnerability discovered which allows an attacker significant access to a web server's internal memory. I wanted to share my assessment here as to how this impacts LedgerSMB, what mitigation and recovery measures I would recommend, etc.
First a note. If you use LedgerSMB solely from your own computer, on a trusted network, where it is not accessible from outside, you have nothing to worry about. In these cases you might not even be using SSL.
I am going to make a few assumptions in this post. If these assumptions do not pertain to you, you may want to conduct your own assessment (you may want to anyway, but at least this is a starting point).
The assumptions are that you are running LedgerSMB through one of the means we support (namely that it is either cgi or fcgi), and that you have followed our security best practices. Also I will assume that only information from the web server's process itself can be read, and that your web server is on a publicly accessible internet address.
The attack works by effectively tricking OpenSSL into handing back memory from the process using the library. Because all LedgerSMB supported configurations currently run in processes external to the web server, one cannot get information relating to the internal operation of LedgerSMB. However one can get the private keys and this is itself a massive problem.
What this means is that if an attacker were to compromise the private keys that make SSL work on the server, they could eavesdrop on the encrypted connections and get any other information sent between the web server and web browsers. This includes usernames and passwords. If you are not using client certificates, they might then be able to log into the system using overheard credentials, and if your database is exposed to the internet via the same credentials you are at risk there (this is uncommon however).
Bruce Schneier's points here are ultimately correct, namely that one should assume keys to have been compromised and if they have been, then usernames and passwords are possibly compromised as well.
In general, the larger deployments I know of are not directly vulnerable to unauthorized access but may benefit from enforcing a password change as a general security measure.
If users are concerned about the impact of this security vulnerability, I am happy to discuss it further. While I am happy to respond privately to requests for individual assessments of risk, for discussions about how to take common mitigation efforts, I think the best place to discuss these is on the -users list.
For those who are worried about exposure, the below snippet of code you can use to force all users to change their passwords within a week. If you want to change the amount of time, you can change the '7 days' to an arbitrary interval that meets your needs, but 7 days is the maximum for when users will get password change requests on login. To run it, copy and paste into a pgAdmin SQL window or a psql window connected to a ledgersmb database.
DO $$
DECLARE
validts timestamp;
user_row users;
BEGIN
validts := now() + '7 days'::interval;
FOR user_row IN SELECT * FROM users
LOOP
EXECUTE $E$ALTER USER $E$
|| quote_ident(user_row.username)
|| $E$ VALID UNTIL $E$ ||
quote_literal(validts);
END LOOP;
END;
$$;
--
Best Wishes,
Chris Travers
Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in.