Re: [OT] Memory Leak in Tomcat
Security seems to be always in the hands of the wrong people. No need for insults here, this is a new requirement which I'm not familiar with, and that's why I asked you guys.. Instead of the JTDS, can I use Tomcat Spengo? will it provide same results, as using a domain user for the tomcat windows service, and removing user and password from xml configuration file under conf/catalina/localhost ? Thanks Hila 2011/3/2 Jorge Medina cerebrotecnolog...@gmail.com I got a good laugh with your message. Security seems to be always in the hands of the wrong people. Once I asked for the algorithm used to hash the passwords (that happened to be HMAC SHA-1) into a database, if I was going to authenticate the users, I needed to use the same algorithm. I did not ask for the key used to salt the hash, I could put that as a parameter to be provided at install time and use any other key during development and testing. My request was rejected until authorized by a manager two levels up! sigh (All I needed to know was HMAC SHA-1!) On Mon, Feb 28, 2011 at 11:02 AM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 הילה, On 2/28/2011 5:17 AM, הילה wrote: How can I encrypt the password inside the xml file? 0. $file = conf/server.xml 1. Use your favorite encryption tool to encrypt the password and shove it into $file 2. Use that same tool in some code you hack-into Tomcat to read it back out. 3. Store the key to your favorite-tool encryption package in another file (say, s3cr3t.key) 4. $file = s3cr3t.key 5. Go to step 1. Repeat this process until you feel like you're safe. (Hint: you are still not safe). Scratch that: repeat this process until your boss or your auditor feel like they are safe. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1rxwwACgkQ9CaO5/Lv0PCtGQCgtxVxV9+N0AvRuYw0U6mi9ki1 ikgAn1xQNqRRtSKby531xKRHizxzEFwD =uuFd -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Memory Leak in Tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 הילה, On 3/6/2011 4:49 AM, הילה wrote: Security seems to be always in the hands of the wrong people. No need for insults here, this is a new requirement which I'm not familiar with, and that's why I asked you guys.. I don't think Jorge was trying to make a disparaging comment about you, here. Instead, I think he was trying to point out that often, the people who are making the security decisions are removed enough from the actual technology that they don't really understand what they're doing. In fact, I apologize if my exasperation at your task seems directed at you: I merely wanted you to acknowledge that your task was ultimately no more secure than a cleartext password in a file with proper permissions. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk10O1sACgkQ9CaO5/Lv0PDjMQCdGXpS9t1YQMRDQykys8rPopLe TjEAn3exSJM773TZnlIZkU6UW3XbhJFm =c2B9 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Memory Leak in Tomcat
Thanks :] This was the task I was required to do, wit no question asked, cause this is a requirement for our application to pass some major barriers. so.. :] Hila 2011/3/7 Christopher Schultz ch...@christopherschultz.net -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 הילה, On 3/6/2011 4:49 AM, הילה wrote: Security seems to be always in the hands of the wrong people. No need for insults here, this is a new requirement which I'm not familiar with, and that's why I asked you guys.. I don't think Jorge was trying to make a disparaging comment about you, here. Instead, I think he was trying to point out that often, the people who are making the security decisions are removed enough from the actual technology that they don't really understand what they're doing. In fact, I apologize if my exasperation at your task seems directed at you: I merely wanted you to acknowledge that your task was ultimately no more secure than a cleartext password in a file with proper permissions. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk10O1sACgkQ9CaO5/Lv0PDjMQCdGXpS9t1YQMRDQykys8rPopLe TjEAn3exSJM773TZnlIZkU6UW3XbhJFm =c2B9 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Memory Leak in Tomcat
I got a good laugh with your message. Security seems to be always in the hands of the wrong people. Once I asked for the algorithm used to hash the passwords (that happened to be HMAC SHA-1) into a database, if I was going to authenticate the users, I needed to use the same algorithm. I did not ask for the key used to salt the hash, I could put that as a parameter to be provided at install time and use any other key during development and testing. My request was rejected until authorized by a manager two levels up! sigh (All I needed to know was HMAC SHA-1!) On Mon, Feb 28, 2011 at 11:02 AM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 הילה, On 2/28/2011 5:17 AM, הילה wrote: How can I encrypt the password inside the xml file? 0. $file = conf/server.xml 1. Use your favorite encryption tool to encrypt the password and shove it into $file 2. Use that same tool in some code you hack-into Tomcat to read it back out. 3. Store the key to your favorite-tool encryption package in another file (say, s3cr3t.key) 4. $file = s3cr3t.key 5. Go to step 1. Repeat this process until you feel like you're safe. (Hint: you are still not safe). Scratch that: repeat this process until your boss or your auditor feel like they are safe. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1rxwwACgkQ9CaO5/Lv0PCtGQCgtxVxV9+N0AvRuYw0U6mi9ki1 ikgAn1xQNqRRtSKby531xKRHizxzEFwD =uuFd -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Memory Leak in Tomcat
continue to the discussion- How can I encrypt the password inside the xml file? Thanks Hila בתאריך 27 בפברואר 2011 19:37, מאת הילה hilavalen...@gmail.com: Original: Does this happen all the time? Under what conditions? Are you able to build a patched version of Tomcat in a test environment to test a fix I have? What version of Java and Tomcat are you running? Hey I'm not sure if you refer the question to me, since the whole topic shifted to an off topic :] But yes, it happens all the time. what do you mean under what conditions? As I specified in my first mail, it happens when I implement windows authentication on tomcat I use tomcat 6.0.29 , on OS win server 2008 R2 standard, JDK 1.6 Build 23 If you have a fix, I'll happy to try it on our test environment. Thanks Hila 2011/2/25 Christopher Schultz ch...@christopherschultz.net -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, On 2/25/2011 10:47 AM, André Warnier wrote: [Thread hijacking] is more annoying, because quite a few people have their client set to display messages by thread (a hierarchical display where messages neatly appear under the ones they respond to, instead of just chronologically). The client classifies new messages as being part of a thread using information contained in other headers within the message (kind of a refers to thing). These headers are automatically added by the list server. So when you respond to an existing message and change the subject, for these people an unrelated message suddenly appears inside a discussion tree where your new message does not belong. Worse are mail clients who think that subject and thread are interchangeable: the thread-id in the SMTP headers is ignored and instead the subject is used to thread things. That way, two things happen: 1. People who hijack threads can't tell and get all angry when we tell them they hijacked the thread 2. Legitimate thread-subject-changes (such as adding [OT] or whatever) end up showing-up in what looks like a separate thread. Please do [chip in]. That's the point of this list. Specially interventions like yours, which is civil, well-written and brings valuable information and insights. Mostly everyone here will ignore most of the list-etiquette rules and remain civil if you have something worthwhile to say. Top-posting is only irritating when it looks like this: Reply: Yes, no, and maybe. There are other times this happens. 1.6. 5.something. Original: Does this happen all the time? Under what conditions? Are you able to build a patched version of Tomcat in a test environment to test a fix I have? What version of Java and Tomcat are you running? Since Chris's post had actual content and didn't really have a point-counterpoint feel to it, top-posting can be forgiven :) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1n8uwACgkQ9CaO5/Lv0PDHNQCfXscF1JWtPIXeu3DMzLgFbg/A CmYAnA/117/lOPYzoKPvU9DOX29BeEFS =Xzcc -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [OT] Memory Leak in Tomcat
From: הילה [mailto:hilavalen...@gmail.com] Subject: Re: [OT] Memory Leak in Tomcat How can I encrypt the password inside the xml file? Short answer: pointless exercise. Long answer: search the archives. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
Re: [OT] Memory Leak in Tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 הילה, On 2/28/2011 5:17 AM, הילה wrote: How can I encrypt the password inside the xml file? 0. $file = conf/server.xml 1. Use your favorite encryption tool to encrypt the password and shove it into $file 2. Use that same tool in some code you hack-into Tomcat to read it back out. 3. Store the key to your favorite-tool encryption package in another file (say, s3cr3t.key) 4. $file = s3cr3t.key 5. Go to step 1. Repeat this process until you feel like you're safe. (Hint: you are still not safe). Scratch that: repeat this process until your boss or your auditor feel like they are safe. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1rxwwACgkQ9CaO5/Lv0PCtGQCgtxVxV9+N0AvRuYw0U6mi9ki1 ikgAn1xQNqRRtSKby531xKRHizxzEFwD =uuFd -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Memory Leak in Tomcat
Original: Does this happen all the time? Under what conditions? Are you able to build a patched version of Tomcat in a test environment to test a fix I have? What version of Java and Tomcat are you running? Hey I'm not sure if you refer the question to me, since the whole topic shifted to an off topic :] But yes, it happens all the time. what do you mean under what conditions? As I specified in my first mail, it happens when I implement windows authentication on tomcat I use tomcat 6.0.29 , on OS win server 2008 R2 standard, JDK 1.6 Build 23 If you have a fix, I'll happy to try it on our test environment. Thanks Hila 2011/2/25 Christopher Schultz ch...@christopherschultz.net -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, On 2/25/2011 10:47 AM, André Warnier wrote: [Thread hijacking] is more annoying, because quite a few people have their client set to display messages by thread (a hierarchical display where messages neatly appear under the ones they respond to, instead of just chronologically). The client classifies new messages as being part of a thread using information contained in other headers within the message (kind of a refers to thing). These headers are automatically added by the list server. So when you respond to an existing message and change the subject, for these people an unrelated message suddenly appears inside a discussion tree where your new message does not belong. Worse are mail clients who think that subject and thread are interchangeable: the thread-id in the SMTP headers is ignored and instead the subject is used to thread things. That way, two things happen: 1. People who hijack threads can't tell and get all angry when we tell them they hijacked the thread 2. Legitimate thread-subject-changes (such as adding [OT] or whatever) end up showing-up in what looks like a separate thread. Please do [chip in]. That's the point of this list. Specially interventions like yours, which is civil, well-written and brings valuable information and insights. Mostly everyone here will ignore most of the list-etiquette rules and remain civil if you have something worthwhile to say. Top-posting is only irritating when it looks like this: Reply: Yes, no, and maybe. There are other times this happens. 1.6. 5.something. Original: Does this happen all the time? Under what conditions? Are you able to build a patched version of Tomcat in a test environment to test a fix I have? What version of Java and Tomcat are you running? Since Chris's post had actual content and didn't really have a point-counterpoint feel to it, top-posting can be forgiven :) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1n8uwACgkQ9CaO5/Lv0PDHNQCfXscF1JWtPIXeu3DMzLgFbg/A CmYAnA/117/lOPYzoKPvU9DOX29BeEFS =Xzcc -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Memory Leak in Tomcat
All, 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 that 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 the 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 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. Hope that helps Chris
Re: [OT] Memory Leak in Tomcat
chris derham wrote: All, 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 I think that's more a matter of personal preference. It makes it a bit harder sometimes to connect a response with the original question, because you have to scroll etc.. or replying to an existing email and changing the subject only. That is more annoying, because quite a few people have their client set to display messages by thread (a hierarchical display where messages neatly appear under the ones they respond to, instead of just chronologically). The client classifies new messages as being part of a thread using information contained in other headers within the message (kind of a refers to thing). These headers are automatically added by the list server. So when you respond to an existing message and change the subject, for these people an unrelated message suddenly appears inside a discussion tree where your new message does not belong. (And you'll probably be ignored, except for a short don't hijack threads injunction). Thus, if you respond to an existing message, hitting the reply button is OK. If you write a message about a new subject, then don't do that. Create a new message, with a new subject, and address it to the list. It will then become the top of a new thread. 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. Please do. That's the point of this list. Specially interventions like yours, which is civil, well-written and brings valuable information and insights. 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. That's why someone at some point changed the subject to add the [OT] (Off-Topic) marker. That's a case by the way where changing the subject is ok, because it still somehow belongs to the same thread. 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. You're right, and I didn't even think of that aspect. 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. Not of everyone. But it seemed to be the thought process of the OP. 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. Agreed. 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 Totally agreed. I must say that I generally dislike the OP's whole setup, for the reason that the DB is now incapable of distinguishing one real user from the other,
RE: [OT] Memory Leak in Tomcat
Chris - Thanks for adding some more well-thought-out reasoning to this discussion. You've pointed out some issues that the rest of us had addressed, or even thought about, and pointing out that real security is always about more than just the simplified checkbox requirements that some security wonkos live by. This plaintext password discussion happens on this list about once every other month on this list in response to someone querying about it. The argument usually comes down to if the hacker can read the config file, you've already got bigger problems. You've actually added some points that I've not seen before that deserve some serious consideration. Kudos. Jeff p.s. top-posting because it's a commentary on all that follows. You don't have to read to the bottom to see my minor comments. -Original Message- From: cjder...@gmail.com [mailto:cjder...@gmail.com] On Behalf Of chris derham Sent: Friday, February 25, 2011 3:55 AM To: Tomcat Users List Subject: Re: [OT] Memory Leak in Tomcat All, 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 that 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 the 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
Re: [OT] Memory Leak in Tomcat
-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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Memory Leak in Tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, On 2/25/2011 10:47 AM, André Warnier wrote: [Thread hijacking] is more annoying, because quite a few people have their client set to display messages by thread (a hierarchical display where messages neatly appear under the ones they respond to, instead of just chronologically). The client classifies new messages as being part of a thread using information contained in other headers within the message (kind of a refers to thing). These headers are automatically added by the list server. So when you respond to an existing message and change the subject, for these people an unrelated message suddenly appears inside a discussion tree where your new message does not belong. Worse are mail clients who think that subject and thread are interchangeable: the thread-id in the SMTP headers is ignored and instead the subject is used to thread things. That way, two things happen: 1. People who hijack threads can't tell and get all angry when we tell them they hijacked the thread 2. Legitimate thread-subject-changes (such as adding [OT] or whatever) end up showing-up in what looks like a separate thread. Please do [chip in]. That's the point of this list. Specially interventions like yours, which is civil, well-written and brings valuable information and insights. Mostly everyone here will ignore most of the list-etiquette rules and remain civil if you have something worthwhile to say. Top-posting is only irritating when it looks like this: Reply: Yes, no, and maybe. There are other times this happens. 1.6. 5.something. Original: Does this happen all the time? Under what conditions? Are you able to build a patched version of Tomcat in a test environment to test a fix I have? What version of Java and Tomcat are you running? Since Chris's post had actual content and didn't really have a point-counterpoint feel to it, top-posting can be forgiven :) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1n8uwACgkQ9CaO5/Lv0PDHNQCfXscF1JWtPIXeu3DMzLgFbg/A CmYAnA/117/lOPYzoKPvU9DOX29BeEFS =Xzcc -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Memory Leak in Tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeffrey, On 2/25/2011 11:13 AM, Jeffrey Janner wrote: Thanks for adding some more well-thought-out reasoning to this discussion. You've pointed out some issues that the rest of us had addressed, or even thought about, and pointing out that real security is always about more than just the simplified checkbox requirements that some security wonkos live by. I'm wondering if any of this discussion can be rolled-into this page: http://wiki.apache.org/tomcat/FAQ/Password - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1n86cACgkQ9CaO5/Lv0PBGRgCfYp8UMuQViRiASnFpSP3Mi7Kx uioAoKKPaQNKpvEK8B/augWw5mZFURO4 =99Tv -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Memory Leak in Tomcat
I know it has its advantages, that's why I used it :] but if the memory leak will continue, and I won't figure it out, I think I'd have to start looking for alternate possibilities Thanks Hila 2011/2/24 Jeffrey Janner jeffrey.jan...@polydyne.com -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Wednesday, February 23, 2011 10:11 AM To: Tomcat Users List Subject: Re: [OT] Memory Leak in Tomcat -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 הילה, On 2/23/2011 10:51 AM, הילה - צוות אגורה wrote: the user that runs the tomcat service is a domain user, but I specify the user name and password of this user under log on tab on the service properties. it's not a problem since the password is encrypted, but in the xml file it's in clear text. It's a good thing those credentials don't need to be decrypted in order to be used. Congratulations: you've covered your ass. 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. 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.) __ Confidentiality Notice: This Transmission (including any attachments) may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this transmission in error, please immediately reply to the sender or telephone (512) 343-9100 and delete this transmission from your system.
Re: [OT] Memory Leak in Tomcat
I'll try to check what you suggested. sounds like something that maybe shed some light on this issue. Thanks :] 2011/2/23 André Warnier a...@ice-sa.com הילה wrote: Yes, I've read you other mail about the Jprofiler. I've run the Jprofiler for a weak until it generated a stuck process on the DB and crashed the application (even though it ran on the app server, and not the DB server) I'm not too familiar with Tomcat tweaks and java monitoring, so i'll try to go over your mail again and see if I can extract from it something that I can work with :] I hate to barge in (again?) in what is starting to look like a nice slinging match, but I think that we have already pretty much established that the memory leak, if any, happens in the jDTS (?) driver and/or the ntlmauth.dll that it is using, and not in Tomcat code. If it is in the ntlmauth.dll, I doubt that any Java tool will show anything. הילה, how exactly are you seeing that the Tomcat process is leaking memory ? With the MS Task Manager ? And, where exactly does that ntlmauth.dll come from ? @Chris : Apparently, the database being used accepts either plain text authentication, or NTLM authentication. And apparently also, the setup is such that in either case, the login to the database is done using a single user-id, provided by Tomcat. One can discuss if this is, in the general scheme of things, an appropriate way in terms of security of access to the data in the database. But in the case of plain text authentication, the user-id and password used are stored in a Tomcat configuration file, in plain text. In the case of the NTLM authentication, the user-id under which tomcat runs can be easily discovered, but the password cannot. So I would think that in that limited sense, using NTLM offers an improvement. Now of course if at the same time, a bug in the jDTS driver or the ntlmauth.dll causes the Tomcat process to need more and more memory over time, the advantage is less evident. To nevertheless make some progress at identifying the culprit, I suggest the following procedure : Leave the user-id under which Tomcat itself is running as it is, using the Windows Domain user. Also leave the database as it is. But change back the authentication used for the database, to the plain-text setting. This way, the jDTS driver will still be there, but it will no longer be using the additional dll, and will authenticate to the DB with the plain-text user-id and password. Then check if the Tomcat process is still leaking memory. If it is not, then you know for sure that the leak is in ntlmauth.dll (or in the jDTS driver, but only when it using NTLM authentication). - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Memory Leak in Tomcat
On 24 February 2011 09:42, André Warnier a...@ice-sa.com wrote: 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. André, I'd be interested in how you arrived at these assertions. In particular, I don't believe your first sentence. I can start a service that logs on as a domain account when my domain member (a laptop) is not connected to the domain. Therefore the domain member is storing something somewhere, not just the DC. And any time something is stored somewhere it is subject to attack, as the Linux-based tools for changing Windows administrator passwords demonstrate rather well - Windows may not allow direct SAM hive access, but a foreign OS has no such compunctions. This is all a long way from the original subject, of course. I routinely use SSPI authentication to SQL Server when I can do, as it does reduce the attack surface somewhat. SSPI generally makes it harder for an attacker to retrieve the credentials used to authenticate a database client to SQL Server. It makes no difference to any attack that subverts the client directly in order to attack through an existing or client-created new connection, of course. - Peter
RE: [OT] Memory Leak in Tomcat
-Original Message- From: André Warnier [mailto:a...@ice-sa.com] 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. __ Confidentiality Notice: This Transmission (including any attachments) may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this transmission in error, please immediately reply to the sender or telephone (512) 343-9100 and delete this transmission from your system.
RE: [OT] Memory Leak in Tomcat
-Original Message- From: peter.crowth...@googlemail.com [mailto:peter.crowth...@googlemail.com] On Behalf Of Peter Crowther Sent: Thursday, February 24, 2011 3:57 AM To: Tomcat Users List Subject: Re: [OT] Memory Leak in Tomcat On 24 February 2011 09:42, André Warnier a...@ice-sa.com wrote: 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. André, I'd be interested in how you arrived at these assertions. In particular, I don't believe your first sentence. I can start a service that logs on as a domain account when my domain member (a laptop) is not connected to the domain. Therefore the domain member is storing something somewhere, not just the DC. And any time something is stored somewhere it is subject to attack, as the Linux-based tools for changing Windows administrator passwords demonstrate rather well - Windows may not allow direct SAM hive access, but a foreign OS has no such compunctions. The local Windows OS caches logon credentials and does a local authentication iff the domain controller is not available -- specifically for the purpose of allowing logins in that case. Those credentials are stored somewhere on disk (probably somewhere under C:\Windows\security, or perhaps in the registry), and potentially usable by an attacker. However, if the credentials cannot be verified by other networked machines, those systems are supposed to reject them. My original point was that I don't know the mechanism for storing credentials in the Services. It appears that they are store in the registry, but I cannot tell if they are encryptions of the credentials themselves or the token returned from authentication. In either case, if you change the password on the domain, you have to change it on the service or it won't start. This is all a long way from the original subject, of course. I routinely use SSPI authentication to SQL Server when I can do, as it does reduce the attack surface somewhat. SSPI generally makes it harder for an attacker to retrieve the credentials used to authenticate a database client to SQL Server. It makes no difference to any attack that subverts the client directly in order to attack through an existing or client-created new connection, of course. - Peter p.s. before the spell-check nazi's comment on it, the iff above was intentional. __ Confidentiality Notice: This Transmission (including any attachments) may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this transmission in error, please immediately reply to the sender or telephone (512) 343-9100 and delete this transmission from your system. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Memory Leak in Tomcat
Jeffrey Janner wrote: -Original Message- From: André Warnier [mailto:a...@ice-sa.com] 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. Hi. I agree with all of the above, and maybe I did not say it clearly, but that is also what I meant. 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
Re:[OT] Memory Leak in Tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 הילה, On 2/23/2011 10:29 AM, הילה wrote: I trust the people in the company, but the company's work is with sites that 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 the user and password to access the DB :]. I'm curious as to how your webapp can connect to a database without credentials. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1lKRwACgkQ9CaO5/Lv0PA9/gCgm7sqTh9ReZ9LXr9gYj9pbYpt lIsAni8xXRsB/v/JyQNNSmvkoFI3aUjz =15dg -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Memory Leak in Tomcat
I've explained it in my mail :] change the user that runs the tomcat service to a domain user with permissions to the DB place ntlmauth.dll (from jtds-1.2.5 package) under c:\windows\system32 place jtds-1.2.5.jar (from jtds-1.2.5 package) in the tomcat 6.0\lib folder and it works. :] 2011/2/23 Christopher Schultz ch...@christopherschultz.net -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 הילה, On 2/23/2011 10:29 AM, הילה wrote: I trust the people in the company, but the company's work is with sites that 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 the user and password to access the DB :]. I'm curious as to how your webapp can connect to a database without credentials. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1lKRwACgkQ9CaO5/Lv0PA9/gCgm7sqTh9ReZ9LXr9gYj9pbYpt lIsAni8xXRsB/v/JyQNNSmvkoFI3aUjz =15dg -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Memory Leak in Tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 הילה, On 2/23/2011 10:38 AM, הילה wrote: I've explained it in my mail :] change the user that runs the tomcat service to a domain user with permissions to the DB So the domain user is password-less? How does the service start without credentials? I'm not actually stupid: I'm just asking stupid questions to lead you to the conclusion that the credentials are in fact somewhere. Just because you can't see them (Windows has them hidden somewhere) doesn't mean they're not there. You are just moving the problem somewhere else. This problem is discussed seasonally around here. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1lLB8ACgkQ9CaO5/Lv0PA87wCfdhGwBHUiutC766MH+8x5g6Zy NfIAoJkUCY7ZPD8EKEJvkdZHkTEEs6cj =+Vwc -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Memory Leak in Tomcat
Hey, the user that runs the tomcat service is a domain user, but I specify the user name and password of this user under log on tab on the service properties. it's not a problem since the password is encrypted, but in the xml file it's in clear text. so.. the problem for me is the memory leak that generated after switching to windows authentication. 2011/2/23 Christopher Schultz ch...@christopherschultz.net -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 הילה, On 2/23/2011 10:38 AM, הילה wrote: I've explained it in my mail :] change the user that runs the tomcat service to a domain user with permissions to the DB So the domain user is password-less? How does the service start without credentials? I'm not actually stupid: I'm just asking stupid questions to lead you to the conclusion that the credentials are in fact somewhere. Just because you can't see them (Windows has them hidden somewhere) doesn't mean they're not there. You are just moving the problem somewhere else. This problem is discussed seasonally around here. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1lLB8ACgkQ9CaO5/Lv0PA87wCfdhGwBHUiutC766MH+8x5g6Zy NfIAoJkUCY7ZPD8EKEJvkdZHkTEEs6cj =+Vwc -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Memory Leak in Tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 הילה, On 2/23/2011 10:51 AM, הילה - צוות אגורה wrote: the user that runs the tomcat service is a domain user, but I specify the user name and password of this user under log on tab on the service properties. it's not a problem since the password is encrypted, but in the xml file it's in clear text. It's a good thing those credentials don't need to be decrypted in order to be used. Congratulations: you've covered your ass. so.. the problem for me is the memory leak that generated after switching to windows authentication. Yup. Let's get back to that. See my other post about working with JProfiler. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1lMawACgkQ9CaO5/Lv0PAKpQCfeM8Qb+ixI0U+o6vukJDEAgIa LuYAoKz94msoMkU2+lCJ+mgY2iVvAuEH =Q9Rk -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Memory Leak in Tomcat
Yes, I've read you other mail about the Jprofiler. I've run the Jprofiler for a weak until it generated a stuck process on the DB and crashed the application (even though it ran on the app server, and not the DB server) I'm not too familiar with Tomcat tweaks and java monitoring, so i'll try to go over your mail again and see if I can extract from it something that I can work with :] Thanks Hila 2011/2/23 Christopher Schultz ch...@christopherschultz.net -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 הילה, On 2/23/2011 10:51 AM, הילה - צוות אגורה wrote: the user that runs the tomcat service is a domain user, but I specify the user name and password of this user under log on tab on the service properties. it's not a problem since the password is encrypted, but in the xml file it's in clear text. It's a good thing those credentials don't need to be decrypted in order to be used. Congratulations: you've covered your ass. so.. the problem for me is the memory leak that generated after switching to windows authentication. Yup. Let's get back to that. See my other post about working with JProfiler. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1lMawACgkQ9CaO5/Lv0PAKpQCfeM8Qb+ixI0U+o6vukJDEAgIa LuYAoKz94msoMkU2+lCJ+mgY2iVvAuEH =Q9Rk -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Memory Leak in Tomcat
הילה wrote: Yes, I've read you other mail about the Jprofiler. I've run the Jprofiler for a weak until it generated a stuck process on the DB and crashed the application (even though it ran on the app server, and not the DB server) I'm not too familiar with Tomcat tweaks and java monitoring, so i'll try to go over your mail again and see if I can extract from it something that I can work with :] I hate to barge in (again?) in what is starting to look like a nice slinging match, but I think that we have already pretty much established that the memory leak, if any, happens in the jDTS (?) driver and/or the ntlmauth.dll that it is using, and not in Tomcat code. If it is in the ntlmauth.dll, I doubt that any Java tool will show anything. הילה, how exactly are you seeing that the Tomcat process is leaking memory ? With the MS Task Manager ? And, where exactly does that ntlmauth.dll come from ? @Chris : Apparently, the database being used accepts either plain text authentication, or NTLM authentication. And apparently also, the setup is such that in either case, the login to the database is done using a single user-id, provided by Tomcat. One can discuss if this is, in the general scheme of things, an appropriate way in terms of security of access to the data in the database. But in the case of plain text authentication, the user-id and password used are stored in a Tomcat configuration file, in plain text. In the case of the NTLM authentication, the user-id under which tomcat runs can be easily discovered, but the password cannot. So I would think that in that limited sense, using NTLM offers an improvement. Now of course if at the same time, a bug in the jDTS driver or the ntlmauth.dll causes the Tomcat process to need more and more memory over time, the advantage is less evident. To nevertheless make some progress at identifying the culprit, I suggest the following procedure : Leave the user-id under which Tomcat itself is running as it is, using the Windows Domain user. Also leave the database as it is. But change back the authentication used for the database, to the plain-text setting. This way, the jDTS driver will still be there, but it will no longer be using the additional dll, and will authenticate to the DB with the plain-text user-id and password. Then check if the Tomcat process is still leaking memory. If it is not, then you know for sure that the leak is in ntlmauth.dll (or in the jDTS driver, but only when it using NTLM authentication). - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [OT] Memory Leak in Tomcat
-Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Wednesday, February 23, 2011 10:11 AM To: Tomcat Users List Subject: Re: [OT] Memory Leak in Tomcat -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 הילה, On 2/23/2011 10:51 AM, הילה - צוות אגורה wrote: the user that runs the tomcat service is a domain user, but I specify the user name and password of this user under log on tab on the service properties. it's not a problem since the password is encrypted, but in the xml file it's in clear text. It's a good thing those credentials don't need to be decrypted in order to be used. Congratulations: you've covered your ass. 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. 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.) __ Confidentiality Notice: This Transmission (including any attachments) may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this transmission in error, please immediately reply to the sender or telephone (512) 343-9100 and delete this transmission from your system.
