[Bug 1406703] New: smack: TLS SecurityMode.required bypass via StripTLS attack
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1406703
Bug ID: 1406703
Summary: smack: TLS SecurityMode.required bypass via StripTLS
attack
Product: Security Response
Component: vulnerability
Keywords: Security
Severity: medium
Priority: medium
Assignee: security-response-team(a)redhat.com
Reporter: anemec(a)redhat.com
CC: aileenc(a)redhat.com, alazarot(a)redhat.com,
chazlett(a)redhat.com, etirelli(a)redhat.com,
gvarsami(a)redhat.com,
java-sig-commits(a)lists.fedoraproject.org,
jcoleman(a)redhat.com, kconner(a)redhat.com,
kverlaen(a)redhat.com, ldimaggi(a)redhat.com,
lpetrovi(a)redhat.com, mbaluch(a)redhat.com,
mwinkler(a)redhat.com, nwallace(a)redhat.com,
pavelp(a)redhat.com, projects.rg(a)smart.ms,
puntogil(a)libero.it, rrajasek(a)redhat.com,
rwagner(a)redhat.com, rzhang(a)redhat.com,
soa-p-jira(a)post-office.corp.redhat.com,
tcunning(a)redhat.com, tkirby(a)redhat.com
A vulnerability in the Smack XMPP library was reported where the security of
the TLS connection is not always enforced. By stripping the "starttls"
feature from the server response with a man-in-the-middle tool, an attacker
can force the client to authenticate in clear text even if the
"SecurityMode.required" TLS setting has been set.
References:
http://seclists.org/oss-sec/2016/q4/716
https://community.igniterealtime.org/blogs/ignite/2016/11/22/smack-securi...
Upstream bug:
https://issues.igniterealtime.org/browse/SMACK-739
Upstream patches:
https://github.com/igniterealtime/Smack/commit/059ee99ba0d5ff7758829acf5a...
https://github.com/igniterealtime/Smack/commit/a9d5cd4a611f47123f9561bc5a...
--
You are receiving this mail because:
You are on the CC list for the bug.
6 years, 9 months
[Bug 1344641] New: builddep mojo NPE on pomless projects
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1344641
Bug ID: 1344641
Summary: builddep mojo NPE on pomless projects
Product: Fedora
Version: rawhide
Component: xmvn
Assignee: mizdebsk(a)redhat.com
Reporter: msimacek(a)redhat.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
Description of problem:
XMVn builddep mojo crashes with NPE on tycho-pomless projects. This is because
Model.getLocation("") returns null for these. I inspected the object in
debugger and location hashmap contains only "properties" key which probably got
there via pom inheritance. I'm not sure of a correct solution. AFAIK location
tracking is not mandatory in maven, so XMVn, shouldn't rely on it (determine
whether dep/plugin was inherited by walking the graph?). Or it would probably
be more straightforward to patch polyglot to set the location. Or use the
"properties" key.
Stacktrace:
[ERROR] Failed to execute goal org.fedoraproject.xmvn:xmvn-mojo:2.5.0:builddep
(default-cli) on project eclipse-abrt: Execution default-cli of goal
org.fedoraproject.xmvn:xmvn-mojo:2.5.0:builddep failed. NullPointerException ->
[Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.fedoraproject.xmvn:xmvn-mojo:2.5.0:builddep (default-cli) on project
eclipse-abrt: Execution default-cli of goal
org.fedoraproject.xmvn:xmvn-mojo:2.5.0:builddep failed.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
default-cli of goal org.fedoraproject.xmvn:xmvn-mojo:2.5.0:builddep failed.
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
... 20 more
Caused by: java.lang.NullPointerException
at org.fedoraproject.xmvn.mojo.BuilddepMojo.execute(BuilddepMojo.java:143)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
... 21 more
Version-Release number of selected component (if applicable):
xmvn-0:2.5.0-7.fc25.noarch
How reproducible:
always
Steps to Reproduce:
1. rebuild eclipse-abrt
--
You are receiving this mail because:
You are on the CC list for the bug.
6 years, 9 months
[Bug 1403824] New: CVE-2016-8745 tomcat: information disclosure due to incorrect Processor sharing
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1403824
Bug ID: 1403824
Summary: CVE-2016-8745 tomcat: information disclosure due to
incorrect Processor sharing
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,
alee(a)redhat.com, aszczucz(a)redhat.com,
bbaranow(a)redhat.com, bmaxwell(a)redhat.com,
ccoleman(a)redhat.com, cdewolf(a)redhat.com,
chazlett(a)redhat.com, csutherl(a)redhat.com,
dandread(a)redhat.com, darran.lofthouse(a)redhat.com,
dedgar(a)redhat.com, dmcphers(a)redhat.com,
dosoudil(a)redhat.com, etirelli(a)redhat.com,
felias(a)redhat.com, fnasser(a)redhat.com,
gvarsami(a)redhat.com, gzaronik(a)redhat.com,
hchiorea(a)redhat.com, huwang(a)redhat.com,
ivan.afonichev(a)gmail.com, jason.greene(a)redhat.com,
java-sig-commits(a)lists.fedoraproject.org,
jawilson(a)redhat.com, jboss-set(a)redhat.com,
jclere(a)redhat.com, jcoleman(a)redhat.com,
jdg-bugs(a)redhat.com, jdoyle(a)redhat.com,
jgoulding(a)redhat.com, jialiu(a)redhat.com,
joelsmith(a)redhat.com, jokerman(a)redhat.com,
jolee(a)redhat.com, jshepherd(a)redhat.com,
kconner(a)redhat.com, krzysztof.daniel(a)gmail.com,
kverlaen(a)redhat.com, ldimaggi(a)redhat.com,
lgao(a)redhat.com, lmeyer(a)redhat.com,
lpetrovi(a)redhat.com, mbabacek(a)redhat.com,
mbaluch(a)redhat.com, me(a)coolsvap.net,
miburman(a)redhat.com, mmccomas(a)redhat.com,
mwinkler(a)redhat.com, myarboro(a)redhat.com,
nwallace(a)redhat.com, pavelp(a)redhat.com,
pgier(a)redhat.com, psakar(a)redhat.com,
pslavice(a)redhat.com, rnetuka(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, tkirby(a)redhat.com,
trick(a)vanstaveren.us, ttarrant(a)redhat.com,
twalsh(a)redhat.com, vhalbert(a)redhat.com,
vtunka(a)redhat.com, weli(a)redhat.com
The following flaw was found in Apache Tomcat:
The refactoring of the Connector code for 8.5.x onwards introduced a regression
in the error handling of the send file code for the NIO HTTP connector. An
error during send file processing resulted in the current Processor object
being added to the Processor cache multiple times. This in turn meant that the
same Processor could be used for concurrent requests. Sharing a Processor can
result in information leakage between requests including, not limited to,
session ID and the response body.
This issue affects only versions 8.5.x and later.
Upstream patch:
8.x: https://svn.apache.org/viewvc?view=revision&revision=1771857
9.x: https://svn.apache.org/viewvc?view=revision&revision=1771853
--
You are receiving this mail because:
You are on the CC list for the bug.
6 years, 9 months
[Bug 1418716] New: CVE-2017-2605 jenkins: Re-key admin monitor leaves behind unencrypted credentials in upgraded installations (SECURITY-376)
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1418716
Bug ID: 1418716
Summary: CVE-2017-2605 jenkins: Re-key admin monitor leaves
behind unencrypted credentials in upgraded
installations (SECURITY-376)
Product: Security Response
Component: vulnerability
Keywords: Security
Severity: medium
Priority: medium
Assignee: security-response-team(a)redhat.com
Reporter: anemec(a)redhat.com
CC: abhgupta(a)redhat.com, bleanhar(a)redhat.com,
ccoleman(a)redhat.com, dedgar(a)redhat.com,
dmcphers(a)redhat.com,
java-sig-commits(a)lists.fedoraproject.org,
jgoulding(a)redhat.com, jkeck(a)redhat.com,
joelsmith(a)redhat.com, kseifried(a)redhat.com,
mizdebsk(a)redhat.com, msrb(a)redhat.com,
tdawson(a)redhat.com, tiwillia(a)redhat.com
The following flaw was found in Jenkins:
The re-key admin monitor was introduced in Jenkins 1.498 and re-encrypted all
secrets in JENKINS_HOME with a new key. It also created a backup directory with
all old secrets, and the key used to encrypt them. These backups were
world-readable and not removed afterwards.
Jenkins now deletes the backup directory, if present. Upgrading from before
1.498 will no longer create a backup directory. Administrators relying on file
access permissions in their manually created backups are advised to check them
for the directory
$JENKINS_HOME/jenkins.security.RekeySecretAdminMonitor/backups, and delete it
if present.
All administrative monitors now require the user accessing them to be an
administrator.
External References:
https://wiki.jenkins-ci.org/display/SECURITY/Jenkins+Security+Advisory+20...
Upstream patch:
https://github.com/jenkinsci/jenkins/commit/0be33cf7328fad6a7596ce9505a74...
--
You are receiving this mail because:
You are on the CC list for the bug.
6 years, 9 months
[Bug 1443409] New: jenkins-task-reactor: Running arbitrary Groovy code in Jenskin JVM via Reactor Event ( SECURITY-487)
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1443409
Bug ID: 1443409
Summary: jenkins-task-reactor: Running arbitrary Groovy code in
Jenskin JVM via Reactor Event (SECURITY-487)
Product: Security Response
Component: vulnerability
Keywords: Security
Severity: high
Priority: high
Assignee: security-response-team(a)redhat.com
Reporter: amaris(a)redhat.com
CC: bleanhar(a)redhat.com, ccoleman(a)redhat.com,
dedgar(a)redhat.com, dmcphers(a)redhat.com,
java-sig-commits(a)lists.fedoraproject.org,
jgoulding(a)redhat.com, jkeck(a)redhat.com,
joelsmith(a)redhat.com, kseifried(a)redhat.com,
mizdebsk(a)redhat.com, msrb(a)redhat.com,
tdawson(a)redhat.com
Reactor plugin allows users with Job/Configure permission to run arbitrary
Groovy code inside the Jenkins JVM by defining a Reactor Script that will be
run when a Reactor Event triggers, effectively elevating privileges to
Overall/Run Scripts.
Affects all versions.
--
You are receiving this mail because:
You are on the CC list for the bug.
6 years, 9 months