Hi Burt,
thanks for the hint! The bug isn't in hashCode() method, but in PBKey#equals(...). The comparison isn't correct (only based on hashCode), will change this to
public boolean equals(Object obj)
{
if (obj == this)
{
return true;
}
if (!(obj instanceof PBKey))
{
return false;
}
PBKey other = (PBKey) obj;
return this.jcdAlias.equals(other.getAlias())
&& (user != null ? user.equals(other.user) : null == other.user)
&& (password != null ? password.equals(other.password) : null == other.password);
}
and change hashCode too (to reduce String concatenation)
public int hashCode()
{
if(hashCode == 0)
{
hashCode = jcdAlias.hashCode()
+ (user != null ? user.hashCode() : 0)
+ (password != null ? password.hashCode() : 0);
}
return hashCode;
}regards, Armin
BURT, RANDALL (CONTRACTOR) wrote:
Coincidentally and completely by accident, my team found a small vulnerability today in PBKey. The hashcode is calculated such that the following usernames and passwords will result in the same broker being returned from the pool:
Username: user Password: password
is the same to OJB as
Username: userp Password: assword
This only works if your application requires the user to supply database login information, the correct username/password is used before the invalid one, broker pooling is turned on, and the invalid login is used while there are still appropriate brokers in the pool.
The fix is simple, change the hashcode method in PBKey as follows:
/** * Return the hash code of this PBKey, * formed by the repository-, user-, password-name. */ public int hashCode() { if(hashCode == 0) { /* this doesn't work... hashCode = (this.jcdAlias + this.user + this.password).hashCode(); */ hashCode = (this.jcdAlias + " " + this.user + " " + this.password).hashCode(); } return hashCode; }
Sorry for no patch. We can't access OJB CVS from work.
-----Original Message----- From: Edson Carlos Ericksson Richter [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 22, 2004 5:34 AM To: OJB Users List Subject: Re: Vulnerabilities
One: jdbc-connection in .xml file has database password in plain text (besides there is workarounds) - as it's does in every tomcat install around the world... Depends where you puts your .xml files!
Two: there is no encryption over data transferred (in real, it's a database dependant protocol issue. As workaround, you could write converters that does the job).
Three: it has no clue about password bad user choices (for paranoids, huh? :-D ).
Richter
Daniel Perry escreveu:
I dont think such a list exists. What sort of security
vunerabilities are
you talking about? Due to the nature of OJB i cant think of
any security
vunerabilities it could suffer? OJB doesnt store any data
itself. Any
vunerabilities i can think of would be introduced by a
database server ojb
is using, the JVM, the OS, the filesystem, or the
application that is using
OJB.
I think the only obvious security vunerability is that
(normally) you have
the database server username and password in the plaintext
repository file.
This is a problem with all If you set the file permissions
properly, no one
can access this.
Daniel.
-----Original Message----- From: Pulat Yunusov [mailto:[EMAIL PROTECTED] Sent: 21 December 2004 22:29 To: OJB Users List Subject: Vulnerabilities
Is there a list of OJB security vulnerabilities: current
and closed? Is
this information regularly collected or posted and where,
in this list?
Thank you,
Pulat
------------------------------------------------------------
---------
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Edson Carlos Ericksson Richter MGR Informática Ltda. Fones: 3347-0446 / 9259-2993
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
