tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: [OT] Memory Leak in Tomcat
Date Fri, 25 Feb 2011 18:13:57 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chris,

On 2/25/2011 4:54 AM, chris derham wrote:
> 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.

True, but we were presuming that the server hasn't been configured to
allow remote users to write to the filesystem. Sure, we were making a
whole bunch of assumptions, here. :)

The original assertion was something along the lines of "cleartext
passwords in server.xml aren't secure enough". My contention is that if
your box is compromised, you're fucked either way. If you have access to
the user that runs Tomcat, you can read the password right out of
server.xml. If you have that same access, you're right: you can just
install whatever software you want into Tomcat and then have full access
to the database (well, to the extent that the database allows).

> 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.

Exactly. That's why I was saying that switching from plaintext
authentication to NTLM (or whatever) doesn't really buy you more
security. Unless you don't trust the OS's ability to protect your files
from unauthorized users, none of these strategies buy you anything other
than being able to check-off a box on some naive security checklist.

I nearly got into a yelling match with a security auditor who told me
that encryption keys and encrypted data should never be at the same
place at the same time. "How do you ever access the data, then?" I
asked. He told me that it was a "best practice" to never have the data
and the key in the same place at the same time. My brain nearly exploded.

> There is a tool http://www.jasypt.org/encrypting-configuration.html 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
> it.

Yup: moving the problem.

Thanks for your thoughts.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1n8WUACgkQ9CaO5/Lv0PDTaACcDIvTSwPotOZWq1hinX4FC7A8
0E0AoJYBOx6N/9QHa00ou4cCKNpUVaRx
=cRep
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message