Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=958047
Bug ID: 958047
Summary: woodstox-core:
javax.xml.XMLConstants.FEATURE_SECURE_PROCESSING not
supported
Product: Fedora
Version: rawhide
Component: woodstox-core
Severity: unspecified
Priority: unspecified
Assignee: jcapik(a)redhat.com
Reporter: fweimer(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: java-sig-commits(a)lists.fedoraproject.org,
jcapik(a)redhat.com, mizdebsk(a)redhat.com
Blocks: 958046
Category: ---
This doesn't work:
SAXParserFactory factory = new WstxSAXParserFactory();
factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
SAXParser parser = factory.newSAXParser();
InputSource is = new InputSource(new FileInputStream(args[0]));
parser.parse(is, new DefaultHandler());
It results in:
Exception in thread "main" org.xml.sax.SAXNotRecognizedException: Feature
'http://javax.xml.XMLConstants/feature/secure-processing' not recognized
As a result, it appears impossible to defend against "billion laughs"-style
denial of service attacks, along the lines of:
https://git.fedorahosted.org/cgit/secure-coding.git/tree/defensive-coding/s…https://git.fedorahosted.org/cgit/secure-coding.git/tree/defensive-coding/s…
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=bPCdHpPVN2&a=cc_unsubscribe
Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=958727
Bug ID: 958727
Summary: plexus-utils: XMLWriterUtil should guard against
problematic comments
Product: Fedora
Version: rawhide
Component: plexus-utils
Severity: unspecified
Priority: unspecified
Assignee: fnasser(a)redhat.com
Reporter: fweimer(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: fnasser(a)redhat.com,
java-sig-commits(a)lists.fedoraproject.org,
mizdebsk(a)redhat.com
Blocks: 958220
Category: ---
org.codehaus.plexus.util.xml#writeComment(XMLWriter, String, int, int, int)
does not check if the comment includes a "-->" sequence. This means that text
contained in the command string could be interpreted as XML, possibly leading
to XML injection issues, depending on how this method is being called.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=N5myzkUcYQ&a=cc_unsubscribe
Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=958221
Bug ID: 958221
Summary: plexus-utils: directory traversal in
org.codehaus.plexus.util.Expand
Product: Fedora
Version: rawhide
Component: plexus-utils
Severity: unspecified
Priority: unspecified
Assignee: fnasser(a)redhat.com
Reporter: fweimer(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: fnasser(a)redhat.com,
java-sig-commits(a)lists.fedoraproject.org,
mizdebsk(a)redhat.com
Blocks: 958220
Category: ---
org.codehaus.plexus.util.Expand does not guard against directory traversal, but
such protection is generally expected from unarchiving tools.
I think the class should just be deprecated and removed because there do not
appear to be any users left (not even a test case).
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=hp1lhU9LQd&a=cc_unsubscribe
https://bugzilla.redhat.com/show_bug.cgi?id=1098412
Bug ID: 1098412
Summary: pax-logging: Bundles code from other logging libraries
Product: Fedora
Version: rawhide
Component: pax-logging
Assignee: puntogil(a)libero.it
Reporter: fweimer(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: java-sig-commits(a)lists.fedoraproject.org,
puntogil(a)libero.it
Blocks: 1098237
pax-logging-1.6.9-8.fc21.noarch bundles class files from other Fedora packages
in its JAR files, e.g. org/slf4j/ILoggerFactory (from
slf4j-0:1.7.7-1.fc21.noarch), org/apache/log4j/helpers/ThreadLocalMap (from
log4j-0:1.2.17-16.fc21.noarch), and some OSGI-related classes like
org/osgi/service/log/LogEntry whose main package is a bit unclear.
This is against the Fedora packaging guidelines, specifically
<http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries>.
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1098237
[Bug 1098237] Java "static linking"/class bundling in Fedora
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=DUsKDiC5iv&a=cc_unsubscribe
https://bugzilla.redhat.com/show_bug.cgi?id=1140314
Bug ID: 1140314
Summary: CVE-2013-4444 tomcat: remote code execution via
uploaded JSP
Product: Security Response
Component: vulnerability
Keywords: Security
Severity: high
Priority: high
Assignee: security-response-team(a)redhat.com
Reporter: vdanen(a)redhat.com
CC: akurtako(a)redhat.com, dknox(a)redhat.com,
gmurphy(a)redhat.com, ivan.afonichev(a)gmail.com,
java-sig-commits(a)lists.fedoraproject.org,
jclere(a)redhat.com, jdoyle(a)redhat.com,
krzysztof.daniel(a)gmail.com, lgao(a)redhat.com,
myarboro(a)redhat.com, pslavice(a)redhat.com,
rsvoboda(a)redhat.com, weli(a)redhat.com
As reported fixed in Apache Tomcat 7.0.40 [1]:
In very limited circumstances, it was possible for an attacker to upload a
malicious JSP to a Tomcat server and then trigger the execution of that JSP.
While Remote Code Execution would normally be viewed as a critical
vulnerability, the circumstances under which this is possible are, in the view
of the Tomcat security team, sufficiently limited that this vulnerability is
viewed as important.
For this attack to succeed all of the following requirements must be met:
1. Using Oracle Java 1.7.0 update 25 or earlier (or any other Java
implementation where java.io.File is vulnerable to null byte injection).
2. A web application must be deployed to a vulnerable version of Tomcat.
3. The web application must use the Servlet 3.0 File Upload feature.
4. A file location within a deployed web application must be writeable by the
user the Tomcat process is running as. The Tomcat security documentation
recommends against this.
5. A custom listener for JMX connections (e.g. the JmxRemoteListener that is
not enabled by default) must be configured and be able to load classes from
Tomcat's common class loader (i.e. the custom JMX listener must be placed in
Tomcat's lib directory).
6. The custom JMX listener must be bound to an address other than localhost for
a remote attack (it is bound to localhost by default). If the custom JMX
listener is bound to localhost, a local attack will still be possible.
Note that requirements 2 and 3 may be replaced with the following requirement:
7. A web application is deployed that uses Apache Commons File Upload 1.2.1 or
earlier.
In this case (requirements 1, 4, 5, 6 and 7 met) a similar vulnerability may
exist on any Servlet container, not just Apache Tomcat.
This was fixed in revision 1470437. [2] (April 22, 2013)
This issue was identified by Pierre Ernst of the VMware Security Engineering,
Communications and Response group (vSECR) and reported to the Tomcat security
team via the Pivotal security team on 5 September 2014. It was made public on
10 September 2014.
Affects: 7.0.0 to 7.0.39
[1] http://tomcat.apache.org/security-7.html#Fixed_in_Apache_Tomcat_7.0.40
[2] http://svn.apache.org/viewvc?view=revision&revision=1470437
Statement:
This issue did not affect the versions of tomcat as shipped with Red Hat
Enterprise Linux 5, 6, or 7 nor the versions of tomcat as shipped with JBoss
Enterprise Web Server.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=NIGlAdEiPm&a=cc_unsubscribe