RE: [COMMERCIAL] Re: [COMMERCIAL] Re: Need Help: - jk doesn't work after upgrade to1.2.40 from 1.2.23

2016-03-15 Thread ZHAO Eric
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, , NULL, conf->log);
rconf->rule_extensions = e;
ap_set_module_config(r->request_config, _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* 

Re: Question about your recent security (CVE-2015-5345) fix in 7.0.68 build

2016-03-15 Thread Harish Krishnan
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

2016-03-15 Thread Christopher Schultz
-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

2016-03-15 Thread Christopher Schultz
-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

2016-03-15 Thread jimi.hullegard
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?

2016-03-15 Thread Christopher Schultz
-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?

2016-03-15 Thread Bjørn T Johansen
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?

2016-03-15 Thread Mark Thomas
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?

2016-03-15 Thread Bjørn T Johansen
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

2016-03-15 Thread Theo Sweeny
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

2016-03-15 Thread Mark Thomas
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?

2016-03-15 Thread Mark Thomas
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?

2016-03-15 Thread Mark Thomas
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?

2016-03-15 Thread Bjørn T Johansen
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