-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Alex,
On 10/14/18 18:06, Alex O'Ree wrote: > 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 > On Wed, Oct 10, 2018 at 10:23 AM Christopher Schultz < > ch...@christopherschultz.net> wrote: > > Mark and Michael, > > On 10/10/18 05:15, Mark Thomas wrote: >>>> On 08/10/18 21:55, Michael Yoder wrote: >>>>> On Wed, Oct 3, 2018 at 12:50 PM Mark Thomas >>>>> <ma...@apache.org> wrote: >>>>>> 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 >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> > -----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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
