You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2019/04/10 15:36:01 UTC
[Bug 63334] New: LockOutRealm will continue to invoke inner user
realms even when the user is lockout
https://bz.apache.org/bugzilla/show_bug.cgi?id=63334
Bug ID: 63334
Summary: LockOutRealm will continue to invoke inner user realms
even when the user is lockout
Product: Tomcat 8
Version: 8.5.x-trunk
Hardware: PC
Status: NEW
Severity: normal
Priority: P2
Component: Catalina
Assignee: dev@tomcat.apache.org
Reporter: jchobantonov@yahoo.com
Target Milestone: ----
In case the user is lockout there is no need to invoke inner realms as the
result will always be unauthenticated user
In LockOutRealm modify each authenticate method to first check if the user is
locked out - if so then return the user is locked out without invoking inner
realms
So from this:
@Override
public Principal authenticate(String username, String clientDigest,
String nonce, String nc, String cnonce, String qop,
String realmName, String md5a2) {
Principal authenticatedUser = super.authenticate(username,
clientDigest, nonce, nc, cnonce,
qop, realmName, md5a2);
return filterLockedAccounts(username, authenticatedUser);
}
To this:
@Override
public Principal authenticate(String username, String clientDigest,
String nonce, String nc, String cnonce, String qop,
String realmName, String md5a2) {
if (isLocked(username)) {
// If the user is currently locked, authentication will always fail
log.warn(sm.getString("lockOutRealm.authLockedUser", username));
return null;
}
Principal authenticatedUser = super.authenticate(username,
clientDigest, nonce, nc, cnonce,
qop, realmName, md5a2);
return filterLockedAccounts(username, authenticatedUser);
}
And that logic applied to all authenticate methods. This will prevent hitting
backend user realms in case the user is locked out because of invalid
username/password been used multiple times and the user got locked out - this
will act as denial of service attack prevention as well as most likely someone
could be trying to brute force guess user password and it will get each time
the user is locked out but the back end will be hit again and again no matter
that the result will be unauthenticated user
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 63334] LockOutRealm will continue to invoke inner user realms
even when the user is lockout
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63334
--- Comment #4 from Mark Thomas <ma...@apache.org> ---
Please read up on timing attacks.
A Map lookup following by a return will be noticeably faster than the
authentication process.
Your proposed change would enable an attacker to determine:
- if an account was locked
- how many failed attempts it takes lock an account
- how long the lock out period was
Exposing that information is considered a (minor) security vulnerability.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 63334] LockOutRealm will continue to invoke inner user realms
even when the user is lockout
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63334
--- Comment #2 from Mark Thomas <ma...@apache.org> ---
Sorry about the typo
"... in use and its configuration."
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 63334] LockOutRealm will continue to invoke inner user realms
even when the user is lockout
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63334
--- Comment #6 from Christopher Schultz <ch...@christopherschultz.net> ---
Realms aren't difficult to write, including a simple realm like the
LockOutRealm.
Feel free to implement your own Realm which meets your requirements. If you'd
like, you can propose a patch, but I don't think anyone here wants to spent the
time to scratch this particular itch.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 63334] LockOutRealm will continue to invoke inner user realms
even when the user is lockout
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63334
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
OS| |All
Resolution|--- |WONTFIX
Status|NEW |RESOLVED
--- Comment #1 from Mark Thomas <ma...@apache.org> ---
The proposed change would expose the LockOut Realm to a timing attack enabling
a malicious user to determine if the Lockout Realm was in used its
configuration.
If repeated authentication requests trigger a DoS then that is a separate issue
that requires a separate (non-Tomcat) solution.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 63334] LockOutRealm will continue to invoke inner user realms
even when the user is lockout
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63334
--- Comment #5 from jchobantonov@yahoo.com ---
Thank you for clarifying your point that attacker could determine there is a
lockout realm installed based on the speed of the request/response, although
this is questionable as if you are dealing with security systems that are in
the backend accessed using network each response could vary from few millisec
to a sec or more - so it will be hard to know if the lockout is in place or
not.
Let me put it this way - the fact that you could know there is lockout realm do
not give you advantage at all - and I think it would be just the opposite as if
you know there is lockout realm you will not try to break the system as it will
take insane amount of time for you - it just telling you that the
authentication won't be performed at all - either you provide invalid or valid
username/password it won't matter - and let's be frank here - an attacker (if
any better) will know and assume there is some lockout in place but the lockout
is there to prevent you from bombarding the server and slow you down - the
purpose is not whether or not the attacker knows about it - even Apple and
their iPhones will tell you that the phone is lockout and you should try in
couple of minutes after that - it will not tell you that the password is
invalid yet again as this only achieve confusion in your users
Back at why hitting backend security systems when you determine to lockout the
user is bad choice - some of the backend systems are actually charging you real
money for the amount of security requests made to those systems - if you are
going to block the user upfront why do I want ever to make a request to those
systems ?
If your concern is about timing and the attacker to know there is lock
mechanism in place - just put a timer and get how long it will take a regular
request to complete - then when the user is lock out do a Thread.wait () to
simulate backend processing so that the user won't suspect a different behavior
- but again even if the end user knows there is lockout, how many tries and for
how long - what you are going to do ? Although I admit that people look at this
as small security concern because you know how things at the backends works it
doesn't mean that you know how to circumvent that - and as I said a real
attacker would expect lockout even if not reported
At least put a property on LockOutRealm whether or not it should hit the inner
realms in case of lockout so that we could configure this in server.xml and not
for us to provide a new class in order to achieve that.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 63334] LockOutRealm will continue to invoke inner user realms
even when the user is lockout
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63334
--- Comment #3 from jchobantonov@yahoo.com ---
I’m sorry but the fix is not going to expose anything to the user - the end
user still is going to get unauthenticated but we are going to invoke our inner
realms like JAASRealm which is not needed at all
See how the filterLockedAccounts method works - it will invoke inner realm and
then it will check if the user is locked - if so it will return null to the
user as Principal - e.g unauthenticated - my suggestion is to just do another
upfront check if the user is locked to not invoke the inner user realms because
this will not change anything - the result will be unauthenticated and nothing
is exposed to the user that you have lovkout realm - the result is the same -
just don’t invoke inner realms unnecessary when the result will be null
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org