[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: My Assessment of the Heartbleed OpenSSL bug and LedgerSMB
- Subject: Re: My Assessment of the Heartbleed OpenSSL bug and LedgerSMB
- From: ario <..hidden..>
- Date: Thu, 10 Apr 2014 15:01:46 +0000
If I were the NSA or GCHQ, I would have _loved_ to have dropped the
developer into the OpenSSL team that coded this 'mistake'. :)
On Thu, 10 Apr 2014 01:14:07 -0700
Chris Travers <..hidden..> wrote:
> 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
> 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
> 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 $$
> validts timestamp;
> user_row users;
> validts := now() + '7 days'::interval;
> FOR user_row IN SELECT * FROM users
> EXECUTE $E$ALTER USER $E$
> || quote_ident(user_row.username)
> || $E$ VALID UNTIL $E$ ||
> END LOOP;
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.
Ledger-smb-users mailing list