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.
http://www.efficito.com/learn_more
------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
Ledger-smb-users mailing list
Ledger-smb-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-users
