Bugzilla Bug 113192

Background 
 ========== 
 Struts is an open source framework for building web applications. The 
 core of the Struts framework is a flexible control layer based on 
 standard technologies such as Java Servlets, JavaBeans, resource 
 bundles, and the Extensible Markup Language (XML). Struts can be used 
 with different Java engines, such as WebLogic, TomCat, JRun, etc. 
  
 Scope 
 ===== 
 After identifying in Struts an error message echoing the path back to 
 the user, Hacktics has conducted a research of identifying a cross site 
 scripting vulnerability in the implementation of this error on different 
 application servers. 
  
 The Finding 
 =========== 
 When attempting to access a non existent Struts action URL (including 
 the Struts URL suffix, e.g. .do), the struts request handler generates 
 an error echoing the path of the requested action. The mechanism 
 generating this error does not perform sufficient input validation nor 
 perform HTML encoding of the output, thus exposing the system, in some 
 environments, to a Cross Site Scripting attack. 
  
 For detailed description and exploit please visit 
 http://www.hacktics.com/AdvStrutsNov05.html 
  
 Versions Tested 
 =============== 
 Vulnerable 
 Struts 1.2.7 Running on WebLogic 8.1 SP4 
 Struts 1.2.7 Running on WebLogic 8.1 SP5 
 Struts 1.2.7 Running on Resin Web Server 
 Non Vulnerable 
 Struts Running on Apache Tomcat 5.5.9 
 Struts Running on Apache Tomcat 5.5.12 
  
 Solution 
 ======== 
 The Apache Struts group has been notified of this vulnerability on 
 November 3rd, and has fixed the problem in the new Struts release 
 (1.2.8). Upgrading to the new version will eliminate the threat. 
 Alternatively, a work around is available on existing versions by 
 configuring the web server to display custom error messages rather than 
 the default ones.

Java herd, please bump to 1.2.8...

Struts 1.2.8 needs commons-validator-1.1.4 which I just added. To speedup
things
we can already start start stabilizing that, but I hope to add struts-1.2.8
also
today. Sorry about this taking a bit long.

Arhces if you want you can test and mark dev-java/commons-validator-1.1.4  
stable. 
 
Note that there is still no fixed struts ebuild. 

Did some looking into this:
betelgeuse@pena /usr/portage/dev-java/struts $ grep KEYWORDS *
ChangeLog:  Added ~ppc64 to KEYWORDS
struts-1.1-r4.ebuild:KEYWORDS="~amd64 ~ppc ppc64 ~sparc ~x86"
struts-1.2.2-r2.ebuild:KEYWORDS="~x86 ~ppc ~amd64"
struts-1.2.4-r2.ebuild:KEYWORDS="~x86 ~ppc ~amd64"
struts-1.2.8.ebuild:KEYWORDS="~amd64 ~ppc ~x86"

The only one stable is ppc64. We also don't have any anything depending on
=dev-java/struts-1.2* in the tree. It might be a packed jar inside something,
but atm we only have Tomcat 5.0 in the tree and that needs =struts-1.1*. Do you
have any idea of this issue is also present in 1.1?

I have no further information. You could try to ask upstream. 

Struts bumped. 

I asked wiktorw@people.pl who is more familiar with j2ee to find out if this
problem is also in struts-1.1 which is included in for example the stable
tomcat. Hopefully he is able to do it during this weekend.

Arches please test and mark struts as well as commons-validator stable. 

In response to the Betelgeuse's request:

I checked the example application from:

http://www.projectrefinery.com/struts.html
http://www.projectrefinery.com/StrutsExample.ear
 
Although simple, it gave me a bit of trouble. First I needed to clean up my
Tomcat/struts installation, because some required libraries were compiled
with jdk1.5. This took a while, but was rather easy. After that I installed
this example app and run it with its own version of struts. It worked.

Then I emerged struts-1.1-r4 and replaced the original files with symlinks:

 WEB-INF/lib/struts.jar -> /usr/share/struts-1.1/lib/struts.jar
 WEB-INF/struts-bean.tld -> /usr/share/struts-1.1/lib/struts-bean.tld
 WEB-INF/struts-html.tld -> /usr/share/struts-1.1/lib/struts-html.tld
 WEB-INF/struts-logic.tld -> /usr/share/struts-1.1/lib/struts-logic.tld
 WEB-INF/struts-template.tld -> /usr/share/struts-1.1/lib/struts-template.tld

There was one file missing in /usr/share/struts-1.1/lib/ however, namely
struts-form.tld (Tag Library Definition). So I left the original one.
This broke this simple app (see attached StrutsExample-problem.txt file).

I also unmasked and emerged struts-1.2.2-r2, struts-1.2.4-r2 and struts-1.2.8
but none of them contained the struts-form.tld.

So, maybe the example was not very well chosen? Maybe it's struts-1.0 based?
But OTOH, the tutorial on the following page:

http://j2ee.masslight.com/Chapter4.html

explicitly states that struts-form.tld is needed for struts app.

I think I'll try another struts-based application...
(sorry for the trouble)

Created an attachment (id=73743) [details]
StrutsExample-problem.txt

Tomcat JSP compiler output after trying to run example struts application.

Tested with struts-1.1 and 1.2.* - the latter didn't even contain the
struts-template.tld file...

Those two tld files are not included in the struts tarball we use:
pena work # find -name "struts-form.tld"
pena work # pwd
/var/tmp/portage/struts-1.2.8/work
pena work # find -name "struts-template.tld"

Do you have any idea if the vulnerability here is also in 1.1.4?

This is still missing the ppc64 stable mark.

I'm sorry. I should have left a comment much earlier! We are currently having   
real troubles with our java environment on ppc64. see bug #94906. So I cannot  
realy test this currently. we (ppc64 team) have to wait for IBM releasing a  
newer version of their jdk/jre.  

I would just close this one without GLSA.

Or maybe downgrade struts-1.1-r4 to ~ppc64 ? I see no reason to keep this bug
opened due to a stable keyword that happens to be on the only arch on which java
wouldn't work :) 

ppc64 team, please tell us what would be a reasonable solution.

I think this is the best solution. so back to unstable on ppc64. 

There is one thing though. struts-1.1-r4 is packed inside the current stable
Tomcat and dev-java/struts-1.1-r4 should go stable with =tomcat-5.0.28* so we
really should find out if it is affected. I was hoping wiktorw would have been
able to do it but it seem I need to bug upstream myself.

(In reply to comment #17)
> I was hoping wiktorw would have been
> able to do it but it seem I need to bug upstream myself.

It's not exactly that way. I've tried (with no luck) the simplest struts-1.0
based application I've found. I did it on Tomcat 5.5 which I emerged using the
java-experimental ebuild. Meanwhile I've switched my development server
completely to the axxo-overlay in the hope of seeing what's going on there.

This has one side effect, that the struts-1.1-r4 does not compile in the
axxo-overlay environment. New struts ebuild comes from the regular portage tree
and the two Java environments are different enough to break the compilation.
I'd have to revert those changes and recompile Tomcat 5.0 before I would be
able to test struts-1.1. And I don't have enough time right now.

I've found two non-trivial struts 1.1 example application I intended to use
as a test suite at. This is a full listing of the applications' components:

=====
(4th page)
http://www.sitepoint.com/article/struts-first-steps
http://www.sitepoint.com/examples/struts/struts_webforum_jars.zip
http://www.sitepoint.com/examples/struts/struts_webforum_src.zip
http://www.sitepoint.com/examples/struts/struts_webforum_war.zip
=====
(3rd page)
http://www.lifl.fr/~dumoulin/tiles/
http://www.lifl.fr/~dumoulin/tiles/doc/installation.html
http://www.lifl.fr/~dumoulin/tiles/tiles.tar.gz
http://www.lifl.fr/~dumoulin/tiles/tiles-src.tar.gz
=====

All the instructions about setting them up can be found online on the sites.

IOW, betelgeuse asked me for help and it turned out that in the current
situation I have to ask for some help too...

Here is what I would do : since with Tomcat, Struts doesn't exhibit the
vulnerable behavior, I would call for stable on both versions struts-1.1-r4 and
struts-1.2.8, so that both users getting it from Tomcat and users getting it by
normal upgrade get a secure combo.

We aren't even sure 1.1 is affected and also the XSS thing isn't such a big
deal anyway (external controls can be added to the vulnerable programs).

This is not a security issue anymore, secure versions are available now. It's
more an old-version cleanup / stableization problem, so please open another bug
about it (or reassign this one if you prefer).

In the meantime, I'll close this security bug as fixed, feel free to reopen if
you disagree.