[OPEN-ILS-DEV] Evergreen security releases: 2.0.10 and 1.6.1.9

[Dan Scott]

Today, the Evergreen development team released Evergreen 2.0.10 and
1.6.1.9 - available from the downloads page at
http://evergreen-ils.org/downloads - to address several security
vulnerabilities and a handful of bug fixes. This post discusses the
security vulnerabilities. If you are running Evergreen in production
today, we encourage you to upgrade your Evergreen system to 1.6.1.9 or
2.0.10 as soon as possible.

Special thanks to Thomas Berezansky who identified and provided fixes
for these issues.

* Summary of issues fixed in 2.0.10 and 1.6.1.9 *

These releases include some protection against brute force guessing of
weak passwords, such as four digit pins.

A running count of incorrect login attempts for a given user is
maintained. After ten incorrect attempts, all attempts to login as that
user will fail until the counter resets. By default, the counter resets
after 90 seconds. Both the counter and the number of incorrect passwords
are configurable. This change requires no client-side changes.

This release also includes a change which prevents the re-use of an
authentication seed to obtain more than one authentication token. This
change required a single client-side change where the staff client was
inadvertently re-using a seed legitimately.

* Additional issues fixed in 2.0.10 *

On the patron visible front there is a change to the OPAC to require
that the user’s current password be provided before changes to username
or email address can be made. This prevents someone who gains access to
another user’s account, say due to a public or otherwise shared
computer, from changing the email address and requesting a password
reset. The username change requiring the user’s password helps keep
someone from being “locked out” of their account because someone changed
their username without the user knowing.

To continue on the password related fixes there is the removal of the
password from the login screen after it is no longer needed. This
prevents malicious code injected into the staff client from obtaining
the password by pulling it out of the password entry box in plain text.
As this code is contained 100% within the local staff client a client
update is required.

* Technical details: fixes in 2.0.10 and 1.6.1.9 *

The most significant vulnerability that has been addressed was the
ability to brute force passwords. The authentication functions,
available to the world via HTTP/HTTPS, have been given protection
against repeated attempts to guess passwords. After a configurable
number of failed login attempts each within a configurable time span
from the previous failed attempt the system will treat all attempts as
failures, even if they are otherwise valid and correct. The default is
10 attempts with 90 seconds between attempts. The system will unlock
after the time between attempts has expired. This can be installed
server-side without any client side changes.

Related to brute forcing of passwords is password replay attempts. If
you can grab the auth.complete call within the auth seed’s validity
period you can re-send the auth.complete data and get a new authtoken,
without needing to know the seed or password. To protect against this
the auth seeds are rendered invalid after a single use (successful or
not). This requires a single client side change to cover the case where
the client thinks it has a registered workstation and the server
disagrees. In that case the client was, in effect, performing a replay
attack as part of normal operations.