tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: [OT] Memory Leak in Tomcat
Date Thu, 24 Feb 2011 22:12:12 GMT
Jeffrey Janner wrote:
>> -----Original Message-----
>> From: André Warnier []
>> Sent: Thursday, February 24, 2011 3:43 AM
>> To: Tomcat Users List
>> Subject: Re: [OT] Memory Leak in Tomcat
>> Jeffrey Janner wrote:
>> ..
>>> Not sure exactly what Windows does once you've entered a verified
>> user/pw combination for a service.  I'm guessing that it stores the
>> password somehow, because if you change the password, the service won't
>> start next time.
>> It is stored in whatever format, encrypted or not or hashed or not, in
>> whatever store the
>> Domain Controller uses to store user credentials.
>> It doesn't matter.
>> NTLM authentication afterward works using "tokens" which somehow encode
>> the information
>> needed by a server to verify that the client is who it says it is, and
>> the server is who
>> it says it is.
>> The point is that the password is not stored in clear on the client,
>> when "client" means
>> whatever host is trying to authenticate itself.  It is of coursee
>> fleetingly in memory at
>> some point, to construct the authentication tokens, but is not kept.
>> Only the token is kept.
>>> However, this is a "nice" (?) feature of using SQL Server.  Already
>> validated user credentials can be passed by the OS to SQL Server to be
>> validated for database logon.  It's their version of SSO for the
>> database. (Note: I don't find it an overwhelming advantage for
>> determining to use that specific database software.)
>> No it isn't, not in this case.
>> in the current scenario, the "user" for which there is SSO is the user-
>> id under which the
>> Tomcat process itself is running.  It is /not/ the users which connect
>> to Tomcat and run
>> the applications.
>> All these users connect to Tomcat, and are or not authenticated using
>> whatever method
>> Tomcat implements.
>> But then, the credentials used to connect to the database are the
>> credentials of the
>> Tomcat process, not the ones of the users.
>> That is why is was questioning how much in fact of a security this
>> brings.
>> The problem is merely moved, to the level of how users authenticate
>> with the Tomcat
>> application. Once they have done that, they can access any information
>> which is accessible
>> by this Tomcat user.
> Isn't that the point of authentication in the application/Tomcat?  (Note, I'm intentionally
misinterpreting your use of the term "Tomcat user" here, as you seem to be mixing the different
authentication levels in your argument.)
> Here's the proper setup the OP is attempting to implement:
> 1: End user's authenticate the application using whatever method they deem necessary.
> 2: Tomcat/application authenticates to SQL Server either via plaintext uid & pw stored
in XML file, or via SSO token derived from Tomcat process login.
> The differences:
> a) The plaintext is available rather easily to anyone who can access said XML file, either
via Tomcat or some other means.  Those credentials can be used to launch an attack on the
DB from the Tomcat server, or any other server. 
> b) The SSO is available directly iff the attacker manages to crash Tomcat or infect it
and the attack must take place via the Tomcat process.
> c) It is probably possible to grab the Windows SSO token used by the Tomcat process by
locating it on disk and somehow making it useable for attacking the SQL Db.  I don't tread
too deeply in the security waters, but I think that would have made big news if it was easy.
> Note:  I'm not particularly trying to argue that this is an "ultimately secure" mechanism
for authenticating Tomcat to the SQL Server database.  But it does allow the checking of the
box next to "No passwords stored in cleartext" line on the security gestapo's checklist.

I agree with all of the above, and maybe I did not say it clearly, but that is also what I


1) authenticating the Tomcat process to the DB system by means of an NTLM-based 
authentication, is a degree more secure than via a clear-text userid/password combination,

because it this last case, the userid/password combination have to be stored somewhere on

the Tomcat server in clear.

2) this however, by itself, does /not/ provide a Single-Sign-On capability for the users,

at least not vis-a-vis the DB system.  A true user-level SSO would have the *user* 
credentials being used to authenticate to the DB system, which is not the case here.
The only user authenticatiing to the DB system, is whatever user-id Tomcat runs under.

3) This is what I meant by "merely displacing the issue" : whichever user is "accepted" by

Tomcat can now use the Tomcat applications to access the contents of the database.  That 
is because Tomcat is authenticated to the DB system, and all accesses to the DB are made 
by Tomcat under its own user-id.
So now the issue is : how (and even if) the users authenticate to Tomcat.
(The OP did not mention that part).

Let me give a stupid example : imagine that Tomcat authenticates users by means of the 
conf/tomcat-users.xml file.
Then getting hold of /that/ file would allow anyone to login to Tomcat, and automatically

gain access to the database (through the Tomcat applications) without any further check.

Also, because there in fact a single user (Tomcat) accessing the DB system, on behalf of 
multiple real users, the type of access granted in the DB system to this "Tomcat user" 
must by force be very broad.  In other words, if 99% of the users of the Tomcat 
applications need only read access to some information, but 1% of these users need also 
write access to it, you will have to give the "Tomcat user" r/w access.
Which means that now the only way of preventing the other 99% to write there, is to do it

at the application level.

4) a real secure system (and SSO mechanism) would have the users authenticating to Tomcat

via a secure method, and the Tomcat application using those same user credentials to 
authenticate to the DB system on behalf of the user.
This way, the DB system would know who is accessing it, and be able to grant access or not

to selective information, based on who the user is.

But from what I understand, that is not what the OP's jDTS/ntlmauth.dll combination does.
It does obtain the "Tomcat user" credentials, and logs in to the DB system using those.

On the other hand, a servlet filter like Jespa authenticates the real user accessing the 
Tomcat application, and allows the Tomcat application to use these credentials to 
authenticate to a further service.

It is another philosophy and another kind of setup, and I am sure that there is room in 
this world for both of them.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message