[Bug 1140314] New: CVE-2013-4444 tomcat: remote code execution via uploaded JSP
by Red Hat Bugzilla
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
8 years, 3 months
[Bug 1004916] New: Package doesn't provide a sysvinit script or systemd service unit
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1004916
Bug ID: 1004916
Summary: Package doesn't provide a sysvinit script or systemd
service unit
Product: Fedora
Version: 19
Component: activemq
Severity: high
Assignee: mspaulding06(a)gmail.com
Reporter: skottler(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: agrimm(a)redhat.com,
java-sig-commits(a)lists.fedoraproject.org,
mspaulding06(a)gmail.com, tdawson(a)redhat.com
Description of problem:
activemq doesn't provide the necessary scripts/config files to start.
Version-Release number of selected component (if applicable):
0:5.6.0-5.fc19
How reproducible:
Always.
Steps to Reproduce:
1. yum install -y activemq activemq-core
2. try starting the service
3. note there is not a service unit
This seems like a fairly major thing to be missing in the packages. Is there
another package or metapackage that needs to be installed for it to work?
--
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=IC3tNZ0uDP&a=cc_unsubscribe
8 years, 4 months
[Bug 1127276] New: CVE-2014-5075 smack: MitM vulnerability
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1127276
Bug ID: 1127276
Summary: CVE-2014-5075 smack: MitM vulnerability
Product: Security Response
Component: vulnerability
Keywords: Security
Severity: medium
Priority: medium
Assignee: security-response-team(a)redhat.com
Reporter: vkaigoro(a)redhat.com
CC: brms-jira(a)redhat.com,
java-sig-commits(a)lists.fedoraproject.org,
pavelp(a)redhat.com, puntogil(a)libero.it,
tkirby(a)redhat.com, weli(a)redhat.com
It was reported [1] that Smack (XMPP client library) is vulnerable to MitM
attacks with a crafted SSL certificates.
Quote from [1]:
...
Details
-------
Smack is using Java's `SSLSocket`, which checks the peer certificate
using an `X509TrustManager`, but does not perform hostname verification.
Therefore, it is possible to redirect the traffic between a Smack-using
application and a legitimate XMPP server through the attacker's server,
merely by providing a valid certificate for a domain under the
attacker's control.
In Smack versions 2.2.0 to 3.4.1, a custom `ServerTrustManager`
implementation was used, which was supplied with the connection's server
name, and performed hostname verification. However, it failed to verify
the basicConstraints and nameConstraints of the certificate chain
(CVE-2014-0363, http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0363)
and has been removed in Smack 4.0.0.
Applications using Smack 2.2.0 to 3.4.1 with a custom `TrustManager` did
not benefit from `ServerTrustManager` and are vulnerable as well, unless
their own `TrustManager` implementation explicitly performs hostname
verification.
...
[1]: http://seclists.org/bugtraq/2014/Aug/29
--
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=vQuZmnHNAP&a=cc_unsubscribe
8 years, 4 months
[Bug 1147963] New: JENKINS script for showing failed jobs is not working
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1147963
Bug ID: 1147963
Summary: JENKINS script for showing failed jobs is not working
Product: Fedora
Version: 21
Component: jenkins
Severity: medium
Assignee: msrb(a)redhat.com
Reporter: amsharma(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: java-sig-commits(a)lists.fedoraproject.org,
msrb(a)redhat.com
Description of problem:
JENKINS script for showing failed jobs is not working
Version-Release number of selected component (if applicable):
[root@dhcp201-185 ~]# rpm -qa | grep jenkins
jenkins-icon-shim-1.0.3-1.fc21.noarch
js-yui2-jenkins-2.9.0-6.fc21.noarch
jenkins-task-reactor-1.4-2.fc21.noarch
jenkins-external-monitor-job-plugin-1.2-1.fc21.noarch
jenkins-javadoc-plugin-1.2-1.fc21.noarch
jenkins-commons-jelly-1.1.20120928-6.fc21.noarch
jenkins-instance-identity-1.3-4.fc21.noarch
jenkins-sshd-1.6-4.fc21.noarch
jenkins-1.581-2.fc21.noarch
jenkins-ant-plugin-1.2-1.fc21.noarch
jenkins-executable-war-1.29-3.fc21.noarch
jenkins-xstream-1.4.7-3.jenkins1.fc21.noarch
trilead-ssh2-217-4.jenkins4.fc21.noarch
jenkins-ssh-cli-auth-1.2-4.fc21.noarch
jenkins-core-1.581-2.fc21.noarch
jenkins-remoting-2.43-1.fc21.noarch
jenkins-json-lib-2.4-7.fc21.noarch
jenkins-junit-plugin-1.1-1.fc21.noarch
jenkins-mailer-plugin-1.11-1.fc21.noarch
jenkins-extras-memory-monitor-1.8-1.fc21.noarch
jenkins-crypto-util-1.4-2.fc21.noarch
jenkins-version-number-1.1-4.fc21.noarch
jenkins-webapp-1.581-2.fc21.noarch
jenkins-winstone-2.3-1.fc21.noarch
jenkins-jexl-1.1-3.20111212.fc21.noarch
jenkins-cli-1.581-2.fc21.noarch
How reproducible:
Always
Steps to Reproduce:
1.go to https://wiki.jenkins-ci.org/display/JENKINS/Failed+Jobs
2. copy script and paste in localhost:8080/script
Actual results:
It does not display anything in output.
Result
Result: []
Expected results:
It should display all failed jobs
Additional info:
I had failed jobs in my jenkins
--
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=63mWa2HTjL&a=cc_unsubscribe
8 years, 6 months
[Bug 1147105] New: CATALINA_OPTS are only read when SECURITY_MANAGER is true
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1147105
Bug ID: 1147105
Summary: CATALINA_OPTS are only read when SECURITY_MANAGER is
true
Product: Fedora
Version: 20
Component: tomcat
Assignee: ivan.afonichev(a)gmail.com
Reporter: awood(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: ivan.afonichev(a)gmail.com,
java-sig-commits(a)lists.fedoraproject.org,
krzysztof.daniel(a)gmail.com
Description of problem:
The CATALINA_OPTS configuration value is ignored during Tomcat start-up unless
the SECURITY_MANAGER configuration value is set to true. By default
SECURITY_MANAGER is set to "false" so this issue can be pretty confusing if
you're trying to add to CATALINA_OPTS and nothing happens.
Version-Release number of selected component (if applicable):
tomcat-7.0.52-1.fc20.noarch
How reproducible: Always
Steps to Reproduce:
1. Edit /etc/tomcat/tomcat.conf
2. Set CATALINA_OPTS to something.
"-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=8000" for
example.
3. Set SECURITY_MANAGER to "false"
3. Restart tomcat.
4. pgrep -fla tomcat
Actual results: The pgrep command reveals that Tomcat is running without the
values set in CATALINA_OPTS.
Expected results: CATALINA_OPTS are present.
Additional info: This bug is actually due to the fix to bug 1051194. In the
bugfix, the reading in of CATALINA_OPTS has been moved in
/usr/libexec/tomcat/server into a block that requires SECURITY_MANAGER to be
true.
if [ "$1" = "start" ] ; then
if [ "${SECURITY_MANAGER}" = "true" ] ; then
FLAGS="${FLAGS} $CATALINA_OPTS"
OPTIONS="${OPTIONS} \
-Djava.security.manager \
-Djava.security.policy==${CATALINA_BASE}/conf/catalina.policy"
fi
run start
I propose that the flags be read before looking at the security manager
settings. Like
if [ "$1" = "start" ] ; then
FLAGS="${FLAGS} $CATALINA_OPTS"
if [ "${SECURITY_MANAGER}" = "true" ] ; then
OPTIONS="${OPTIONS} \
-Djava.security.manager \
-Djava.security.policy==${CATALINA_BASE}/conf/catalina.policy"
fi
run start
Possible OPTIONS should be read outside of the block too?
--
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=H3lP9UbWQ1&a=cc_unsubscribe
8 years, 6 months
[Bug 1157983] New: maven-shared-utils: Test failures
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1157983
Bug ID: 1157983
Summary: maven-shared-utils: Test failures
Product: Fedora
Version: rawhide
Component: maven-shared-utils
Assignee: msrb(a)redhat.com
Reporter: mizdebsk(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: java-sig-commits(a)lists.fedoraproject.org,
mizdebsk(a)redhat.com, msrb(a)redhat.com,
tradej(a)redhat.com
Description of problem:
Update of maven-shared-utils to version 0.7 introduced 2 test failures, which
shourd be investigated.
Version-Release number of selected component (if applicable):
0.7-1
Failed tests:
FileUtilsTest.isASymbolicLink:1375 null
DirectoryScannerTest.followSymlinksFalse:132 expected:<9> but was:<11>
Tests run: 843, Failures: 2, Errors: 0, Skipped: 24
isASymbolicLink(org.apache.maven.shared.utils.io.FileUtilsTest) Time elapsed:
0.011 sec <<< FAILURE!
java.lang.AssertionError: null
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at
org.apache.maven.shared.utils.io.FileUtilsTest.isASymbolicLink(FileUtilsTest.java:1375)
followSymlinksFalse(org.apache.maven.shared.utils.io.DirectoryScannerTest)
Time elapsed: 0.002 sec <<< FAILURE!
java.lang.AssertionError: expected:<9> but was:<11>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:555)
at org.junit.Assert.assertEquals(Assert.java:542)
at
org.apache.maven.shared.utils.io.DirectoryScannerTest.followSymlinksFalse(DirectoryScannerTest.java:132)
--
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=JOXEy6pH7e&a=cc_unsubscribe
8 years, 7 months