Re: libapache-mod-jk: CVE-2014-8111
Hi Markus,
On Mon, May 25, 2015 at 05:10:48PM +0200, Markus Koschany wrote:
> Hello Salvatore,
>
> On 25.05.2015 09:21, Salvatore Bonaccorso wrote:
> [...]
> >> I think the issue warrants a DSA since it is remotely exploitable
> >> although the severity and impact are probably only moderate for most setups.
> >
> > Sourcewise the debdiffs looks good to me. But no I'm not really
> > familar with the source package. Were the changes sucessfully as well
> > tested in some (production) environment?
>
> I know that the same patch was applied to four Red Hat products one
> month ago. [1] Building and updating the package works as expected. I am
> familiar with the Apache web server but I don't run the Apache + Tomcat
> + mod_jk combination and have no way to test this change in a production
> environment. The change will enable a new default option
> "CollapseSlashesUnmount". For Debian only the changes in the apache-2.0
> module are important but I left the patch intact, who knows what corner
> cases exist out there with Apache-1.3 servers. Judging from the patch
> the new jk_no2slash function is then responsible for removing adjacent
> slashes. I expect that no disruption occurs from applying this change
> but more testing and feedback are appreciated.
Thanks for the explanation. I guess we can do the following. I take
your debdiffs, build them for both wheezy and jessie respectively and
then first we do another call for testing (both on debian-java and as
well debian-security list, exposing the packages to testing). Given no
negative feedback we then can go ahead with the release.
> > To already look ahead: If I see it correctly, wheezy and jessie share
> > the same original source, so
> > https://wiki.debian.org/DebianSecurity/AdvisoryCreation/SecFull#Stable_and_oldstable_sharing_the_same_upstream_tarball
> > will aply, so when we then go ahead, the first upload need to be build
> > with -sa, wait to have it accepted on security-master side, and then
> > upload the second without including the original source (otherwise
> > there are problems when pushing the package to ftp-master from
> > security-master).
>
> Please note that I can't upload the package myself, so someone from the
> Java or security team is needed for the final upload.
Yes noticed it. Given the above, I can take care of doing the upload
to security-master for you.
> >> It was discovered that a JkUnmount rule for a subtree of a previous
> >> JkMount rule could be ignored. This could allow a remote attacker to
> >> potentially access a private artifact in a tree that would otherwise not
> >> be accessible to them.
> >
> > Please add here a introductory description of libapache-mod-jk. E.g.
> > "An information disclosure flaw was found in mod_jk, the Tomcat
> > Connector module for Apache. [...]" (or any improvement to this).
>
> There isn't much to say about libapache-mod-jk, but let's try this:
>
> An information disclosure flaw due to incorrect JkMount/JkUnmount
> directives processing was found in the Apache 2 module mod_jk to forward
> requests from the Apache web server to Tomcat. A JkUnmount rule for a
> subtree of a previous JkMount rule could be ignored. This could allow a
> remote attacker to potentially access a private artifact in a tree that
> would otherwise not be accessible to them.
Thanks.
Regards,
Salvatore
Reply to: