[SECURITY] CVE-2018-11784 Apache Tomcat - Open Redirect

[Mark Thomas]

CVE-2018-11784 Apache Tomcat - Open Redirect

Severity: Moderate

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 9.0.0.M1 to 9.0.11
Apache Tomcat 8.5.0 to 8.5.33
Apache Tomcat 7.0.23 to 7.0.90
The unsupported 8.0.x release line has not been analysed but is likely
to be affected.

Description:
When the default servlet returned a redirect to a directory (e.g.
redirecting to '/foo/' when the user requested '/foo') a specially
crafted URL could be used to cause the redirect to be generated to any
URI of the attackers choice.

Mitigation:
Users of the affected versions should apply one of the following
mitigations:
- Upgrade to Apache Tomcat 9.0.12 or later.
- Upgrade to Apache Tomcat 8.5.34 or later.
- Upgrade to Apache Tomcat 7.0.91 or later.
- Use mapperDirectoryRedirectEnabled="true" and
mapperContextRootRedirectEnabled="true" on the Context to ensure that
redirects are issued by the Mapper rather than the default Servlet.
See the Context configuration documentation for further important
details.

Credit:
This vulnerability was found by Sergey Bobrov and reported responsibly
to the Apache Tomcat Security Team.

History:
2018-10-03 Original advisory

References:
[1] http://tomcat.apache.org/security-9.html
[2] http://tomcat.apache.org/security-8.html
[3] http://tomcat.apache.org/security-7.html

---------------------------------------------------------------------
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

[Michael Yoder]

Post by Mark Thomas
CVE-2018-11784 Apache Tomcat - Open Redirect

Is it possible to get more information on the "specially crafted URL"?
I'd like more information so that I can test if some of our apps are
vulnerable.

In addition, I'd like to verify that the value of
mapperContextRootRedirectEnabled defaults to "true", so if we don't
alter that value we aren't susceptible?

Thanks and regards,
-Mike Yoder
Cloudera, Inc.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

[Mark Thomas]

Post by Michael Yoder

Post by Mark Thomas
CVE-2018-11784 Apache Tomcat - Open Redirect

Is it possible to get more information on the "specially crafted URL"?
I'd like more information so that I can test if some of our apps are
vulnerable.

Generally, there is a balance to strike here between making it easy for
the less technically competent attackers to construct an attack and
making it easy for end users to figure out if they are vulnerable. The
way we typically do this is by describing the conditions necessary for
an attack to be possible as completely as possible but not providing
details of how to perform an attack.

We also provide references to the commit that fixed the issue. For
someone with the right skills, there is usually enough information in
the description and the commit for a successful attack to be reverse
engineered.

Post by Michael Yoder
In addition, I'd like to verify that the value of
mapperContextRootRedirectEnabled defaults to "true",

For the latest release of each supported Tomcat version, that is
correct. Historically, that is version dependent. Check the docs for the
version you are using.

Post by Michael Yoder
so if we don't
alter that value we aren't susceptible?

Incorrect. As per the announcement both mapperDirectoryRedirectEnabled
and mapperContextRootRedirectEnabled need to be true to avoid this
vulnerability if you are not using a fixed version.

The default for mapperDirectoryRedirectEnabled is false.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

[Christopher Schultz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Mark and Michael,

Post by Mark Thomas

Post by Michael Yoder

Post by Mark Thomas
CVE-2018-11784 Apache Tomcat - Open Redirect

Is it possible to get more information on the "specially crafted
URL"? I'd like more information so that I can test if some of our
apps are vulnerable.

Generally, there is a balance to strike here between making it easy
for the less technically competent attackers to construct an attack
and making it easy for end users to figure out if they are
vulnerable. The way we typically do this is by describing the
conditions necessary for an attack to be possible as completely as
possible but not providing details of how to perform an attack.
We also provide references to the commit that fixed the issue. For
someone with the right skills, there is usually enough information
in the description and the commit for a successful attack to be
reverse engineered.

It doesn't look like Sergey has posted anything (that I can find) that
might be called a full disclosure. If he had, I'd point it out.

If I were you, I'd just make sure that you either (a) upgrade or (b)
use the existing settings to mitigate the potential problem, as
described in the announcement.

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlu+C0QACgkQHPApP6U8
pFhCJQ/9Gw/G8dw46y4ItHFCsPTDiTxGenxMmVAlxt7kisblb8H3o9vK8PU96+PD
Nb44/Vf5hp5XKN5Xuu3czyNjQ2l0QFb/WxZyqSnlWPEWOQs7a6ZFez9MQZ1W1H13
t6qRCSgcOWcrHvXBKjshspHzY6XeQq2Q5kzHntbVZKjQMQif/Cd73XYX0/GIukcF
4tKhQIXRNh99/NOsw6Ot+DgVjksVhVgg62sOuAe7gUh/UNginc07JvYBa9rKgAz+
JP3Z+PvUyCJFzGSoT1cYAniU+ZNiayquEmMxVeJ4VX6ZK2PMhPjEt58yD3NTOCaN
fAE7ct9UICZ8g9WP22OcTAfaYgUSBGSCOxd7DkqM/o06Lv2bTsiWYtOr8bhHNnrO
S7hJJ5a6Tm7TbN4Insm+BQhvts5FeDAsKM92TWGTrAZ52LEhdS2twsRcmCQDE69z
+mmjRTl+W9UTxl6JTmDHj10d/aWYaA3f2SpZ4A18rRP4JSXQm7Ls/st8hR/TwdKC
LsQ9RnmrDLgtSyql9keWhwaD28iQix5KgfFXOLrByCByzORnbP3z9VEu1knO1r1f
Voe8wq8lDf56vRsr5VjjqSgmkeabtz8uxymOSbt8b3spQ6Q2J7y86MDA3/I7ZjTx
cqgS2JyYAgtlD6vyiNeYRG14XBly3vFZeoCmw6CKFSTFSdK8r3I=
=2IHD
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

[Alex O'Ree]

Is there perhaps a patch that can be applied or better yet, a list of jars
that are were affected by this? (I'm just trying to find a simple way to
patch a large volume of servers)

On Wed, Oct 10, 2018 at 10:23 AM Christopher Schultz <

Post by Christopher Schultz
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Mark and Michael,

Post by Mark Thomas

Post by Michael Yoder

Post by Mark Thomas
CVE-2018-11784 Apache Tomcat - Open Redirect

Is it possible to get more information on the "specially crafted
URL"? I'd like more information so that I can test if some of our
apps are vulnerable.

Generally, there is a balance to strike here between making it easy
for the less technically competent attackers to construct an attack
and making it easy for end users to figure out if they are
vulnerable. The way we typically do this is by describing the
conditions necessary for an attack to be possible as completely as
possible but not providing details of how to perform an attack.
We also provide references to the commit that fixed the issue. For
someone with the right skills, there is usually enough information
in the description and the commit for a successful attack to be
reverse engineered.

It doesn't look like Sergey has posted anything (that I can find) that
might be called a full disclosure. If he had, I'd point it out.
If I were you, I'd just make sure that you either (a) upgrade or (b)
use the existing settings to mitigate the potential problem, as
described in the announcement.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlu+C0QACgkQHPApP6U8
pFhCJQ/9Gw/G8dw46y4ItHFCsPTDiTxGenxMmVAlxt7kisblb8H3o9vK8PU96+PD
Nb44/Vf5hp5XKN5Xuu3czyNjQ2l0QFb/WxZyqSnlWPEWOQs7a6ZFez9MQZ1W1H13
t6qRCSgcOWcrHvXBKjshspHzY6XeQq2Q5kzHntbVZKjQMQif/Cd73XYX0/GIukcF
4tKhQIXRNh99/NOsw6Ot+DgVjksVhVgg62sOuAe7gUh/UNginc07JvYBa9rKgAz+
JP3Z+PvUyCJFzGSoT1cYAniU+ZNiayquEmMxVeJ4VX6ZK2PMhPjEt58yD3NTOCaN
fAE7ct9UICZ8g9WP22OcTAfaYgUSBGSCOxd7DkqM/o06Lv2bTsiWYtOr8bhHNnrO
S7hJJ5a6Tm7TbN4Insm+BQhvts5FeDAsKM92TWGTrAZ52LEhdS2twsRcmCQDE69z
+mmjRTl+W9UTxl6JTmDHj10d/aWYaA3f2SpZ4A18rRP4JSXQm7Ls/st8hR/TwdKC
LsQ9RnmrDLgtSyql9keWhwaD28iQix5KgfFXOLrByCByzORnbP3z9VEu1knO1r1f
Voe8wq8lDf56vRsr5VjjqSgmkeabtz8uxymOSbt8b3spQ6Q2J7y86MDA3/I7ZjTx
cqgS2JyYAgtlD6vyiNeYRG14XBly3vFZeoCmw6CKFSTFSdK8r3I=
=2IHD
-----END PGP SIGNATURE-----
---------------------------------------------------------------------

[Christopher Schultz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Alex,

Post by Alex O'Ree
Is there perhaps a patch that can be applied or better yet, a list
of jars that are were affected by this? (I'm just trying to find a
simple way to patch a large volume of servers)

There is nothing official. Nobody has individually identified which
svn revisions fix this issue, so your only options really are:

1. Grab the previous version from source, apply all patches and deploy
(this is the same as just grabbing the new binaries, assuming you
trust ASF distros)

2. Grab the new binaries, determine which JARs are different (which
may not be super-easy), then copy those to each server. But then you
have a server which reports x.y.z but is actually x.y.z+∂ :(

3. Look at all the commits in ∂ and try to guess the problem. Then,
mitigate it at e.g. reverse-proxy of WAF level. One way would be to
prevent redirects to sites other than your own (which is really the
big danger for open-redirects). Just look for sketchy-looking Location
response headers. :)

I'm curious how you handle upgrades in general. This certainly isn't
the first security issue inn Tomcat that requires an update in your
environment. How do you usually handle updates?

- -chris

Post by Alex O'Ree
On Wed, Oct 10, 2018 at 10:23 AM Christopher Schultz <
Mark and Michael,

Post by Mark Thomas

Post by Mark Thomas

On Wed, Oct 3, 2018 at 12:50 PM Mark Thomas

Post by Mark Thomas
CVE-2018-11784 Apache Tomcat - Open Redirect

Is it possible to get more information on the "specially
crafted URL"? I'd like more information so that I can test
if some of our apps are vulnerable.

Generally, there is a balance to strike here between making
it easy for the less technically competent attackers to
construct an attack and making it easy for end users to
figure out if they are vulnerable. The way we typically do
this is by describing the conditions necessary for an attack
to be possible as completely as possible but not providing
details of how to perform an attack.
We also provide references to the commit that fixed the
issue. For someone with the right skills, there is usually
enough information in the description and the commit for a
successful attack to be reverse engineered.

It doesn't look like Sergey has posted anything (that I can find)
that might be called a full disclosure. If he had, I'd point it
out.
If I were you, I'd just make sure that you either (a) upgrade or
(b) use the existing settings to mitigate the potential problem,
as described in the announcement.
-chris

Post by Mark Thomas
---------------------------------------------------------------------

-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvInigACgkQHPApP6U8
pFhgDw/+L0SpWHz4IACgy7xB4ekyHpIt/5wbOEbqTfyZAh0m+LrSZgI73zPJuHtt
pLnpwgx3lqwCiWTTFFpK8CqhiQ+a+2dKtSTeDlKRJuU4QZLDMSrgYpcWlGJ3h6w/
LiM2KlnJ1i/jI95NVvoW8HFh/6wHCJLJV+czZJja3Uh/xQz/MTWhmh5dx3eVEIY6
7WTB/JNO02wzM8EudqHypypXmwI0pMLbsMsjTSikIHf8m41Qyd+XrY60DKZul8dv
L6bolXxH23vGnxiv4fnN+tGzIaT1ptXmJ6u/MWFUODtD3PVR3CdjIp2JrXFd3GVN
wGEow0tPRa3tsUvL/frllk22xhzbtxzu1M0Rf9U02TLB4nolyBIdJ5e3OyAnmS/Q
ap3aAPVnFWz2twBxUbuXkk4aZ39YziziWqyFO36y5BFNKI5EQlI3GryDbmBZ6SeT
vOJnMDwLy8o6kRcChNh1LmpjnbZMTYPmSkKEhfzf1tocDdBHZmd5yTIjBNrS0++V
n572zrrTWiBbca39QKFqEgmB5iy4fWpkVYHPKqmOVT7JLhI74WRnKap9dqrSDGrP
n1F4AjfuUjmG8H5Vo01bHWBav4aJuMDrLQ+Sr+sUl6uWPu5DDsG+1W9t2JAyC2Vq
tfP9XLMNBDV+f0BUaYt2aPXmBmLe5IP8FNVAzO1W/2VJG7c1UrM=
=E/P3
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

[Alex O'Ree]

Basically. I start with the tomcat distro, apply my changes, then zip it
up and distribute. I'm at a situation when patches are preferable over a
complete reinstall of my product thus the inquiry. I can probably just
replace all the tomcat bits and be done with it.


On Thu, Oct 18, 2018, 8:52 AM Christopher Schultz <

Post by Christopher Schultz
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Alex,

Post by Alex O'Ree
Is there perhaps a patch that can be applied or better yet, a list
of jars that are were affected by this? (I'm just trying to find a
simple way to patch a large volume of servers)

There is nothing official. Nobody has individually identified which
1. Grab the previous version from source, apply all patches and deploy
(this is the same as just grabbing the new binaries, assuming you
trust ASF distros)
2. Grab the new binaries, determine which JARs are different (which
may not be super-easy), then copy those to each server. But then you
have a server which reports x.y.z but is actually x.y.z+∂ :(
3. Look at all the commits in ∂ and try to guess the problem. Then,
mitigate it at e.g. reverse-proxy of WAF level. One way would be to
prevent redirects to sites other than your own (which is really the
big danger for open-redirects). Just look for sketchy-looking Location
response headers. :)
I'm curious how you handle upgrades in general. This certainly isn't
the first security issue inn Tomcat that requires an update in your
environment. How do you usually handle updates?
- -chris

Post by Alex O'Ree
On Wed, Oct 10, 2018 at 10:23 AM Christopher Schultz <
Mark and Michael,

Post by Mark Thomas

Post by Mark Thomas

On Wed, Oct 3, 2018 at 12:50 PM Mark Thomas

Post by Mark Thomas
CVE-2018-11784 Apache Tomcat - Open Redirect

Is it possible to get more information on the "specially
crafted URL"? I'd like more information so that I can test
if some of our apps are vulnerable.

Generally, there is a balance to strike here between making
it easy for the less technically competent attackers to
construct an attack and making it easy for end users to
figure out if they are vulnerable. The way we typically do
this is by describing the conditions necessary for an attack
to be possible as completely as possible but not providing
details of how to perform an attack.
We also provide references to the commit that fixed the
issue. For someone with the right skills, there is usually
enough information in the description and the commit for a
successful attack to be reverse engineered.

It doesn't look like Sergey has posted anything (that I can find)
that might be called a full disclosure. If he had, I'd point it
out.
If I were you, I'd just make sure that you either (a) upgrade or
(b) use the existing settings to mitigate the potential problem,
as described in the announcement.
-chris

Post by Mark Thomas
---------------------------------------------------------------------

-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvInigACgkQHPApP6U8
pFhgDw/+L0SpWHz4IACgy7xB4ekyHpIt/5wbOEbqTfyZAh0m+LrSZgI73zPJuHtt
pLnpwgx3lqwCiWTTFFpK8CqhiQ+a+2dKtSTeDlKRJuU4QZLDMSrgYpcWlGJ3h6w/
LiM2KlnJ1i/jI95NVvoW8HFh/6wHCJLJV+czZJja3Uh/xQz/MTWhmh5dx3eVEIY6
7WTB/JNO02wzM8EudqHypypXmwI0pMLbsMsjTSikIHf8m41Qyd+XrY60DKZul8dv
L6bolXxH23vGnxiv4fnN+tGzIaT1ptXmJ6u/MWFUODtD3PVR3CdjIp2JrXFd3GVN
wGEow0tPRa3tsUvL/frllk22xhzbtxzu1M0Rf9U02TLB4nolyBIdJ5e3OyAnmS/Q
ap3aAPVnFWz2twBxUbuXkk4aZ39YziziWqyFO36y5BFNKI5EQlI3GryDbmBZ6SeT
vOJnMDwLy8o6kRcChNh1LmpjnbZMTYPmSkKEhfzf1tocDdBHZmd5yTIjBNrS0++V
n572zrrTWiBbca39QKFqEgmB5iy4fWpkVYHPKqmOVT7JLhI74WRnKap9dqrSDGrP
n1F4AjfuUjmG8H5Vo01bHWBav4aJuMDrLQ+Sr+sUl6uWPu5DDsG+1W9t2JAyC2Vq
tfP9XLMNBDV+f0BUaYt2aPXmBmLe5IP8FNVAzO1W/2VJG7c1UrM=
=E/P3
-----END PGP SIGNATURE-----
---------------------------------------------------------------------

[Christopher Schultz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Alex,

Post by Alex O'Ree
Basically. I start with the tomcat distro, apply my changes, then
zip it up and distribute. I'm at a situation when patches are
preferable over a complete reinstall of my product thus the
inquiry. I can probably just replace all the tomcat bits and be
done with it.

Tomcat only ships with .jar files and configuration. Feel free to just
overwrite all the JAR files with the newer Tomcat ones. It's just as
easy to replace all two-dozen of them as it would be to replace a
single one, right?

- -chris

Post by Alex O'Ree
On Thu, Oct 18, 2018, 8:52 AM Christopher Schultz <
Alex,

Post by Mark Thomas

Post by Alex O'Ree
Is there perhaps a patch that can be applied or better yet, a
list of jars that are were affected by this? (I'm just trying
to find a simple way to patch a large volume of servers)

There is nothing official. Nobody has individually identified
which svn revisions fix this issue, so your only options really
1. Grab the previous version from source, apply all patches and
deploy (this is the same as just grabbing the new binaries,
assuming you trust ASF distros)
2. Grab the new binaries, determine which JARs are different
(which may not be super-easy), then copy those to each server. But
then you have a server which reports x.y.z but is actually x.y.z+∂
:(
3. Look at all the commits in ∂ and try to guess the problem.
Then, mitigate it at e.g. reverse-proxy of WAF level. One way would
be to prevent redirects to sites other than your own (which is
really the big danger for open-redirects). Just look for
sketchy-looking Location response headers. :)
I'm curious how you handle upgrades in general. This certainly
isn't the first security issue inn Tomcat that requires an update
in your environment. How do you usually handle updates?
-chris

Post by Mark Thomas

Post by Alex O'Ree
On Wed, Oct 10, 2018 at 10:23 AM Christopher Schultz <
Mark and Michael,

Post by Mark Thomas

Post by Mark Thomas

On Wed, Oct 3, 2018 at 12:50 PM Mark Thomas

Post by Mark Thomas
CVE-2018-11784 Apache Tomcat - Open Redirect

Is it possible to get more information on the
"specially crafted URL"? I'd like more information so
that I can test if some of our apps are vulnerable.

Generally, there is a balance to strike here between
making it easy for the less technically competent
attackers to construct an attack and making it easy for
end users to figure out if they are vulnerable. The way
we typically do this is by describing the conditions
necessary for an attack to be possible as completely as
possible but not providing details of how to perform an
attack.
We also provide references to the commit that fixed
the issue. For someone with the right skills, there is
usually enough information in the description and the
commit for a successful attack to be reverse
engineered.

It doesn't look like Sergey has posted anything (that I can
find) that might be called a full disclosure. If he had, I'd
point it out.
If I were you, I'd just make sure that you either (a) upgrade
or (b) use the existing settings to mitigate the potential
problem, as described in the announcement.
-chris

Post by Mark Thomas
------------------------------------------------------------------

- ---

Post by Alex O'Ree

Post by Mark Thomas
---------------------------------------------------------------------

-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvIqP0ACgkQHPApP6U8
pFgc9A//Qw9voOII2A/tOhYKSlyAK4psc5Cmq0Yf0DDtDYJzWYNrIHg50gXYB/lh
HnaPEYWLuhIcOHYVI/37FXiOpBLA502U4U/shY5kncA7aNvOYMM7wRd+BM5FJEOK
b6W6P2oFqc+vuJXfGknoT7Ff7CCRkRE7vBRvZH9FHxMXqrpCInl3n5/NAvgjkuHn
pA1rhCsu1+n7y6kDUhiL7HvY2SwYKfqx0WrhDfCyc9bzqPN9urP0uWZm4lJ1LP4V
+PdbtEegTLrBXUA0A5IMXmTHItmACqdDh/K9XDIkfh2201igLFLAnXjFPM72dMUx
wz0jEX/4x/cgy0GEgDG5DURyuHIP8OzuD2xPM3PdB88/DQhN8pnd7nZ6gBPEere8
OAX+nrYNpI6MhHet6zeRAf0HBOXHDrgj86nxB9iPV02JQn5Y8tLIaVKeJ5JbH6L0
rzlDw+0CHXxnaz+p1ZzcxDjUckZQJsAHVZa7SqSfY54Oe4keSX5dihlyi7iT7JEd
On74o+sYd2F2fhEd1QgWT3kxjhdCcgsfOAwZRX+PYCVPfx/L4vv2IyUnotzxXaoM
u267+lUkD1e6/A7pLRRcNreW8TT/C39LphdjaGmShkJzKgixr6py8j/9OmakOY8S
8t0s/xkk3PFUGnKL7gFi/+rfTobbEM3TARRxqhmgkaqJcDB4Gg8=
=AYwn
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

[Alex O'Ree]

Roger that, thanks

On Thu, Oct 18, 2018, 9:38 AM Christopher Schultz <

Post by Christopher Schultz
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Alex,

Post by Alex O'Ree
Basically. I start with the tomcat distro, apply my changes, then
zip it up and distribute. I'm at a situation when patches are
preferable over a complete reinstall of my product thus the
inquiry. I can probably just replace all the tomcat bits and be
done with it.

Tomcat only ships with .jar files and configuration. Feel free to just
overwrite all the JAR files with the newer Tomcat ones. It's just as
easy to replace all two-dozen of them as it would be to replace a
single one, right?
- -chris

Post by Alex O'Ree
On Thu, Oct 18, 2018, 8:52 AM Christopher Schultz <
Alex,

Post by Mark Thomas

Post by Alex O'Ree
Is there perhaps a patch that can be applied or better yet, a
list of jars that are were affected by this? (I'm just trying
to find a simple way to patch a large volume of servers)

There is nothing official. Nobody has individually identified
which svn revisions fix this issue, so your only options really
1. Grab the previous version from source, apply all patches and
deploy (this is the same as just grabbing the new binaries,
assuming you trust ASF distros)
2. Grab the new binaries, determine which JARs are different
(which may not be super-easy), then copy those to each server. But
then you have a server which reports x.y.z but is actually x.y.z+∂
:(
3. Look at all the commits in ∂ and try to guess the problem.
Then, mitigate it at e.g. reverse-proxy of WAF level. One way would
be to prevent redirects to sites other than your own (which is
really the big danger for open-redirects). Just look for
sketchy-looking Location response headers. :)
I'm curious how you handle upgrades in general. This certainly
isn't the first security issue inn Tomcat that requires an update
in your environment. How do you usually handle updates?
-chris

Post by Mark Thomas

Post by Alex O'Ree
On Wed, Oct 10, 2018 at 10:23 AM Christopher Schultz <
Mark and Michael,

Post by Mark Thomas

Post by Mark Thomas

On Wed, Oct 3, 2018 at 12:50 PM Mark Thomas

Post by Mark Thomas
CVE-2018-11784 Apache Tomcat - Open Redirect

Is it possible to get more information on the
"specially crafted URL"? I'd like more information so
that I can test if some of our apps are vulnerable.

Generally, there is a balance to strike here between
making it easy for the less technically competent
attackers to construct an attack and making it easy for
end users to figure out if they are vulnerable. The way
we typically do this is by describing the conditions
necessary for an attack to be possible as completely as
possible but not providing details of how to perform an attack.
We also provide references to the commit that fixed
the issue. For someone with the right skills, there is
usually enough information in the description and the
commit for a successful attack to be reverse
engineered.

It doesn't look like Sergey has posted anything (that I can
find) that might be called a full disclosure. If he had, I'd
point it out.
If I were you, I'd just make sure that you either (a) upgrade
or (b) use the existing settings to mitigate the potential
problem, as described in the announcement.
-chris

Post by Mark Thomas
------------------------------------------------------------------

- ---

Post by Alex O'Ree

Post by Mark Thomas
---------------------------------------------------------------------

-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvIqP0ACgkQHPApP6U8
pFgc9A//Qw9voOII2A/tOhYKSlyAK4psc5Cmq0Yf0DDtDYJzWYNrIHg50gXYB/lh
HnaPEYWLuhIcOHYVI/37FXiOpBLA502U4U/shY5kncA7aNvOYMM7wRd+BM5FJEOK
b6W6P2oFqc+vuJXfGknoT7Ff7CCRkRE7vBRvZH9FHxMXqrpCInl3n5/NAvgjkuHn
pA1rhCsu1+n7y6kDUhiL7HvY2SwYKfqx0WrhDfCyc9bzqPN9urP0uWZm4lJ1LP4V
+PdbtEegTLrBXUA0A5IMXmTHItmACqdDh/K9XDIkfh2201igLFLAnXjFPM72dMUx
wz0jEX/4x/cgy0GEgDG5DURyuHIP8OzuD2xPM3PdB88/DQhN8pnd7nZ6gBPEere8
OAX+nrYNpI6MhHet6zeRAf0HBOXHDrgj86nxB9iPV02JQn5Y8tLIaVKeJ5JbH6L0
rzlDw+0CHXxnaz+p1ZzcxDjUckZQJsAHVZa7SqSfY54Oe4keSX5dihlyi7iT7JEd
On74o+sYd2F2fhEd1QgWT3kxjhdCcgsfOAwZRX+PYCVPfx/L4vv2IyUnotzxXaoM
u267+lUkD1e6/A7pLRRcNreW8TT/C39LphdjaGmShkJzKgixr6py8j/9OmakOY8S
8t0s/xkk3PFUGnKL7gFi/+rfTobbEM3TARRxqhmgkaqJcDB4Gg8=
=AYwn
-----END PGP SIGNATURE-----
---------------------------------------------------------------------