tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From chris derham <>
Subject Re: [OT] Memory Leak in Tomcat
Date Fri, 25 Feb 2011 09:54:34 GMT

I've only been on this mailing list for a couple of weeks, so am still not
quite sure of the etiquette. I know people get upset about top posting or
replying to an existing email and changing the subject only. Not sure about
the intricacies of when people should attempt to help others on the list. I
assume anybody can chip in at anytime - please let me know otherwise.

Having said this, I can't bear to see this thread anymore without chipping
in. I understood from the original post that this inquiry was about a
problem whereby a move from having db credentials stored in tomcat config to
having windows service credentials used to log into the database. Once this
happened, a memory leak occurred. Some suggestions were made as to how to
track this down, and since then the thread has drifted into a discussion
about the merits of this approach, and now seems to be tittering on the edge
of a discussion about the merits of true SSO. I just wanted to address the
first two points.

The posts indicate that the service was run as local system. Moving to a
domain user to make things simpler doesn't really add up for me. You've now
exposed the whole network to the hacker - if they can break into the tomcat
process, any action they perform will potentially have access to any network
resource as the process is a domain user. The OP didn't detail the topology
of the network, and if the webserver is on a DMZ with a firewall between it
and the rest of the network. This may or not be more worrying than having
the ability to read the password.

If a hacker gets onto your webserver, there are a couple of scenarios.
Either they break into the tomcat process and are constrained in it, or get
full control of the whole server. The thought process of all people
discussing this on this thread is that if they can read the password to the
db, they can then get into the database and do bad things. Hackers are
human, and as such lazy. It is far simpler to craft a fairly simple jsp
page, that allows posting arbitrary SQL to the same jsp, which then asks
tomcat for a connection, and then runs the SQL and displays the results.
Doesn't matter how you store the password/token to access the database, once
this jsp is in place they still got the ability to execute arbitrary SQL. So
any discussions about which method is better to store the password are
something of a moot point.

Security recommendations suggest that you should secure the db to least
privs. So the db should only accept connections from the webserver IP. So
the ability to read the password really isn't such a big thing - if they can
read it, they can only access the db from the webserver.

Security recommendations suggest that you should secure the webserver to run
tomcat with least privs. If you store username and password using plain
text, you can run the service as a dedicated local user on the machine. When
configured correctly, this will constrain what the hackers can do if they
break into the tomcat process - e.g. they can only access tomcat files and
no other files on the webserver. This is less risk than running as a domain
account IMHO

> I trust the people in the company, but the company's work is with sites
> any user all over the internet can access. so we want to perform a damage
> control if some hacker would gain access to our web server, so if he can -
> he won't get access to the DB, at least not with our help of displaying
> user and password to access the DB :].

So secure these other sites, such that they can't access this website. e.g.
run the other sites as local user A and run your site as local user B. That
way your concern is potentially mitigated, as long as the hacker only takes
control of the other sites process. An alternative would be to separate the
two sets of sites, either on separate physical machines, or using a virtual
machine and a physical machine, or multiple virtual machines. That way if
they break into these other sites, they won't have access to your site or
its configuration.

There is a tool which
allows you to store the configuration information in an encrypted form. I
mention it as this might appease some less technical/ceo/manager type people
and it might help you to tick any security check list that says "no
passwords in clear text". However  be sure to understand this won't make
your site any more secure. If someone can obtain access to the config file
containing plain text password, when the setting is encrypted they would
still be able to access the encrypted one and find the key used to unencrypt

Hope that helps


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message