Re: My Assessment of the Heartbleed OpenSSL bug and LedgerSMB

[ario <..hidden..>]

If I were the NSA or GCHQ, I would have _loved_ to have dropped the
developer into the OpenSSL team that coded this 'mistake'. :)

ario


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
> 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;
> $$;
> 
> 


------------------------------------------------------------------------------
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
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-users