Red Hat Bugzilla – Bug 495108
CVE-2008-2025 struts: XSS vulnerability
Last modified: 2016-03-04 06:03:06 EST
Common Vulnerabilities and Exposures assigned an identifier CVE-2008-2025 to
the following vulnerability:
Reference: MISC: https://bugzilla.novell.com/show_bug.cgi?id=385273
Reference: MISC: https://launchpad.net/bugs/cve/2008-2025
Reference: CONFIRM: http://download.opensuse.org/update/10.3-test/repodata/patch-struts-5872.xml
Reference: CONFIRM: http://support.novell.com/security/cve/CVE-2008-2025.html
Reference: URL: http://lists.opensuse.org/opensuse-security-announce/2009-04/msg00003.html
Cross-site scripting (XSS) vulnerability in Apache Struts before
1.2.9-162.31.1 on SUSE Linux Enterprise (SLE) 11, before 1.2.9-108.2
on SUSE openSUSE 10.3, before 1.2.9-198.2 on SUSE openSUSE 11.0, and
before 1.2.9-162.163.2 on SUSE openSUSE 11.1 allows remote attackers
to inject arbitrary web script or HTML via unspecified vectors related
to "insufficient quoting of parameters."
Created attachment 338986 [details]
patch taken from SUSE srpm
This patch is taken from SUSE's 10.3 struts-1.2.9-108.2.src.rpm. It applies without flaw to our RHEL5 sources.
struts-1.2.9-6.12.fc9 has been submitted as an update for Fedora 9.
struts-1.2.9-6.12.fc10 has been submitted as an update for Fedora 10.
struts-1.2.9-6.12.fc11 has been submitted as an update for Fedora 11.
An issue was opened upstream about this, it has a patch associated with it but it has not been committed to the upstream svn yet.
And the proposed patch from upstream:
According to upstream, this is a non security issue:
"I think we disagree on whether this is a vulnerability in Struts or not. In my opinion the vulnerability is not in Struts code, but in any user code that uses unfiltered user input for attribute values. We have fixed XSS vulnerabilities in Struts before - but in those cases it really was a vulnerability in Struts (e.g.rendering a user input url in an error message), rather than trying to prevent dodgy user code from creating a vulnerability.
Lets also put this into context - its not the normal use-case to re-render user input as attribute values - these are normally coded in the jsp page by the developer. Even where a user might want a dynamic value I believe it would be rare for this to be from user input - rather than a *safe* value controlled by the application. The most likely situation where we are re-rending user values is in the *value* of form tags and these have been filtered since Struts 1.0
Now if we had made the decision nine years ago to filter attribute values then maybe that would have been nice and helped protect users from shooting themselves in the foot - but since its worked that way for nine years it seems wrong to me to punish those users have properly filtered attribute values when required and reward those who are self harming."
As a result, and because the upstream proposed changes could introduce problems where existing scripts may no longer work, we will not be correcting this in our struts packages. Future struts packages from upstream will incorporate some hardening, but to apply such hardening to existing packages may end up breaking client applications which is unacceptable for a security update.
Please see https://issues.apache.org/struts/browse/STR-3191 for more information.
(In reply to Vincent Danen from comment #20)
> Please see https://issues.apache.org/struts/browse/STR-3191 for more
New URL for upstream struts bug tracker is: