Subject: Security Advisory: LedgerSMB < 1.3.36, Improper Logout on Some Browsers
Severity: Low (cvssv2 base score: 3.6, total 0.5)
Remotely Exploitable: No
Complexity of Attack: High
Impact: Relatively low.
Prerequisite for Attack: Physical Access to Previously Logged In Browser, so high complexity in most cases.
Attack Vector: Physical, against client.
Impact: The attacker may gain access unexpectedly to LedgerSMB using the client's previous credentials.
Background
LedgerSMB uses HTTP authentication, with credentials which are passed through to the database. This means that the web application is not trusted by the database, and has no permission to the data in the absence of actual user credentials. Logout works by setting credentials to known bad values (logout:logout) and returning these to the client. This effectively, to the extent it works, prevents the client from logging in again with the old credentials since they are cleared.
Unfortunately there is some variation in how browsers handle a request to change credentials. The RFC gives tremendous flexibiltiy to browsers as to when to reuse credentials. Firefox and some other browsers will re-use credentials until they get either a 401 error from the server or a request to use different credentials. This is the behavior that the aforementioned versions have relied upon.
Other browsers, including Chrome, do not immediately use credentials requested unless prompted by a 401 error. This means that sending a request with bad credentials won't actually send the bad credentials unless the web server sends back an error against the good credentials first. This behavior is counterintuitive for developers and a recipe for security problems, but it is at least in compliance with a technical reading of the RFC.
The result is that unpatched LedgerSMB depends effectively on client-side behavior to log out, and while this may not be ideal, it is totally consistent with HTTP being a stateless protocol (and therefore the client bears responsibility for managing authentication information). This method of logout is not supported on all browsers.
Browsers which do support a purely client-side logout include Firefox and Internet Explorer. Those that don't include Chrome. When used with the latter category, the authentication credentials remain valid until one closes the browser.
To address this, browsers like Chrome must be required to send two round trips to the server, the first to reject the good credentials and the second to accept the bad ones. Our patch, assuming proper operation of software and network, addresses this. We still believe it is safer to use browsers, such as Firefox, which support a fully client-side logout. The reason here is that if a security model requires a working network to make a logout take effect, then breakdowns in the network may introduce temporary vulnerabilities. This is, however, a fundamental problem with browsers which rely on this and cannot be fixed by web servers using stateless approaches to authentication.
Exploit
After logout (assuming that the browser is not fully closed after), go to the login screen. Leave the username and password blank. Type in the db name you want to access under the company name, click Log In, and you may be logged in if the browser authentication cache has not been cleared, or just use the back button to return to the application (as authentication data will be resubmitted on request).
Workaround/How to Mitigate
Assuming single control to each client computer, this issue has only very minor security implications. A successful attack means breaching any physical security on site. In systems where this is not the case, client-side security concerns may well eclipse any concerns this raises, which is why we have classified it as "low" in terms of severity.
The obvious mitigation techniques include switching to a browser, such as Firefox, which does support a purely client logout from http authentication.
Another mitigation technique is to close the browser after use. However this requires trusting users to do things that may not be obvious regarding security. In Chrome, in cognito windows could be used to effectively prevent this (assuming they are closed after).
Patch Availability
We have a patch available for this issue. It has not been fully regression tested, and it was committed to our public svn repository for branches/1.3 in svn revision 6518. It is included in 1.3.37 or you can pull a patch directly from svn.
Final Notes
It is worth remembering that this is an exploit which typically would be against one layer in a relatively deep area of IT defense. Attacks would require circumventing other routine aspects of IT security and therefore while we do recommend that users take the issue seriously it is not one which is expected to be particularly urgent.
Credit:
Chris Travers discovered this issue.
--
Best Wishes,
Chris Travers
Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in.