Re: Virtual event focussed on Tomcat Security

[Maarten van Hulsentop]

Hi Mark,

This sounds like a great idea to me. Security is a very important topic,
and the maturity of the Tomcat makes it a very secure choice for users. I
am sure a lot of people will be interested to join in.

What is not completely clear to me on this event; would this event be
focussed on improving the security of Tomcat from within (as a Hackathon
suggests)? Like trying to find security flaws/improvements and get them
fixed.
or is this meant to be an educational event where information is shared
about secure setups/hardening of the Tomcat in production systems? Or a
little of both?

For the educational/hardening aspect, it could be nice to team up
with/involve OWASP?

I am surely interested to pitch in on this topic!

Kind regards,

Maarten van Hulsentop

Op di 29 sep. 2020 om 13:26 schreef Mark Thomas :

> Hi all,
>
> We (the Tomcat community) have some funding from Google to help us
> improve Tomcat security. Our original plan was to use the funding to
> support an in-person security focussed hackathon. As you would expect,
> those plans are on hold for now. We would, therefore, like to explore
> the possibility of doing something virtually.
>
> The purpose of this email is to gather input from the community about
> what such an event should look like. With that input we can put together
> a plan for the event. So, over to you. What would your ideal virtual
> event focussed on Tomcat Security look like?
>
> Thanks,
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Fwd: [SECURITY] CVE-2017-12615 Apache Tomcat Remote Code Execution via JSP upload

[Maarten van Hulsentop]

Hello,

Op wo 20 sep. 2017 om 09:27 schreef Mark Thomas :

> On 19/09/17 14:10, Mark Thomas wrote:
> > On 19/09/17 14:00, André Warnier (tomcat) wrote:
> >> Hello.
> >>
> >> Did the issue below also affect the DAV application ?
> >
> > Yes, as the WebDAV servlet also processes HTTP PUT requests.
> >
> > The WebDAV servlet extends the Default servlet so they actually share
> > the implementation.
>
> Thinking about this a little more, it will depend on how the WebDAV
> servlet is mapped. While there is a configuration where this would be an
> issue for WebDAV, I don't think it is one that would normally be used.
>
> I have tried to reproduce this issue on a fresh tomcat 7.0.78 installation.
The issue can indeed easily be reproduced on the default servlet by setting
the readonly property to false. After that, it is possible to PUT the jsp
and the GET request will execute.

When i change the default servlet to be the WebDAV servlet, it can not
longer PUT the JSP because of 409 errors.
Adjusting the servlet mapping from / to /* resolves the 409. But doing so
seems to prevent the JSP execution; the GET request will just yield the
contents of the JSP.
What do i need to do to get it reproduced for the WebDAV servlet as well?
Or is this a theoretical thing and can we consider the WebDAV servlet
configured in scenario 3 as not vulnerable in the real world? Does this
also apply for individual web applications configuring a similar web.xml or
is it only reproducable on the global default servlet?

For clarity, my scenarios are;
1. == Default servlet reproduction
- [fresh installation Tomcat 7.0.78]
- Modify [tomcat]/conf/web.xml,
add 
readonlyfalse
to default
- PUT possible
- GET executes JSP -> vulnerable!

2. == WebDAV servlet reproduction with mapping on '/'
- [fresh installation Tomcat 7.0.78]
- Modify [tomcat]/conf/web.xml, change
to  org.apache.catalina.servlets.WebdavServlet
for default
- Modify [tomcat]/conf/web.xml,
add 
readonlyfalse
to default
- PUT fails with 409 message -> not vulnerable?

3. == WebDAV servlet reproduction with mapping on '/*'
- [fresh installation Tomcat 7.0.78]
- Modify [tomcat]/conf/web.xml, change to
org.apache.catalina.servlets.WebdavServlet
for default
- Modify [tomcat]/conf/web.xml,
add 
readonlyfalse
to default
- Modify [tomcat]/conf/web.xml, change url pattern
/ to /*
(for default)
- PUT possible
- GET retrieves the content for the JSP -> not vulnerable right now?

Thank you for your feedback,

Regards,

Maarten van Hulsentop

Tomcat 7.0.63 release date known?

[Maarten van Hulsentop]

Dear Tomcat users,

We are using Apache Tomcat 7 to run our product on, using a number of
features of the Tomcat product, such as the SPNego mechanism. For security
reasons we keep up with the latest supported versions of both Tomcat and
the Oracle JRE. Lately, we have found out that the regression bug
introduced in the Oracle JRE now causes the SPNego authentication to fail.

We see that this is fixed with a work around (the new attribute
applyJava8u40Fix controls this) in Tomcat 8.0.23 release (yay!) and after
some investigation i see this is on the changelog for 7.0.63 as well. Good
news for us! :)

My question would be if there is a release date available for the Tomcat 7
product?

Thanks and keep up the great work (even fixing /workarounding Oracles bugs
;) )

Regards,

Maarten

SAML 2.0 with container managed authentication in Tomcat

[Maarten van Hulsentop]

Dear Tomcat-users,

We are investigating the best way to support SAML 2.0 (SP) authentication
with our application. Our application is using container managed
authentication provided by Tomcat, and works very well with basic
authentication, form authentication, SPnego and others.

My expectation would be that it should be possible to add a Valve and a
Realm and have a 3rd party tool supply the SAML2 Relying Party
implementation.

So far, we have identified a couple of possible candidates.
- Apache CXF Fediz. This project still seems young, but the integration
would be as i expect.
- Spring security might be possible to wrap into a Valve and Realm?
- Picketlink? As stated on
https://docs.jboss.org/author/display/PLINK/SAML+Authenticators+(Tomcat,JBossAS)
- Very own Tomcat support not there yet?
https://issues.apache.org/bugzilla/show_bug.cgi?id=54503
- Shibbolth (on HTTPD, remote user passed through AJP)

Until now we have been using the Shibbolth/HTTPd implementation, but from
Tomcat perspective this is not very 'pure'. We would like to configure it
all in one place, Tomcat.

Whats your view on this? Does anybody else have experience with any of
these, or others? Any best practices?

Thank you!

Regards,

Maarten van Hulsentop

SingleSignOn valve in combination with SPNego

[Maarten van Hulsentop]

Hello all,

We are encountering an issue with the use of the SingleSignOn valve and
SPNego and are looking for a best practice on this. Let me describe our
situation;
Our suite consists of multiple end-user webapplications but also a few
webapplications that accept interaction from other systems. Authentication
from other systems is always done on a BASIC authentication basis, using
username/password.

For the end-user webapplications the method of authentication and
authorization (Valve and Realm) is configurable in the application specific
realms. The end-user applications are closely related so we use the
SingleSignOn valve at global (server.xml) level to share end-user 'logins'.

To make sure that users who succesfully authenticated by an end-user
webapplication cannot access the webapplications for external systems, the
SingleSignOn valve has requireReauthentication set to true. This way a user
can only access the applications for which the username/credential matches.

Now, when we configure SPNego, we have to have a realm for that web
application that always grants the user access, as the authentication for
SPNego is performed completely in the valve. But when a user who
authenticated in a non-SPNego web application tries to access the SPNego
web application, the realm will also allow that user. This is a problematic
situation.

Maybe we could prevent this with the role mechanism, but in some cases we
like to use the tomcatAuthentication="false" on the AJP connector, and in
those cases a role would complicate things.

Any ideas?

Regards,

Maarten

Re: [ANN] Apache Tomcat 7.0.52 released

[Maarten van Hulsentop]

Hello Violeta,

On the security vulnerability site https://tomcat.apache.org/security-7.html,
issue 
CVE-2014-0050is
still reported to be fixed in 7.0.51, which is stated as "not yet
released".
I assume the fix is delivered in 7.0.52 as well, but the vulnerability page
is not updated yet. Can you confirm this?

Thank you very much!

Regards,

Maarten




2014-02-19 13:10 GMT+01:00 Violeta Georgieva :

> The Apache Tomcat team announces the immediate availability of Apache
> Tomcat 7.0.52.
>
> Apache Tomcat is an open source software implementation of the Java
> Servlet, JavaServer Pages and Java Expression Language technologies.
>
> This release contains a number of bug fixes and improvements compared to
> version 7.0.50.
>
> Please refer to the change log for the complete list of changes:
> http://tomcat.apache.org/tomcat-7.0-doc/changelog.html
>
> Note: This version has 4 zip binaries: a generic one and
>   three bundled with Tomcat native binaries for Windows operating
>   systems running on different CPU architectures.
>
> Note: Use of the JSR-356 Java WebSocket 1.0 implementation requires Java 7.
>
> Note: If you use the APR/native AJP or HTTP connector you *must* upgrade
>   to version 1.1.29 or later of the APR/native library.
>
> Downloads:
> http://tomcat.apache.org/download-70.cgi
>
> Migration guides from Apache Tomcat 5.5.x and 6.0.x:
> http://tomcat.apache.org/migration.html
>

Re: Single error page for multiple web applications

[Maarten van Hulsentop]

Thank you all for your input!
I do realize that our use case is somewhat odd, as we have multiple webapps
that have shared resources and are related in that sense.
For now, we should go for the duplication of resources (using Tomcat 7).
However, the webAppMount option looks like a fair option to me, once we
have migrated to Tomcat 8.

Regards,

Maarten



2014/1/1 Christopher Schultz 

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Leo,
>
> On 12/31/13, 3:58 PM, Leo Donahue wrote:
> > On Dec 31, 2013 3:15 AM, "Maarten van Hulsentop"
> >  wrote:
> >>
> >> Hello,
> >>
> >> We are using Tomcat to host a number of web applications as a
> >> uniform solution. We trying to implement something that seems to
> >> be an odd requirement, evh it is really a use case for us.
> >>
> >> We would like to define a single [default] error page for all
> >> web applications residing on this Tomcat instance. After some
> >> experimentation and googling around, it seems that there is no
> >> clear-cut solution for
> > this.
> >> I see a few options;
> >>
> >> - Let the global conf/web.xml define error pages for all web
> >> applications at once. However these are always relative to the
> >> web application context, and require every web application to
> >> pack the error pages again, which is
> > a
> >> duplicate of resources and defeats the DRY principle.
> >
> > I asked a question similar to this a while back regarding JSF
> > templates.
> >
> > If you pick a location to share this resource among all web apps,
> > then your web apps aren't self contained.
> >
> > The solution is in your build / deploy process.
>
> +1
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJSxGvAAAoJEBzwKT+lPKRYWxsQALL6eBfL6J9Gv1Lkw1YY4sHo
> BmVEDiOW2fKpI8U7XJgWeGOJosN0Pd7hrBh4NP8KZtqP8Xx+t7yf+R0iIaftp6a9
> cN237abc629k5x8k3Cg5XwY94mVMVYRTbLu4BnlsERVCVskw+A4dhcAfwwdJRykc
> fg0FbLN0WV33uYz7zFsSl0hxP2Yhxl1ZQBocn8OgwdiEkO17K6NLZhfD54AX3W5i
> CfyXRImO6hdpHg3+XTgEQvyfP0/Ydw4n7B8XqRBN9fjOWc2hQp+SYR6Th8BrPWz1
> tRLDR07SmN3BlwSikAiiX7tibzWAfLBK5ENDJ2nUVWhAlp4A9Hbz6W+eOrHu1Bzy
> ghYVs+MMWqd0axBomKVvBq4giL1jhSB2fMno6HdLup/+FF4cdGmfK3eWM5h15rwq
> +hoXjJguZIA2riKlbn5oPKYTEpiP65ufZ5Wa2ylY5KOgQTvENYWgYNj/3p3E9gQY
> PIh9IFUjSXaeG4dZnx9ouUNGO8cBaFPYiBfTaaPyY0DRsatV96z6zCKu249GEcgM
> GZ1gumDJN0mbfsUayqGfBkhneUi83xwDItejjYxyhlxMv3bYesMxGcnmH1bN5UlC
> n/s438m6CpfvIVTq/aQH0AZqStOeVKR5uBX6nqF+yFb7IWa2XpbVonAjYjlsVMDk
> IaUOf1dAf8ISd41svgSc
> =qThL
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Single error page for multiple web applications

[Maarten van Hulsentop]

Hello Serge,

Thank you for your reply. This option seems to be similar to the first
thing i tried, editing conf/web.xml. As is suggested in
http://stackoverflow.com/questions/13914575/how-to-build-server-level-custom-error-page-in-tomcat

But contrary to what's stated in the stackoverlow message, this does not
work if the error occours in the context of another web application.
The following issue description is similar to mine;
http://anthonyjdev.blogspot.nl/2012/09/custom-error-page-for-all-apps-in-tomcat.html
In this case, even if the location is defined in conf/web.xml (global), the
error pages are being searched for in the context of the web application
that issued the error. In strict J2EE sense, i do understand that
reasoning. That's not what i want though ;)

If i am wrong about the understanding of all of this, please correct me.
But i just tried that stackoverlow approach again and still it seems to be
tied to the webapp that issues the error.

Thank you,

Regards,

Maarten

.





2013/12/31 Serge Fonville 

> Hello Maarten,
>
> When I was in the same boat, I found
>
> http://stackoverflow.com/questions/13914575/how-to-build-server-level-custom-error-page-in-tomcatand
> http://wiki.apache.org/tomcat/FAQ/Miscellaneous#Q6 both very helpful.
>
> I found these by googling
>
> https://www.google.nl/?gws_rd=cr&ei=ALNzUtHWPKKN4wTVv4DgAw#q=tomcat+webapp+error+page&safe=off
>
> HTH
>
> Kind regards/met vriendelijke groet,
>
> Serge Fonville
>
> http://www.sergefonville.nl
>
>
> 2013/12/31 Maarten van Hulsentop 
>
> > Hello,
> >
> > We are using Tomcat to host a number of web applications as a uniform
> > solution. We trying to implement something that seems to be an odd
> > requirement, even though it is really a use case for us.
> >
> > We would like to define a single [default] error page for all web
> > applications residing on this Tomcat instance. After some experimentation
> > and googling around, it seems that there is no clear-cut solution for
> this.
> > I see a few options;
> >
> > - Let the global conf/web.xml define error pages for all web applications
> > at once. However these are always relative to the web application
> context,
> > and require every web application to pack the error pages again, which
> is a
> > duplicate of resources and defeats the DRY principle.
> > - An Error reporting valve can be implemented to handle error pages.
> Simply
> > extend ErrorReportValve delivered from Tomcat and implement the report()
> > method. But then how should this report method behave?
> > 1-  It could build up a HTML page from java code directly (as is being
> done
> > in the Tomcat default implementation of the ErrorReportValve). The
> downside
> > of this would be that it is not possible to style the page afterwards.
> > 2-  It could fetch the HTML page from a location specified in
> configuration
> > (system property or otherwise) and stream it to the client. But is it
> > possible to have dynamic behavior in that case (jsp behavior). I think we
> > would need a RequestDispatcher for that and that is supposed to be in
> > context i presume.
> > 3-  It could fetch the ROOT context (which has to be crossContext=true
> then
> > i assume) and delegate the handling of errors to a page in the root
> > context. This one would have my preference, as it allows the
> configuration
> > of a single error page, while trying to stick (mimic) as much of the
> normal
> > J2EE behavior as possible. But it also seems to be the most tricky one.
> > Also, i am not sure on the crossContext setting. Documentation points out
> > that it should not be set on security conscious environments. My
> experience
> > is that security is always important, so does this make it a no-no or is
> > this a theoretical security risk?
> >
> > Please share your opinions about this, things i missed, or (even better!)
> > your solution :)
> >
> > Thank you in advance!
> > Regards,
> >
> > Maarten van Hulsentop
> >
>

Single error page for multiple web applications

[Maarten van Hulsentop]

Hello,

We are using Tomcat to host a number of web applications as a uniform
solution. We trying to implement something that seems to be an odd
requirement, even though it is really a use case for us.

We would like to define a single [default] error page for all web
applications residing on this Tomcat instance. After some experimentation
and googling around, it seems that there is no clear-cut solution for this.
I see a few options;

- Let the global conf/web.xml define error pages for all web applications
at once. However these are always relative to the web application context,
and require every web application to pack the error pages again, which is a
duplicate of resources and defeats the DRY principle.
- An Error reporting valve can be implemented to handle error pages. Simply
extend ErrorReportValve delivered from Tomcat and implement the report()
method. But then how should this report method behave?
1-  It could build up a HTML page from java code directly (as is being done
in the Tomcat default implementation of the ErrorReportValve). The downside
of this would be that it is not possible to style the page afterwards.
2-  It could fetch the HTML page from a location specified in configuration
(system property or otherwise) and stream it to the client. But is it
possible to have dynamic behavior in that case (jsp behavior). I think we
would need a RequestDispatcher for that and that is supposed to be in
context i presume.
3-  It could fetch the ROOT context (which has to be crossContext=true then
i assume) and delegate the handling of errors to a page in the root
context. This one would have my preference, as it allows the configuration
of a single error page, while trying to stick (mimic) as much of the normal
J2EE behavior as possible. But it also seems to be the most tricky one.
Also, i am not sure on the crossContext setting. Documentation points out
that it should not be set on security conscious environments. My experience
is that security is always important, so does this make it a no-no or is
this a theoretical security risk?

Please share your opinions about this, things i missed, or (even better!)
your solution :)

Thank you in advance!
Regards,

Maarten van Hulsentop

Tomcat SPNEGO valve - role assignment in 'grant-all' realm

[Maarten van Hulsentop]

Hi,

We are configuring our Tomcat web application to authenticate using SPNEGO
(Kerberos in particular) on Tomcat 7.0.29.
Following the step-by-step 'Windows Authentication How-To', i succeeded
doing so. Part of setting it up was configuring a Realm that assigns a role
to the user, because the web application requires this. The Realm is
supposed to grant the role to any user, where the password equals the user
name.

Now, as long as we combine the SPNEGOAuthenticator and this Realm, there is
no issue. But as soon as somebody starts using my special Realm in
combination with, lets say, the BasicAuthenticator, we have introduced a
huge security hole.

In my mind, the responsibilities are assigned differently. The Valves
(Authenticators) should be doing the HTTP request/header/login form/etc
handling, and the Realm should be doing the actual Authentication against
some data source. In the case of SPNEGO, the SPNEGOAuthenticator seems to
try to do the authentication as well, and only delegate to the Realm to
finally grant the role.

Now my questions are; am i right i my assumption of the responsibilities?
Should i be configuring this differently? or am i indeed on the right track?

Regards,

Maarten van Hulsentop