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

[Harish Krishnan]

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 -


 

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

Programmatically create JNDI resource links?

[Christopher Simons]

Greetings,

I have a javax.naming.spi.ObjectFactory implemented in a JAR file 
sitting in $CATALINA_HOME/lib.  I have declared it as a  in 
$CATALINA_HOME/conf/server.xml.  Upon Tomcat startup, its 
getObjectInstance(...) method is being invoked, and within that method, 
some objects are bound into the javax.naming.Context object that is 
passed in as an argument.


Normally, to give application access to a global resource I'd declare a 
 in the applications META-INF/context.xml file or in 
$CATALINA_HOME/conf/context.xml.  In this case, however, I don't know 
what new objects I'll be binding into the Context until run-time, and it 
will change frequently, so placing such declarations there in a static 
manner will not work.


Is there an API I can use to programmatically create global resource 
links as one would normally put in $CATALINA_HOME/conf/context.xml, or 
to somehow otherwise access the global Tomcat Context bindings from my 
hosted applications?


Thanks,



Christopher Simons
Pittsburgh, PA

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

Re: ***UNCHECKED*** RE: Intermittent ClassNotFoundException in Jasper EL evaluation

[Mark Thomas]

On 11/03/2016 19:00, jimi.hulleg...@svensktnaringsliv.se wrote:
> On Friday, March 11, 2016 6:07 PM, ma...@apache.org wrote:



> I'm wasn't talking about gathering information regarding performance. I was 
> talking about gathering information about what jsp/tag code and what EL 
> variable names are responsible for this, and how often it happens. In order 
> to get a grasp of if it is feasible to solve by fixing the code. For example, 
> if this log output showed me that 90% of the ClassNotFoundExceptions happen 
> because of a handful of jsp/tag files, then I would just fix these and see 
> how much that helped. But if the log output would indicate that this problem 
> is spread out over too many jsp and tag files, then I wouldn't even try and 
> fix it in the code, but would instead try some other approach (like disabling 
> this feature, or reverting back to Tomcat 7).

Ah, now I understand your motivation. debug logging would be more
helpful than a profiler in that case.

The next problem is that we are in a spec class and can't add any
dependencies. That forces a hard dependency on java.util.logging which
isn't great.

What you can do is turn on debug logging for the web application class
loader. That should get you most of what you need.

>> At the point where you'd need to access the ServletContext to read the 
>> configuration, the ServletContext isn't available.
>> [...]
>> Since I wrote the "configuration API" above, I did some more research and 
>> found the route 
>> via the ELContext. That is what the implemented solution uses. 
> 
> So, just to check if I understood you correctly... You *can* get access to 
> the ServletContext, right? (Using page.getServletContext()...)

No, the ServletContext isn't directly accessible but more digging shows
some helpful signs.

ScopedAttributeELResolver can access the current JspContext. That has
access to the page/request/session/application attributes and can
probably be cast to PageContext which has access to the ServletContext.
So there is a (slightly contrived) route by which per web application
config can be passed without breaking the spec and per page config can
be passed with custom code or extending the spec (which as far as the
spec owners are concerned is the same thing as breaking the spec).

>> And why would it not work for some users? I'm not saying it would magically 
>> solve the problem for everyone. But it would solve the worst problems for 
>> most people, and it wouldn't make it worse for anyone (ie, the fact that one 
>> would have the *option* to turn it off, doesn't make the situation worse).
> 
> 
>> Which is my point. The solution doesn't help those users that need imports 
>> and 
>> good performance. Greater granularity in configuration helps to a point but 
>> there will be users that need imports and good performance on the same page 
>> and per expression configuration is taking things a bit too far for my taste.
> 
> I'm sorry, but I don't follow you now. Are you saying that since there are 
> people who wouldn't benefit from this (but not get hurt either), there is no 
> reason to fix it for those that *would* benefit from it?

I'm saying that I prefer to expend effort on a solution that doesn't
break the spec and works for everyone than one that only works for some
users, probably involves breaking the spec and increases configuration
complexity.

>> Per page is certainly better than global but I still have concerns. In 
>> addition to the large pages 
>> needing imports and performance above, I'm concerned that there is no good 
>> default for
>> an option that disables import support. Disabling imports by default will 
>> break pages that 
>> use imports unless the developer adds the extra code. Not disabling them by 
>> default means 
>> having to add code to every page with a performance problem.
> 
> Well, I never said that it would solve the problem for everyone. But for 
> people who don't use any EL imports at all (like everyone migrating from 
> Tomcat 7), they would benefit from a global *off* option, and then they can 
> systematically enable this feature slowly, page by page, as they add 
> functionality that depends on it.

Page by page config requires breaking the spec which at this point I'd
rather not do by default.

> As for people who have pages that need both imports and performance, I still 
> claim that this fix wouldn't make it any *worse* for them. In fact, I would 
> claim that it would make it somewhat better, because now they would have an 
> option to control what pages should have this feature, and if they have 
> important pages that doesn't use imports then they at least could reduce the 
> performance problem for those pages. And regarding the pages with both a need 
> for both imports and performance, well they still have the workaround that 
> was mentioned in the beginning of this thread, adding a specific scope to all 
> the EL variables (at least the ones that can be null or not set).

RE: Intermittent ClassNotFoundException in Jasper EL evaluation

[jimi.hullegard]

On Friday, March 11, 2016 6:07 PM, ma...@apache.org wrote:
> 
> And a debug log message is unlikely to tell you any more than the thread dump 
> did. 

That depends on what is actually being logged. If the class name is printed, 
then one could immediately figure out the name of the EL variable (like 
"java.lang.myTempValue", then the EL parameter name is "myTempValue").

And the thread dump only gives me a snapshot, containing 0, 1 or more 
stacktraces with the ClassNotFoundException. Unless I take a threaddump every 
millisecond (or even more often), the thread dump method would miss some 
stacktraces. With logging, it would not miss any.


> If the same code keeps appearing in a thread dump it is a fair bet that time 
> is being spent in that code but you still need performance data - which you 
> can't get from debug logging or thread dumps - to be certain.

I'm wasn't talking about gathering information regarding performance. I was 
talking about gathering information about what jsp/tag code and what EL 
variable names are responsible for this, and how often it happens. In order to 
get a grasp of if it is feasible to solve by fixing the code. For example, if 
this log output showed me that 90% of the ClassNotFoundExceptions happen 
because of a handful of jsp/tag files, then I would just fix these and see how 
much that helped. But if the log output would indicate that this problem is 
spread out over too many jsp and tag files, then I wouldn't even try and fix it 
in the code, but would instead try some other approach (like disabling this 
feature, or reverting back to Tomcat 7).



> As for using it in production, you aren't going to be using a profiler unless 
> you have a problem. 
> I'd look at the risk (never seen an issue) of using a profiler against the 
> production system and 
> the quality of data / time to useful results vs debug logging and the longer 
> to get results / lower 
> quality of data and choose the profiler every time. YMMV.

Well, I guess you have a point. But the fact is that we don't have any profiler 
tool installed in production right now (and I suspect that is a quite common 
scenario for many users in general), and having one installed is not something 
that is done quickly. Enabling trace or debug logging in a specific class takes 
less than a minute, giving me much needed information more or less instantly.

But yes, if one would have followed common sense, and already had a profiler 
installed (and have used it enough to know how to get it to output the needed 
information), then you would be right ;)



> At the point where you'd need to access the ServletContext to read the 
> configuration, the ServletContext isn't available.
> [...]
> Since I wrote the "configuration API" above, I did some more research and 
> found the route 
> via the ELContext. That is what the implemented solution uses. 

So, just to check if I understood you correctly... You *can* get access to the 
ServletContext, right? (Using page.getServletContext()...)



> It should be possible to hook up your proposed configuration option 
> to pass data via that as long as the code is careful.

OK. Sounds promising. Fingers crossed. :)


> And why would it not work for some users? I'm not saying it would magically 
> solve the problem for everyone. But it would solve the worst problems for 
> most people, and it wouldn't make it worse for anyone (ie, the fact that one 
> would have the *option* to turn it off, doesn't make the situation worse).


> Which is my point. The solution doesn't help those users that need imports 
> and 
> good performance. Greater granularity in configuration helps to a point but 
> there will be users that need imports and good performance on the same page 
> and per expression configuration is taking things a bit too far for my taste.

I'm sorry, but I don't follow you now. Are you saying that since there are 
people who wouldn't benefit from this (but not get hurt either), there is no 
reason to fix it for those that *would* benefit from it?



> Per page is certainly better than global but I still have concerns. In 
> addition to the large pages 
> needing imports and performance above, I'm concerned that there is no good 
> default for
> an option that disables import support. Disabling imports by default will 
> break pages that 
> use imports unless the developer adds the extra code. Not disabling them by 
> default means 
> having to add code to every page with a performance problem.

Well, I never said that it would solve the problem for everyone. But for people 
who don't use any EL imports at all (like everyone migrating from Tomcat 7), 
they would benefit from a global *off* option, and then they can systematically 
enable this feature slowly, page by page, as they add functionality that 
depends on it.

As for people who have pages that need both imports and performance, I still 
claim that this fix wouldn't make it any *worse* for them. In fact, I would 

Re: Intermittent ClassNotFoundException in Jasper EL evaluation

[Mark Thomas]

On 11/03/2016 14:17, jimi.hulleg...@svensktnaringsliv.se wrote:
> On Thursday, March 10, 2016 10:44 PM, ma...@apache.org wrote:
>>
>> We'll have to agree to disagree on that one. If you are concerned
>> about a performance issue then you need to know where to look to
>> enable debug logging. A profiler will tell you where to look and
>> at that point you don't need the debug logging.
> 
> Well, first of all, I found this without knowing where to look. I just 
> checked the thread dump, looked closer at the stack traces involving the 
> ClassNotFoundExceptions, and found the try catch clause. If there would have 
> been a log.debug(...) or log.trace(...) statement there, then I would know 
> how to enable debug logging for this. All without knowing beforehand where to 
> look, and all without anybody telling me where to look.

And a debug log message is unlikely to tell you any more than the thread
dump did. If the same code keeps appearing in a thread dump it is a fair
bet that time is being spent in that code but you still need performance
data - which you can't get from debug logging or thread dumps - to be
certain.

> Secondly, not all problems are easily reproducible in a 
> development/test/staging environment, especially if one depends on the nature 
> of the production traffic to find all (or at least most) places in the code 
> that experience problems. Not all organizations have the time and/or the 
> money to replay/simulate live traffic in another environment. And I suspect 
> that most IT departments and/or service providers would react with some 
> suspicion or worry if one would try and get them to introduce a profiler in 
> production, even though these tools have become more and more production 
> friendly over the years.

You still need to know what debug logging to turn on and if you are
guessing based on thread dumps then you already have everything debug
logging is likely to give you.

> Thirdly, even if profiling would be an option, if no profiling is setup 
> already then it would take some time and money to do that. Compared to the 
> trivial change of logging level for a specific class. And I can't really see 
> how log.debug(...) or log.trace(...)  (possibly surrounded by a 
> log.isDebugEnabled() or isTraceEnabled())would have any negative effect for 
> anyone.

Compared to the cost of the time to debug issues without a profiler, the
cost of a profiler is tiny. I use YourKit (because they give me a free
copy to use for my ASF work) and, while the price of it has gone up
quite a bit since I last looked a few years ago, it still (in my view)
offers a very quick return on investment.

As for using it in production, you aren't going to be using a profiler
unless you have a problem. I'd look at the risk (never seen an issue) of
using a profiler against the production system and the quality of data /
time to useful results vs debug logging and the longer to get results /
lower quality of data and choose the profiler every time. YMMV.

>> The code in question is in the JSP API JAR and there is no 
>> configuration API available. The only option would be 
>> a system property which would make it a global configuration option.
> 
> I'm not sure I understand why the absence of a "configuration API" would stop 
> you from simply checking for a specific init parameter in the servlet context 
> (thus making it possible to configure it in the web.xml using a 
> context-param). And when it comes to per jsp configuration, one could check 
> for a page scoped attribute with the same name. Ideally this could be added 
> as a new page directive attribute (like <%@ page disableELImports="true" %>), 
> but I guess that would constitute a "configuration API" change that would 
> have to be in the specification. But the init parameter or page scoped 
> attribute could be fine interim solutions, until the specification is updated 
> to add these configuration options the proper way.

At the point where you'd need to access the ServletContext to read the
configuration, the ServletContext isn't available. The code in question
is in a spec JAR and we can't change the public API in any way, nor can
we add a dependency to some other component. That tends to leave system
properties as the only option.

Since I wrote the "configuration API" above, I did some more research
and found the route via the ELContext. That is what the implemented
solution uses. It should be possible to hook up your proposed
configuration option to pass data via that as long as the code is careful.

> And why would it not work for some users? I'm not saying it would magically 
> solve the problem for everyone. But it would solve the worst problems for 
> most people, and it wouldn't make it worse for anyone (ie, the fact that one 
> would have the *option* to turn it off, doesn't make the situation worse).

Which is my point. The solution doesn't help those users that need
imports and good performance. Greater granularity in 

RE: Intermittent ClassNotFoundException in Jasper EL evaluation

[jimi.hullegard]

On Thursday, March 10, 2016 10:44 PM, ma...@apache.org wrote:
> 
> We'll have to agree to disagree on that one. If you are concerned
> about a performance issue then you need to know where to look to
> enable debug logging. A profiler will tell you where to look and
> at that point you don't need the debug logging.

Well, first of all, I found this without knowing where to look. I just checked 
the thread dump, looked closer at the stack traces involving the 
ClassNotFoundExceptions, and found the try catch clause. If there would have 
been a log.debug(...) or log.trace(...) statement there, then I would know how 
to enable debug logging for this. All without knowing beforehand where to look, 
and all without anybody telling me where to look.

Secondly, not all problems are easily reproducible in a 
development/test/staging environment, especially if one depends on the nature 
of the production traffic to find all (or at least most) places in the code 
that experience problems. Not all organizations have the time and/or the money 
to replay/simulate live traffic in another environment. And I suspect that most 
IT departments and/or service providers would react with some suspicion or 
worry if one would try and get them to introduce a profiler in production, even 
though these tools have become more and more production friendly over the years.

Thirdly, even if profiling would be an option, if no profiling is setup already 
then it would take some time and money to do that. Compared to the trivial 
change of logging level for a specific class. And I can't really see how 
log.debug(...) or log.trace(...)  (possibly surrounded by a 
log.isDebugEnabled() or isTraceEnabled())would have any negative effect for 
anyone.

Just my two cents...


> The code in question is in the JSP API JAR and there is no 
> configuration API available. The only option would be 
> a system property which would make it a global configuration option.

I'm not sure I understand why the absence of a "configuration API" would stop 
you from simply checking for a specific init parameter in the servlet context 
(thus making it possible to configure it in the web.xml using a context-param). 
And when it comes to per jsp configuration, one could check for a page scoped 
attribute with the same name. Ideally this could be added as a new page 
directive attribute (like <%@ page disableELImports="true" %>), but I guess 
that would constitute a "configuration API" change that would have to be in the 
specification. But the init parameter or page scoped attribute could be fine 
interim solutions, until the specification is updated to add these 
configuration options the proper way.



> Um, no. See above. This would have to be a global option. It would work for 
> some users/pages but not for others.

Um, yes, see above. ;)

And why would it not work for some users? I'm not saying it would magically 
solve the problem for everyone. But it would solve the worst problems for most 
people, and it wouldn't make it worse for anyone (ie, the fact that one would 
have the *option* to turn it off, doesn't make the situation worse).


> Generally, the suggestions are reasonable. The control can't be as 
> fine-grained as you suggest but that isn't necessarily a show-stopper.

Well, the solution with the page scoped attribute in the jsp page would make it 
fine grained enough for most people, don't you think? :)

I would also be interested in hearing your thoughts about having an option to 
disable this class lookup for all names that doesn't start with a capital 
letter. Thus making ${Boolean.TRUE} work as normal, while skipping ${foo.bar}, 
even if they coexist in the same jsp page. I actually would think that would be 
the best solution to this, since the naming convention dictates that you should 
start class names with capital letter, and variables with lower case letters.

Basically, the code could look something like this, in 
ScopedAttributeELResolver.java:

if (importHandler != null) {
if (resolveClass) {
//disableELImportsForNamesNotStartingWithUpperCase is false by 
default,
//and can be configured using for example a web.xml init 
parameter
if (disableELImportsForNamesNotStartingWithUpperCase && 
!Character.isUpperCase(key.charAt(0))) {
resolveClass = false;
}
}
if (resolveClass) {
...
}
...



> The main disadvantage that these options have is that a 
> better solution is available. Follow the bug report from 
> my previous message in this thread for details.
> [...]
> In this case, I believe the root cause has been fixed.

That sounds great! And I saw now in the bug report page that your simple test 
case indicated a ~1ms performance gain per avoided ClassNotFoundException. That 
sounds very close to my own tests, where the start page takes about 2500 ms, 
and I counted about 2700 ClassNotFoundExceptions.

[ANN] Apache Tomcat Native 1.2.5 released

[Mark Thomas]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat Native 1.2.5 stable.

The key features of this release are:
- Report OpenSSL runtime version in use rather than compile
  time version used.
- Windows binaries built with APR 1.5.1 and OpenSSL 1.0.2g.


Note that users should now be using 1.2.x in preference to 1.1.x.

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/native-doc/miscellaneous/changelog.html

Downloads:
http://tomcat.apache.org/download-native.cgi

The Apache Tomcat Native Library provides portable API for features
not found in contemporary JDK's. It uses Apache Portable Runtime as
operating system abstraction layer and OpenSSL for SSL networking and
allows optimal performance in production environments.


Thank you,
-- 
The Apache Tomcat Team

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

Re: Error 404 for autodiscover.xml

[Mark Thomas]

On 11/03/2016 08:26, Subhro Paul wrote:
> Hi All,
> 
> Our client has a simple website consists of some jsps, images, css, 
> javascripts and html files. It has two Apache proxy(under loadbalancers) 
> and two Tomcat6(under Loadbalancer). All servers are installed under Linux 
> environment.This website don't deal with any e-mailing or SMTP features. 
> It dose not have any Microsoft exchange facility(I am not sure what it is. 
> Got this things while searching in the web). It's a very simple website 
> and all are static contents.
> 
> But if we see the log we always see the below present in the logs in both 
> proxy and tomcat box.
> 
> [11/Mar/2016:00:36:04 -0500] "POST /autodiscover/autodiscover.xml 
> HTTP/1.1" 404 172
> [11/Mar/2016:00:36:06 -0500] "GET /autodiscover/autodiscover.xml HTTP/1.1" 
> 404 172
> 
> Why this /autodiscover/autodiscover.xml is called? Who is calling it? Is 
> that a feature of Apache proxy which is automatically called?
> 
> Before going to prevent this log I first want to know why is this been 
> called?

http://lmgtfy.com/?q=%2Fautodiscover%2Fautodiscover.xml

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

[Mark Thomas]

On 11/03/2016 01:43, Christopher Schultz wrote:
> 林慶龍,
> 
> On 3/10/16 8:07 PM, 林慶龍 Barry Lin wrote:
>> These days, Everyone talks about the vulnerability in Tomcat, and
>> we found that we had the same problem with “deserialization 
>> vulnerability”.
> 
>> How can I fix deserialization vulnerability in tomcat?
> 
> 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.

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.

> You can disable session serialization, but if you don't trust the
> files on your own disk then you probably have bigger problems.
> 
> You can disable clustering, but if you don't trust the other members
> of your cluster, then you probably have bigger problems.
> 
> You can disable session persistence, but if you don't trust your
> database, then you probably have bigger problems.

In 99.99% if use cases none of the above will be a problem since the
data is trusted.

The vulnerability *only* applies when running untrusted web applications
under a security manager (think hosting provider that only allows users
to host WARs and uses a security manager to limit what those WARs can
do). Because serialization and deserialization is performed by trusted
code, it was possible for an untrusted web application to place a
malicious object in the session that would, on deserialization, execute
some code that would normally be blocked by the SecurityManager. If
effect, this was a way for an untrusted app to bypass the constraints
imposed by the SecurityManager.

> The reality is that this "deserialization vulnerability" is wildly
> overblown. Yes, it should be mitigated, but the attack vectors are
> very, very narrow.

Agreed.

> As of Tomcat 8.0.32, the session resumption "vulnerability" has been
> mitigated in Tomcat itself if you configure it properly. It's covered
> under "CVE-2016-0714" on this page:
> https://tomcat.apache.org/security-8.html
> 
> You need to either run Tomcat under a SecurityManager (in which case,
> you'll get a non-null default value for this configuration setting),
> or you need to set sessionAttributeValueClassNameFilter on your
>  element in server.xml.
> https://tomcat.apache.org/tomcat-8.0-doc/config/manager.html

If you aren't running Tomcat under a security manager web applications
can do whatever they like so this vulnerability is irrelevant.

> (I admit I find the use of that CVE a little confusing, here, but the
> patches for that CVE are the ones that also fix the de-serialization
> vulnerability.)

What do you find confusing? I've re-read the CVE description and I
really can't see where it is unclear but given I wrote it pointers to
what is unclear would be welcome.

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?

[Rob Gansevles]

Barry,

The deserialization-vulnerability for RMI endpoints in your webapp can be
mitigated using our library at https://github.com/Servoy/rmi-whitelist
Add it to the tomcat system library and classes like the
commons-collections can no longer be used in the serialisation attacks over
RMI.

Rob

2016-03-11 2:07 GMT+01:00 林慶龍 Barry Lin :

> Dears:
>
> These days, Everyone talks about the vulnerability in Tomcat, and we found
> that we had the same problem with “deserialization vulnerability”.
>
> How can I fix deserialization vulnerability in tomcat?
>
> Thanks for your help!
>
>
>
>
>
> Best regard,
>
> Barry Lin
>
> 鼎捷
> (鼎新電腦股份有限公司、鼎誠資訊股份有限公司、鼎捷軟件股份有限公司及鼎捷軟件越南有限公司)將善保管您的個人資料，並於合法取得之前提下善意使用，據此本公司僅在營運範圍內之目的與您聯繫，包含鼎捷主辦或協辦之行銷活動、客戶服務、供應商聯繫等，非經由本公司上開目的下之合法授權，所寄發之資訊並不代表本公司
> 。本電子郵件及附件所載訊息均為保密資訊，受合約保護或依法不得洩漏。其內容僅供指定收件人按限定範圍或特殊目的使用。未經授權者收到此資訊者均無權閱讀、
> 使用、
> 複製、洩漏或散佈。若您因為誤傳而收到本郵件或者非本郵件之指定收件人，煩請即刻回覆郵件或並永久刪除此郵件及其附件和銷毀所有複印件。倘若有前述情形或信件誤遞至您的信箱或有相關問題，請透過下列方式聯繫更正；mail：
> dsc...@digiwin.biz。謝謝您的合作！
>

Re: Intermittent ClassNotFoundException in Jasper EL evaluation

[Mark Thomas]

On 10/03/2016 22:16, Christopher Schultz wrote:
> Mark,
> 
> On 3/10/16 4:43 PM, Mark Thomas wrote:
>> On 10/03/2016 21:16, jimi.hulleg...@svensktnaringsliv.se wrote:
>>> On Thursday, March 10, 2016 11:20 AM, ma...@apache.org wrote:

> 3. Why is the problem not limited to the first request for a
> jsp page?

 Because EL imports may be dynamic so the EL has to be evaluated
 on execution.
>>>
>>> I'm not really sure I follow you now. Can you explain what you
>>> mean with dynamic imports in this regard? I can't see any
>>> mentioning of it in the specs 
>>> (http://download.oracle.com/otn-pub/jcp/el-3_0-fr-eval-spec/EL3.0.FR.
> pdf).
> 
>>>
>> There is nothing stopping a JSP author obtaining a reference to
>> the ImportHandler and conditionally adding classes to import. The 
>> configuration of the ImportHandler could change on every call to
>> the page.
> 
> What about marking the ImportHandler as "dirty" and flushing a cache
> of prior lookups? (Or are we talking about spec-defined classes only,
> here?)

We are talking about spec defined classes here.

Also, ELContext and ImportHandler are not cached across requests and a
class level cache doesn't work because each page can have different imports.

I looked at caching when this issue first arose and we already cache
everything we can. Fixing the performance issue required a different
approach based on making the affected Resolver more aware of the context
in which it was being used so it could skip the ImportHandler in the
affected cases.

Mark

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

Error 404 for autodiscover.xml

[Subhro Paul]

Hi All,

Our client has a simple website consists of some jsps, images, css, 
javascripts and html files. It has two Apache proxy(under loadbalancers) 
and two Tomcat6(under Loadbalancer). All servers are installed under Linux 
environment.This website don't deal with any e-mailing or SMTP features. 
It dose not have any Microsoft exchange facility(I am not sure what it is. 
Got this things while searching in the web). It's a very simple website 
and all are static contents.

But if we see the log we always see the below present in the logs in both 
proxy and tomcat box.

[11/Mar/2016:00:36:04 -0500] "POST /autodiscover/autodiscover.xml 
HTTP/1.1" 404 172
[11/Mar/2016:00:36:06 -0500] "GET /autodiscover/autodiscover.xml HTTP/1.1" 
404 172

Why this /autodiscover/autodiscover.xml is called? Who is calling it? Is 
that a feature of Apache proxy which is automatically called?

Before going to prevent this log I first want to know why is this been 
called?

Thanks & Regards
Subhro Paul
=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you