[Bug 1205615] New: CVE-2015-1812 CVE-2015-1813 jenkins: Reflective XSS vulnerability (SECURITY-171, SECURITY-177)
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1205615
Bug ID: 1205615
Summary: CVE-2015-1812 CVE-2015-1813 jenkins: Reflective XSS
vulnerability (SECURITY-171, SECURITY-177)
Product: Security Response
Component: vulnerability
Keywords: Security
Severity: medium
Priority: medium
Assignee: security-response-team(a)redhat.com
Reporter: vkaigoro(a)redhat.com
CC: bleanhar(a)redhat.com, ccoleman(a)redhat.com,
dmcphers(a)redhat.com,
java-sig-commits(a)lists.fedoraproject.org,
jdetiber(a)redhat.com, jialiu(a)redhat.com,
jkeck(a)redhat.com, joelsmith(a)redhat.com,
jokerman(a)redhat.com, kseifried(a)redhat.com,
lmeyer(a)redhat.com, mmccomas(a)redhat.com,
msrb(a)redhat.com
An attacker without any access to Jenkins can navigate the user to a carefully
crafted URL and have the user execute unintended actions. This vulnerability
can be used to attack Jenkins inside firewalls from outside so long as the
location of Jenkins is known to the attacker.
External References:
https://wiki.jenkins-ci.org/display/SECURITY/Jenkins+Security+Advisory+20...
--
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=aUngdTWJZ8&a=cc_unsubscribe
8 years, 2 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, 2 months
[Bug 1222923] New: CVE-2015-2156 netty: HttpOnly cookie bypass
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1222923
Bug ID: 1222923
Summary: CVE-2015-2156 netty: HttpOnly cookie bypass
Product: Security Response
Component: vulnerability
Keywords: Security
Severity: medium
Priority: medium
Assignee: security-response-team(a)redhat.com
Reporter: mprpic(a)redhat.com
CC: aileenc(a)redhat.com, alazarot(a)redhat.com,
asantos(a)redhat.com, aszczucz(a)redhat.com,
bdawidow(a)redhat.com, bkearney(a)redhat.com,
brms-jira(a)redhat.com, cbillett(a)redhat.com,
cdewolf(a)redhat.com, chazlett(a)redhat.com,
cpelland(a)redhat.com, cperry(a)redhat.com,
dandread(a)redhat.com, darran.lofthouse(a)redhat.com,
epp-bugs(a)redhat.com, etirelli(a)redhat.com,
felias(a)redhat.com, fnasser(a)redhat.com,
gvarsami(a)redhat.com, hchiorea(a)redhat.com,
hfnukal(a)redhat.com, huwang(a)redhat.com,
jason.greene(a)redhat.com,
java-sig-commits(a)lists.fedoraproject.org,
jawilson(a)redhat.com, jboss-set(a)redhat.com,
jbpapp-maint(a)redhat.com, jcoleman(a)redhat.com,
jdg-bugs(a)redhat.com, jerboaa(a)gmail.com,
jolee(a)redhat.com, jon.vanalten(a)redhat.com,
jpallich(a)redhat.com, katello-bugs(a)redhat.com,
kconner(a)redhat.com, kseifried(a)redhat.com,
ldimaggi(a)redhat.com, lgao(a)redhat.com,
lpetrovi(a)redhat.com, mbaluch(a)redhat.com,
mmccune(a)redhat.com, mnovotny(a)redhat.com,
msimacek(a)redhat.com, msrb(a)redhat.com,
mweiler(a)redhat.com, mwinkler(a)redhat.com,
myarboro(a)redhat.com, nwallace(a)redhat.com,
ohadlevy(a)redhat.com, pavelp(a)redhat.com,
pgier(a)redhat.com, pslavice(a)redhat.com,
rhq-maint(a)redhat.com, rrajasek(a)redhat.com,
rsvoboda(a)redhat.com, rwagner(a)redhat.com,
rzhang(a)redhat.com,
soa-p-jira(a)post-office.corp.redhat.com,
spinder(a)redhat.com, tcunning(a)redhat.com,
theute(a)redhat.com, tjay(a)redhat.com, tkirby(a)redhat.com,
tomckay(a)redhat.com, ttarrant(a)redhat.com,
twalsh(a)redhat.com, vhalbert(a)redhat.com,
vtunka(a)redhat.com, weli(a)redhat.com
A flaw was found in the way Netty’s CookieDecoder method validated cookie name
and value characters. An attacker could use this flaw to bypass the httpOnly
flag on sensitive cookies.
Upstream patch:
https://github.com/slandelle/netty/commit/800555417e77029dcf8a31d7de44f27...
External References:
https://www.playframework.com/security/vulnerability/CVE-2015-2156-HttpOn...
http://engineering.linkedin.com/security/look-netty%E2%80%99s-recent-secu...
--
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=Vfly1r8bG5&a=cc_unsubscribe
8 years, 2 months
[Bug 1195244] New: Mis-configured logging mutes log messages
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1195244
Bug ID: 1195244
Summary: Mis-configured logging mutes log messages
Product: Fedora
Version: 22
Component: javapackages-tools
Assignee: mizdebsk(a)redhat.com
Reporter: leamas.alec(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: java-sig-commits(a)lists.fedoraproject.org,
mat.booth(a)redhat.com, mizdebsk(a)redhat.com,
msimacek(a)redhat.com, msrb(a)redhat.com
Created attachment 994371
--> https://bugzilla.redhat.com/attachment.cgi?id=994371&action=edit
Test case provoking bug with non-readable metadata.
Description of problem:
Version-Release number of selected component (if applicable):
How reproducible: Always
Steps to Reproduce:
1. Install DecodeIrCaller from
https://copr.fedoraproject.org/coprs/leamas/harctoolbox/
2. For the example, create a bug:
$ sudo chmod 600 /usr/share/maven-metadata/DecodeIrCaller.xml
3.Run attached maven.req. It is a patched version of the thing
run by rpmbuild
$ ./maven.req
4. Watch in output
Processing files: IrpMaster-1.0.2-1.fc21.noarch
No handlers could be found for logger "pyxb.binding.basis"
No handlers could be found for logger "pyxb.binding.basis"
The messages stems from the XML parsing in
javapackages/metadata/pyxbmetadata.py around line 59. Obviously, they are not
really helpful, loggers should be configure
Actual results:
Useless messages
Expected results:
Good messages.
Additional info:
Same thing is likely to happen for any maven-driver spec given a non-readable
metadata dependency. And there are other things which might got wrong, needing
configured logger I guess.
--
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=AcTChb0Kzb&a=cc_unsubscribe
8 years, 3 months
[Bug 1215690] New: [abrt] tomcat-7.0.59-1.fc21: Uncaught exception java.lang.NullPointerException in method org.apache.catalina.loader.WebappClassLoader.getResource()
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1215690
Bug ID: 1215690
Summary: [abrt] tomcat-7.0.59-1.fc21: Uncaught exception
java.lang.NullPointerException in method
org.apache.catalina.loader.WebappClassLoader.getResour
ce()
Product: Fedora
Version: 21
Component: tomcat
Assignee: ivan.afonichev(a)gmail.com
Reporter: redhat(a)lb1a.de
QA Contact: extras-qa(a)fedoraproject.org
CC: alee(a)redhat.com, coolsvap(a)gmail.com,
ivan.afonichev(a)gmail.com,
java-sig-commits(a)lists.fedoraproject.org,
krzysztof.daniel(a)gmail.com
Description of problem:
Tried to reload the geonetwork-opensource webapp via the manager application.
This seemed to fail with endless identical error in the logfile, so i tried to
stop the tomcat server
[root@pazuzu]# service tomcat stop
Redirecting to /bin/systemctl stop tomcat.service
Then abrt popped up.
Version-Release number of selected component:
tomcat-7.0.59-1.fc21
Additional info:
reporter: libreport-2.3.0
abrt-java-connector: 1.0.10
cmdline: /usr/lib/jvm/jre/bin/java
-agentpath:/usr/lib/abrt-java-connector/libabrt-java-connector.so=abrt=on
-classpath
/usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar:/usr/lib/java/commons-daemon.jar
-Dcatalina.base=/usr/share/tomcat -Dcatalina.home=/usr/share/tomcat
-Djava.endorsed.dirs= -Djava.io.tmpdir=/var/cache/tomcat/temp
-Djava.util.logging.config.file=/usr/share/tomcat/conf/logging.properties
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
org.apache.catalina.startup.Bootstrap start
executable: /usr/share/tomcat/bin/bootstrap.jar
java_executable:
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.45-31.b13.fc21.x86_64/jre/bin/java
kernel: 3.19.4-200.fc21.x86_64
pid: 12202
runlevel: N 5
uid: 91
Truncated backtrace:
#1 java.lang.NullPointerException
#2 at
org.apache.catalina.loader.WebappClassLoader.getResource(WebappClassLoader.java:1466)
[file:/usr/share/java/tomcat/catalina.jar]
#3 at
org.apache.catalina.loader.WebappClassLoader.getResource(WebappClassLoader.java:1466)
[file:/usr/share/java/tomcat/catalina.jar]
#4 at
org.apache.catalina.loader.WebappClassLoader.getResource(WebappClassLoader.java:1466)
[file:/usr/share/java/tomcat/catalina.jar]
#5 at
org.apache.catalina.loader.WebappClassLoader.getResource(WebappClassLoader.java:1466)
[file:/usr/share/java/tomcat/catalina.jar]
#6 at
org.apache.catalina.loader.WebappClassLoader.getResource(WebappClassLoader.java:1466)
[file:/usr/share/java/tomcat/catalina.jar]
#7 at
org.apache.catalina.loader.WebappClassLoader.getResource(WebappClassLoader.java:1466)
[file:/usr/share/java/tomcat/catalina.jar]
#8 at
org.apache.catalina.loader.WebappClassLoader.getResource(WebappClassLoader.java:1466)
[file:/usr/share/java/tomcat/catalina.jar]
#9 at
org.apache.catalina.loader.WebappClassLoader.getResource(WebappClassLoader.java:1466)
[file:/usr/share/java/tomcat/catalina.jar]
#10 at
org.apache.catalina.loader.WebappClassLoader.getResource(WebappClassLoader.java:1466)
[file:/usr/share/java/tomcat/catalina.jar]
--
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=Ox2leBR99N&a=cc_unsubscribe
8 years, 3 months
[Bug 1224515] New: default for tomcat temp folder should be multiple instances should be ${catalina.base}/temp
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1224515
Bug ID: 1224515
Summary: default for tomcat temp folder should be multiple
instances should be ${catalina.base}/temp
Product: Fedora
Version: 21
Component: tomcat
Severity: low
Assignee: ivan.afonichev(a)gmail.com
Reporter: edwardquick(a)hotmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: alee(a)redhat.com, ivan.afonichev(a)gmail.com,
java-sig-commits(a)lists.fedoraproject.org,
krzysztof.daniel(a)gmail.com, me(a)coolsvap.net
Description of problem:
When a user configures multiple instances of tomcat, the CATALINA_TMPDIR
setting is not updated to match the instance's temp folder.
Version-Release number of selected component (if applicable):
tomcat-7.0.59-1.fc21.noarch
How reproducible:
The default setting in /etc/tomcat/tomcat.conf is
# System-wide tmp
CATALINA_TMPDIR="/var/cache/tomcat/temp"
Steps to Reproduce:
1. systemctl enable tomcat(a)instance1.service
2. Create catalina base folders (and contents), conf, work, temp, webapps under
/var/lib/tomcats/instance1
3. systemctl start tomcat(a)instance1.service
Actual results:
In the tomcat instance1 process, the temp folder is specified as:
-Djava.io.tmpdir=/var/cache/tomcat/temp
Expected results:
The tomcat instance temp folder should be:
-Djava.io.tmpdir=/var/lib/tomcats/instance1/temp
Additional info:
Note we did nothing to configure LOGGING_PROPERTIES, yet the process correctly
specifies it as we expect
-Djava.util.logging.config.file=/var/lib/tomcats/instance1/conf/logging.properties
This issue is easily fixed with the followiing patch to
/usr/libexec/tomcat/preamble
# diff -u /usr/libexec/tomcat/preamble.orig /usr/libexec/tomcat/preamble
--- /usr/libexec/tomcat/preamble.orig 2015-05-23 23:10:14.979921192 +0100
+++ /usr/libexec/tomcat/preamble 2015-05-23 23:14:07.636951751 +0100
@@ -42,3 +42,11 @@
LOGGING_PROPERTIES="${CATALINA_HOME}/conf/logging.properties"
fi
fi
+
+if [ -z "$CATALINA_TMPDIR" ] ; then
+ CATALINA_TMPDIR="${CATALINA_BASE}/temp"
+ if [ ! -d "${CATALINA_TMPDIR}" ] ; then
+ CATALINA_TMPDIR="${CATALINA_HOME}/temp"
+ fi
+fi
+
--
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=niFb9Utlz4&a=cc_unsubscribe
8 years, 3 months
[Bug 1223569] New: Logs in catalina.out are lost with each RPM update
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1223569
Bug ID: 1223569
Summary: Logs in catalina.out are lost with each RPM update
Product: Fedora
Version: 21
Component: tomcat
Severity: medium
Assignee: ivan.afonichev(a)gmail.com
Reporter: doug.knight(a)karmix.org
QA Contact: extras-qa(a)fedoraproject.org
CC: alee(a)redhat.com, ivan.afonichev(a)gmail.com,
java-sig-commits(a)lists.fedoraproject.org,
krzysztof.daniel(a)gmail.com, me(a)coolsvap.net
Description of problem:
The rpm for tomcat contains /var/log/tomcat/catalina.out in its manifest. Each
time the tomcat package is updated, rpm replaces the catalina.out log with the
mostly-empty file from the package. All logs in catalina.out are lost in the
process.
Version-Release number of selected component (if applicable):
All versions since commit 3cb34c71 (tomcat-6.0.32-1)
How reproducible:
Always
Steps to Reproduce:
1. Install an old version of tomcat
2. Create logs in /var/log/tomcat/catalina.out
3. yum upgrade tomcat
Actual results:
catalina.out is clobbered, and the logs are lost.
Expected results:
Not this.
Additional info:
I recommend dropping catalina.out from the manifest. Since it is a log file,
and should initially be empty, we don't want rpm to manage its contents.
Likewise, we don't care about tracking its metadata since we are using the
/var/log/tomcat directory to control access to the tomcat log files.
I am not sure why we are putting the "tomcat-X.Y.Z RPM installed" message in
catalina.out; it seems like something that belongs in a system log, not an
application log. If we really need to keep that message around, we should add
it with something like
runuser -s /bin/bash -c '/bin/echo
"%{name}-%{major_version}.%{minor_version}.%{micro_version} RPM installed" >>
%{logdir}/catalina.out'
from the %post script.
--
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=ME0qtjP2n5&a=cc_unsubscribe
8 years, 3 months