Sorry for the accidental send before. This is the corrected advisory. I
accidentally hit the send button when I didn't mean to.
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.
http://www.efficito.com/learn_more.shtml
--
Best Wishes,
Chris Travers
Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor
lock-in.
http://www.efficito.com/learn_more.shtml
------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
_______________________________________________
Ledger-smb-users mailing list
Ledger-smb-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-users
