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