RE: [COMMERCIAL] Re: [COMMERCIAL] Re: Need Help: - jk doesn't work after upgrade to1.2.40 from 1.2.23
Andre,
Martin,
Thanks for your reply:
Answer to your previous question: 1). since the loadbalance haven't been
triggered, so I think we can ignore it now.
2). You are right "missing uri map" is a debug information, but in the above
code I pasted, it will return DECLINED, which is actually an error case.
3). the hostname doesn’t match with the configuration file, since I modified
some conf, so I tried to copy the original one used on 1.2.32. sorry for the
confusion.
4). I don't know ajp12, it's not triggered yet in my testing.
I attached the configuration files in my lab, this setting worked if using
mod_jk 1.2.23 release. If I replace the mod_jk.so with the version 1.2.40,
then it failed to open the page /sso/lsm/lsm.jnlp ( I got "Not Found The
requested URL /sso/lsm/lsm.jnlp was not found on this server.").
I opened the debug of mod_jk, I noticed it added into some uri work map and
also it can be dumped into jk.log:
[Wed Mar 16 12:47:17.965 2016] [12184:139831250073568] [debug]
uri_worker_map_add::jk_uri_worker_map.c (863): exact rule '/sso=csajboss'
source 'JkMount' was added
[Wed Mar 16 12:47:17.965 2016] [12184:139831250073568] [debug]
uri_worker_map_add::jk_uri_worker_map.c (854): wildchar rule '/sso/*=csajboss'
source 'JkMount' was added
...
[Wed Mar 16 12:47:17.974 2016] [12185:139831250073568] [debug]
uri_worker_map_dump::jk_uri_worker_map.c (197): NEXT (1) map #10: uri=/sso/*
worker=csajboss context=/sso/* source=JkMount type=Wildchar len=6
[Wed Mar 16 12:47:17.974 2016] [12185:139831250073568] [debug]
uri_worker_map_dump::jk_uri_worker_map.c (197): NEXT (1) map #20: uri=/sso
worker=csajboss context=/sso source=JkMount type=Exact len=4
But later when I tried to open the sso/lsm/lsm.jnlp, it should match the
wildchar /sso/* uri map. But it was failed, from the code, it's failed in
mod_jk.c jk_translate method()
The conf->wu_map was null(don't know why ??),
if (!conf->uw_map) {
if (JK_IS_DEBUG_LEVEL(conf->log))
jk_log(conf->log, JK_LOG_DEBUG,
"missing uri map for %s:%s",
conf->s->server_hostname ? conf->s->server_hostname
: "_default_",
r->uri);
return DECLINED;
}
else {
rule_extension_t *e;
worker = map_uri_to_worker_ext(conf->uw_map, r->uri,
NULL, &e, NULL, conf->log);
rconf->rule_extensions = e;
ap_set_module_config(r->request_config, &jk_module, rconf);
}
Do I need to change some configuration after upgrade to 1.2.40?
Thanks,
Eric.
-Original Message-
From: André Warnier (tomcat) [mailto:a...@ice-sa.com]
Sent: Monday, March 14, 2016 7:50 PM
To: Tomcat Users List
Subject: [COMMERCIAL] Re: [COMMERCIAL] Re: Need Help: - jk doesn't work after
upgrade to1.2.40 from 1.2.23
Hi Eric.
A couple of things :
1) Martin is right, in the sense that if a "worker" is mentioned in the
loadbalancer configuration ("balance_workers"), then normally you should /not/
also list it in the list of individual "workers" in the "worker.list" directive.
2) I am not even sure that you really have a problem : the logfile part that
you are showing, shows "[debug]" lines with the "Missing URI map.." messages.
These are not errors (otherwise they would be marked "[error]"), they are trace
messages allowing you to figure out what is going on when debugging a problem.
A "missing URI map" just indicates that mod_jk is trying to match the URI of
the current request with one of the "JkMount" URI's, and failing *for the
worker which it is now trying to match*. That does not necessarily mean that
it will fail to match this URI with some other worker.
3) the debug messages show a prefix like "IBM001OAM01:". What does that
correspond to ? I do not see this name in the JkMount directives that you show,
nor in the part of workers.properties that you show.
4) I am a bit puzzled by this section :
>>> worker.ajp12.port=8007
>>> worker.ajp12.host=localhost
>>> worker.ajp12.type=ajp12
What is this type "ajp12" ? As far as I know, this does not exist, see
http://tomcat.apache.org/connectors-doc/reference/workers.html
Mandatory Directives -> type
And finally, do you have a problem, and what is it ?
What really happens when you try to access a URI like
"http://(hostname)/sso/lsm/lsm.jnlp" ?
And could you provide a *complete* list of your (Jk*) configuration directives,
and a complete content of the workers.properties file ?
And maybe a short description as to what you are trying to achieve.
From what you provided so far, it is not very clear which URI's you want to
"load-balance" and which not.
The fact that "it worked before" is no guarantee that what you had before was
entirely correct.
On 14.03.2016 11:47, Martin Knoblauch wrote:
> Hi Eric,
>
> there are two things different from *my* w
Re: Question about your recent security (CVE-2015-5345) fix in 7.0.68 build
Hello There, I am kind of blocked here in my project while applying your CVE fix in our product & verify the fix. Any guidelines on what i am doing (mentioned in my previous email) wrong is highly appreciated. All i am trying to do is, disable the redirect for the root (Ex: /manager & /examples in tomcat) of the webapp. If i know how to do this on the mentioned tomcat webapps, then i can apply the same for my webapps too. Looking for your response & help here. regards Harish Krishnan On Fri, Mar 11, 2016 at 4:05 PM, Harish Krishnan wrote: > Thanks again for the reply, Chris & Violeta! > Thanks for clarifying what the "protected directory" is, even i guessed it > to be same. Now i understood the fix for the directories protected by a > security constraint. I also verified this & the redirect is no more > happening for these protected ones. Really appreciate your help here. > > However, i am still unable to disable the redirect for the root of the > webapp. This is what i did on the latest tomcat build (7.0.68) - > > a) Set the context attribute (mapperContextRootRedirectEnabled) to false > for manager webapp. Here is my context.xml (from > \webapps\manager\META-INF\) file - > > antiResourceLocking="false" privileged="true" > > > > b) Accessing http://localhost:8080/manager gets redirected to manger/. > > c) I have also set the above context attribute in the default context.xml > (from \conf\context.xml) file as well. > > d) Accessing http://localhost:8080/examples gets redirected to examples/. > > Not sure what i am missing here. Same behavior is seen on my web > application too. > Please let me know where i am doing wrong & help me on how to disable the > redirect for the root of webapps. > > > regards > Harish Krishnan > > > > > > > > On Wed, Mar 9, 2016 at 7:29 AM, Christopher Schultz < > ch...@christopherschultz.net> wrote: > >> Harish, >> >> On 3/8/16 5:47 PM, Harish Krishnan wrote: >> > Thanks Chris for the reply. >> > Looks like my understanding of the fix is incorrect. >> > I assumed (my bad) that, with the fix for this CVE in place (tomcat >> > 7.0.68) + setting the additional context attribute >> > (mapperContextRootRedirectEnabled="false"), all the redirects for that >> > webapp where context attribute was set, will completely be disabled. >> > You mentioned that only "protected directories" inside the deployed web >> > application is covered in this CVE fix. >> > Can you please help me understand what this protected directories are & >> how >> > to configure this in tomcat ? >> >> A "protected directory" is one that has a in >> web.xml. That's not a spec-defined term... just one we've been using >> because it captures the meaning with fewer words. >> >> As for the redirects you are seeing that "expose" the availability of a >> particular web application, those are essentially impossible to prevent, >> and not considered a part of the CVE. >> >> -chris >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> >
Re: Tomcat 6.x 32bit-- becomes non responsive state / crash/hang
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mahudeswaran, On 3/14/16 2:21 PM, Mahudeswaran A wrote: > We are working in different time zone. & We will try the thread > dump meantime...Would you like to share any check points in thread > dump or share some troubleshooting steps/tools to identify the > issue. The visualgc plugin in jvisualvm is not supported for the > jvm 1.6. > > Is there any configuration to include timestamp in tomcat std.out > or std.err log files. > > **Attached is the sequence flow that we are trying in our load > environment; > > Itr-1: If we attach a commercial tool (forget the name-it something > like yourjdk... will share you as soon as I get) the jvm crashes > within 10-15 minutes; Thread-count=150 Itr-2: If we attach a > commercial tool (forget the name-it something like yourjdk... will > share you as soon as I get) the jvm crashes within 50-55 minutes; > Thread-count=300 Itr-3: If we attach a commercial tool (forget the > name-it something like yourjdk... will share you as soon as I get) > the jvm crashes within 50-55 minutes; Thread-count=30 Itr-4: The > commercial tool was disconnected from jvm monitoring and started > the load with thread-count=30; & last few hours before checked it's > was running;monitoring with jvisualvm. You are probably using YourKit. When the JVM "crashes", do you get a hspid file and the process actually dies, or do you get some kind of exception in Tomcat's catalina.out or other log? Thanks, - -chris > -Original Message- From: Mark Thomas > [mailto:ma...@apache.org] Sent: 14 March 2016 20:14 To: Tomcat > Users List Subject: Re: Tomcat 6.x 32bit-- becomes non responsive > state / crash/hang > > On 14/03/2016 14:41, Mahudeswaran A wrote: >> Hi, >> >> We are facing unusual issue in Tomcat 6.x, where Tomcat 6.x >> becomes non responsive state after two week's time. This happens >> randomly; The jvisualvm screen shows CPU, memory, thread are >> normal and we don't see memory leak, thread leak or CPU hike. JVM >> running is 32 bit; In our lab, we are simulating this issue by >> running a load but still trying our level best but couldn't. Min >> heap=256MB; Max heap=512MB Thread count=150 Tomcat idle session >> timeout=30minutes In out load environment the thread count >> reduced to 30; >> >> Any insights on why the tomcat becomes non responsive; > > Take a series of 3 thread dumps, ~15s apart. If you need help > analysing them, post them here. > > Mark > > > - > > 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 > -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlboVRQACgkQ9CaO5/Lv0PCUxwCbB+LSrljEx62lSXvbRsOD4Xbj +g8An0UqMAZSgmVUEEXJcgqQH6NFxPrX =KmpU -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How to comply with http://www.sitemaps.org/protocol.html#location
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Terence, On 3/14/16 6:34 AM, Terence M. Bandoian wrote: > On 3/13/2016 10:23 AM, Lyallex wrote: >> CentOS 5.2 jdk1.7.0_45 apache-tomcat-7.0.42 no httpd, tomcat >> only, one webapp ROOT.war >> >> According to the documentation at >> >> http://www.sitemaps.org/protocol.html#location >> >> An xml sitemap should appear in the context root, if it dosn't it >> can only contain a limited set of urls. >> >> Currently, whenever I add a new product for sale I auto generate >> sitemap.xml and write it to a remote context called sitemap >> giving me the sitemap URL >> >> www.mysite.com/sitemap/sitemap.xml which I detail in robots.txt >> >> However this is apparently incorrect and sitemap.xml should live >> at www.mysite.com/sitemap.xml. Unfortunately it is not possible >> to write to the root of my web app on the fly so how do people >> deal with this ? >> >> Thanks Lyallex >> > > > One solution might be to write a servlet mapped to /sitemap.xml > that reads sitemap.xml from an alternate location and sends the > contents as a response to any requests for /sitemap.xml Or use PreResources in the ROOT webapp. No programming necessary. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlboUp8ACgkQ9CaO5/Lv0PAFqACcD4wezJtqsSpHfPIXlL6Zi43v IK4AoLtEqPF6LBLzM6sZVl6hQeqUtgEo =1QsM -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Intermittent ClassNotFoundException in Jasper EL evaluation
On Friday, March 11, 2016 10:03 PM, ma...@apache.org wrote: > > Monday works. I might try experimenting with some ideas between now and then > anyway. Hi again, A bit shorter reply this time, because of time shortage. I preferred to focus the little time I managed to "break free" on testing the trunk version of Tomcat 8 :) And... it looks really great! I have performed some JMeter tests now, and here are the results: Tomcat 8.0.32 Average 2500 ms per request. Tomcat 8 trunk (revision 81735040) Average 360 ms per request Tomcat 7.0.68 Average 290 ms per request Test setup: - Windows 8 - JMeter 2.13 - Tomcat with a custom webapp, on Escenic CMS - JMeter running with one thread, and a throttle (Constant Throughput Timer) set to 12 samples per minute (ie 5 seconds between each request) - Testing the start page (with lots of content) - Tomcat started fresh, and the webapp visited a few times in the browser as a warmup - Waited until CPU fan and CPU load settled down before starting the test - No other traffic to Tomcat during the test - No resource hungry program running except Tomcat and JMeter So, all in all, I see a huge improvement with our site. Going from 2500 ms to 360 ms. :) As you can see, compared to Tomcat 7 it is still an increase with 70 ms, but for our site that is not a "deal breaker". Regards /Jimi - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How can I fix deserialization vulnerability?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark, On 3/15/16 5:19 AM, Mark Thomas wrote: > This comes down to the threat scenarios in which Tomcat is intended > to be secure. A vulnerability is, essentially, when an attacker is > able to bypass that security in some way. > > Tomcat is not intended to be secure from attacks by malicious > local users if those local users have write access to any part of > the Tomcat installation. Precisely. This is why I was minimizing the impact of this threat. It's definitely something that ought to be addressed (by users -- there is a mitigation available), but it shouldn't be considered high-priority or urgent. > Tomcat is intended to be secure from running malicious web > applications (they should not be able to view data from other web > applications or access other data on the server Tomcat is running > on) providing a SecurityManager is used. Where it gets interesting > is that you cannot protect against a DoS attack by a malicious web > application - even when running under a SecurityManager. Of course. One of the features of a web server is that it's expected to, you know, serve content when a request is made ;) > It would probably be a "Good Thing" to document the scenarios in > which Tomcat is intended to be secure. I think they are reasonably > well understood by the Tomcat committers - maybe not so much by the > wider community. Or, more to the point, document the scenarios under which we think that security is /not/ achievable -- such as protecting config files beyond what the filesystem permissions can provide. In general, Tomcat should be fairly secure out of the box. I always think it's funny when people want to know about "Hardening Tomcat". It's pretty "hard" to begin with. Basically, if you want to harden a Tomcat installation, do whatever you would to harden anything: don't run as root/admin, lock-down file permissions, remove unnecessary applications, use TLS. Nothing really Tomcat-specific. The only thing that's potentially insecure in a stock Tomcat install is that the examples applications will deploy by default (unless you use separate CATALINA_HOME/CATALINA_BASE), and there could be a vulnerability hiding in the examples webapp. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlboPbgACgkQ9CaO5/Lv0PBCdgCfdCStn1my/zUuAUUPPBFcCovm lscAoLeNWXpp3Jy5nFFhJz7qfCmSHFoy =8xu9 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Apache Tomcat Native 1.2.5 on CentOS 7?
On Tue, 15 Mar 2016 10:35:38 + Mark Thomas wrote: > On 15/03/2016 09:47, Bjørn T Johansen wrote: > > On Tue, 15 Mar 2016 09:20:24 + > > Mark Thomas wrote: > > > >> On 15/03/2016 08:04, Bjørn T Johansen wrote: > >>> Just tried to configure and compile the native libs under CentOS 7 and I > >>> get this while configuring: > >>> > >>> Found OPENSSL_VERSION_NUMBER 0x1000105f (OpenSSL 1.0.1e 11 Feb 2013) > >>> Require OPENSSL_VERSION_NUMBER 0x1000200f or greater (1.0.2) > >>> > >>> It this something I should worry about or can I just ignore it? (I don't > >>> use SSL on Tomcat anyway but...) > >> > >> If you don't use TLS then there is no benefit to using the native > >> libraries. > >> > >> Mark > >> > > > > Hmmm... I might have misunderstood the reasons to use the native libs, I > > thought there was a performance gain in using these libs but they are only > > needed when using TLS? > > There days the performance gain is minimal if you aren't using TLS. > > The native I/O code is faster but it also adds overhead switching > between Java and native code. Generally, these balance out. Depending on > exact usage, one will be slightly faster than the other but there isn't > very much in it. > > Mark > Ok, thx... :) BTJ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Apache Tomcat Native 1.2.5 on CentOS 7?
On 15/03/2016 09:47, Bjørn T Johansen wrote: > On Tue, 15 Mar 2016 09:20:24 + > Mark Thomas wrote: > >> On 15/03/2016 08:04, Bjørn T Johansen wrote: >>> Just tried to configure and compile the native libs under CentOS 7 and I >>> get this while configuring: >>> >>> Found OPENSSL_VERSION_NUMBER 0x1000105f (OpenSSL 1.0.1e 11 Feb 2013) >>> Require OPENSSL_VERSION_NUMBER 0x1000200f or greater (1.0.2) >>> >>> It this something I should worry about or can I just ignore it? (I don't >>> use SSL on Tomcat anyway but...) >> >> If you don't use TLS then there is no benefit to using the native libraries. >> >> Mark >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> > > > Hmmm... I might have misunderstood the reasons to use the native libs, I > thought there was a performance gain in using these libs but they are only > needed when using TLS? There days the performance gain is minimal if you aren't using TLS. The native I/O code is faster but it also adds overhead switching between Java and native code. Generally, these balance out. Depending on exact usage, one will be slightly faster than the other but there isn't very much in it. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Apache Tomcat Native 1.2.5 on CentOS 7?
On Tue, 15 Mar 2016 09:20:24 + Mark Thomas wrote: > On 15/03/2016 08:04, Bjørn T Johansen wrote: > > Just tried to configure and compile the native libs under CentOS 7 and I > > get this while configuring: > > > > Found OPENSSL_VERSION_NUMBER 0x1000105f (OpenSSL 1.0.1e 11 Feb 2013) > > Require OPENSSL_VERSION_NUMBER 0x1000200f or greater (1.0.2) > > > > It this something I should worry about or can I just ignore it? (I don't > > use SSL on Tomcat anyway but...) > > If you don't use TLS then there is no benefit to using the native libraries. > > Mark > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > Hmmm... I might have misunderstood the reasons to use the native libs, I thought there was a performance gain in using these libs but they are only needed when using TLS? BTJ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Starting and stopping contexts programmatically
Hi James, From: Mark Thomas Sent: 15 March 2016 09:21 To: Tomcat Users List Subject: Re: Starting and stopping contexts programmatically On 15/03/2016 00:25, James H. H. Lampert wrote: > The only ways I know of to start and stop individual webapp contexts is > to (1) start and stop them from the manager, or (2) start and stop > Tomcat itself. > > Is there a way, from the back end, to start and stop individual contexts? You could do that via JMX. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org You can also call Tomcat Manager via Curl - curl -X GET http://:@:/manager/text/start?path=/%23%23v1.0.9 The %23 implies # E.G - my-web-service##v1.0.9 Theo Avios Group (AGL) Ltd is a limited company registered in England (registered number 2260073 and VAT number 512566754) whose registered address is Astral Towers, Betts Way, London Road, Crawley, West Sussex RH10 9XY . Avios Group (AGL) Limited is part of the IAG group of companies This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Starting and stopping contexts programmatically
On 15/03/2016 00:25, James H. H. Lampert wrote: > The only ways I know of to start and stop individual webapp contexts is > to (1) start and stop them from the manager, or (2) start and stop > Tomcat itself. > > Is there a way, from the back end, to start and stop individual contexts? You could do that via JMX. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Apache Tomcat Native 1.2.5 on CentOS 7?
On 15/03/2016 08:04, Bjørn T Johansen wrote: > Just tried to configure and compile the native libs under CentOS 7 and I get > this while configuring: > > Found OPENSSL_VERSION_NUMBER 0x1000105f (OpenSSL 1.0.1e 11 Feb 2013) > Require OPENSSL_VERSION_NUMBER 0x1000200f or greater (1.0.2) > > It this something I should worry about or can I just ignore it? (I don't use > SSL on Tomcat anyway but...) If you don't use TLS then there is no benefit to using the native libraries. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How can I fix deserialization vulnerability?
On 14/03/2016 21:01, Christopher Schultz wrote: > On 3/11/16 4:10 AM, Mark Thomas wrote: >> On 11/03/2016 01:43, Christopher Schultz wrote: >>> If you don't have any applications that have known problematic >>> classes in them (such as the famous commons-collections bug), >>> then you aren't really in any danger. > >> That statement is dangerously incorrect. > > I disagree, though my statement may easily be misunderstood. > >> The vulnerability is not in Commons Collections or any of the >> various other libraries that have been leveraged in the various >> examples that have been made public. > >> The vulnerability is always that an application takes data from an >> untrusted source and deserializes it without validation and/or >> sanitation. If your application does this then you are almost >> certainly vulnerable to a deserialization attack of some form. > > The vulnerability is in neither the library (e.g. commons-collections) > nor the application (Tomcat, in this case). Instead, the vulnerability > is in the interaction between the two of them. I disagree. The vulnerability, in this case, is in Tomcat since Tomcat is taking the untrusted data and treating it as trusted. > Specifically, if you are using an application (Tomcat) that is > "vulnerable" (because it unsafely de-serializes untrusted streams) but > no "vulnerable" library is present, then it is not possible to exploit > this vulnerability. The problem is that you cannot prove that there is no code that can be leveraged by the attacker. More ways to do this are being found all the time. I suspect it is only a matter of time before one is found in the JRE. >> If you aren't running Tomcat under a security manager web >> applications can do whatever they like so this vulnerability is >> irrelevant. > > I disagree. If you aren't running under a SecurityManager, it's still > possible (yet unlikely) for an attacker to inject a Trojan Horse into > Tomcat's session store. For example, a local user might be able to > escalate their privileges if they only have write access to the > session store. A SecurityManager might not help protect against such a > Trojan Horse, so the vulnerability IMO is definitely important even > under a SM. If you give an untrusted local user write access to the work directory (where Tomcat persists the sessions) then there are a whole bunch of ways you can compromise a Tomcat installation - none of which I would consider security vulnerabilities. They would all be classed as configuration errors. I do agree that such a scenario is pretty unlikely. This comes down to the threat scenarios in which Tomcat is intended to be secure. A vulnerability is, essentially, when an attacker is able to bypass that security in some way. Tomcat is not intended to be secure from attacks by malicious local users if those local users have write access to any part of the Tomcat installation. Tomcat is intended to be secure from running malicious web applications (they should not be able to view data from other web applications or access other data on the server Tomcat is running on) providing a SecurityManager is used. Where it gets interesting is that you cannot protect against a DoS attack by a malicious web application - even when running under a SecurityManager. It would probably be a "Good Thing" to document the scenarios in which Tomcat is intended to be secure. I think they are reasonably well understood by the Tomcat committers - maybe not so much by the wider community. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Apache Tomcat Native 1.2.5 on CentOS 7?
Just tried to configure and compile the native libs under CentOS 7 and I get this while configuring: Found OPENSSL_VERSION_NUMBER 0x1000105f (OpenSSL 1.0.1e 11 Feb 2013) Require OPENSSL_VERSION_NUMBER 0x1000200f or greater (1.0.2) It this something I should worry about or can I just ignore it? (I don't use SSL on Tomcat anyway but...) Regards, BTJ -- --- Bjørn T Johansen b...@havleik.no --- Someone wrote: "I understand that if you play a Windows CD backwards you hear strange Satanic messages" To which someone replied: "It's even worse than that; play it forwards and it installs Windows" --- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
