[Bug 1409838] New: CVE-2016-9879 Spring Security: Improper handling of path parameters allows bypassing the security constraint
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1409838
Bug ID: 1409838
Summary: CVE-2016-9879 Spring Security: Improper handling of
path parameters allows bypassing the security
constraint
Product: Security Response
Component: vulnerability
Keywords: Security
Severity: medium
Priority: medium
Assignee: security-response-team(a)redhat.com
Reporter: amaris(a)redhat.com
CC: abhgupta(a)redhat.com, aileenc(a)redhat.com,
bmcclain(a)redhat.com, chazlett(a)redhat.com,
dblechte(a)redhat.com, dmcphers(a)redhat.com,
eedri(a)redhat.com, gklein(a)redhat.com,
java-sig-commits(a)lists.fedoraproject.org,
jialiu(a)redhat.com, jokerman(a)redhat.com,
kseifried(a)redhat.com, lmeyer(a)redhat.com,
lsurette(a)redhat.com, mgoldboi(a)redhat.com,
michal.skrivanek(a)redhat.com, mmccomas(a)redhat.com,
puntogil(a)libero.it, rbalakri(a)redhat.com,
Rhev-m-bugs(a)redhat.com, sbonazzo(a)redhat.com,
sherold(a)redhat.com, srevivo(a)redhat.com,
tiwillia(a)redhat.com, ydary(a)redhat.com,
ykaul(a)redhat.com
Spring Security does not consider URL path parameters when processing security
constraints. By adding a URL path parameter with an encoded "/" to a request,
an attacker may be able to bypass a security constraint. The root cause of this
issue is a lack of clarity regarding the handling of path parameters in the
Servlet Specification (see below). Some Servlet containers include path
parameters in the value returned for getPathInfo() and some do not. Spring
Security uses the value returned by getPathInfo() as part of the process of
mapping requests to security constraints. The unexpected presence of path
parameters can cause a constraint to be bypassed.
Users of Apache Tomcat (all current versions) are not affected by this
vulnerability since Tomcat follows the guidance previously provided by the
Servlet Expert group and strips path parameters from the value returned by
getContextPath(), getServletPath() and getPathInfo().
Users of other Servlet containers based on Apache Tomcat may or may not be
affected depending on whether or not the handling of path parameters has been
modified.
Users of IBM WebSphere Application Server 8.5.x are known to be affected.
Users of other containers that implement the Servlet specification may be
affected.
Mitigation:
Use a Servlet container known not to include path parameters in the return
values for getServletPath() and getPathInfo()
Upstream bug:
https://github.com/spring-projects/spring-security/issues/4169
External Reference:
https://pivotal.io/security/cve-2016-9879
--
You are receiving this mail because:
You are on the CC list for the bug.
6 years, 9 months
[Bug 1380898] New: Spurious EOF error when reading build.sbt
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1380898
Bug ID: 1380898
Summary: Spurious EOF error when reading build.sbt
Product: Fedora
Version: 24
Component: sbt
Severity: medium
Assignee: willb(a)redhat.com
Reporter: greenrd(a)greenrd.org
QA Contact: extras-qa(a)fedoraproject.org
CC: java-sig-commits(a)lists.fedoraproject.org,
mizdebsk(a)redhat.com, s(a)shk.io, willb(a)redhat.com
Description of problem:
I get this error:
build.sbt:272: error: ';' expected but eof found.
val projectInfoFile = dir / "ProjectInfo.scala"
^
sbt.compiler.EvalException: Error parsing definition. Ensure that there are no
blank lines within a definition.
But the file build.sbt does not end on line 272!
Version-Release number of selected component (if applicable):
sbt-0.13.1-8.fc24.1.noarch
How reproducible:
Always
Steps to Reproduce:
Unfortunately this requires our proprietary source code, but maybe it can be
reproduced by cloning another Scala repo and running sbt compile.
Actual results:
See above
Expected results:
Should build as it does on another machines (e.g. a Fedora 24 machine with the
Lightbend sbt RPM installed).
Additional info:
project/build.properties contains:
sbt.version=0.13.12
--
You are receiving this mail because:
You are on the CC list for the bug.
6 years, 9 months
[Bug 1276653] New: fop fails to include some images
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1276653
Bug ID: 1276653
Summary: fop fails to include some images
Product: Fedora
Version: 23
Component: fop
Severity: high
Assignee: r.landmann(a)redhat.com
Reporter: wboessen(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: c.david86(a)gmail.com,
java-sig-commits(a)lists.fedoraproject.org,
mizdebsk(a)redhat.com, msimacek(a)redhat.com,
msrb(a)redhat.com, rhbugs(a)n-dimensional.de,
r.landmann(a)redhat.com
Created attachment 1087917
--> https://bugzilla.redhat.com/attachment.cgi?id=1087917&action=edit
Complete output from fop on a failed run.
Description of problem:
When building a PDF from a .fo file on F23, some, but not all,
external-graphic elements with a relative path to a file will generate a
"SEVERE: File not found" image.
Version-Release number of selected component (if applicable): fop-2.0-2
How reproducible:
Always
Steps to Reproduce:
1. Have a directory tree like this:
test.fo
Common_Content/images/note.svg
2. include a tag like this in test.fo
<fo:external-graphic width="auto" height="auto" content-width="24pt"
src="url(Common_Content/images/note.svg)"/>
3. run fop
Actual results:
Lots of tracebacks about missing images
Expected results:
PDF renders with images, like fop-1.1 did.
Additional info:
The errors for missing images can be interesting, as the path they refer to has
the leading part doubled. The actual PDF does have empty gaps of the correct
size for the missing image.
--
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=HNt46vlCn3&a=cc_unsubscribe
6 years, 9 months