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 <chris.trav...@gmail.com> 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 Ledger-smb-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-users
