Security advisory, LedgerSMB 1.3.0-1.3.36

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.