Bug#840000: libapache-mod-jk: CVE-2016-6808
Looks like Apache is not affected. [1] I guess would be justified here. Markus [1] https://mail-archives.apache.org/mod_mbox/tomcat-users/201610.mbox/%3CCABzHfVmjt6oRKZfETgrP22wX%3DMF%2BSZsYDw2mAJkmhwcHDt0T3Q%40mail.gmail.com%3E signature.asc Description: OpenPGP digital signature
Bug#840000: libapache-mod-jk: CVE-2016-6808
On 07.10.2016 16:20, Salvatore Bonaccorso wrote: > Hi Markus, [...] > Thanks for your investigation! Have you good upstream contact to try > to clarify why the above statement was made? Hi Salvatore, unfortunately not. I'm just the guy who tries to keep these packages alive. But I agree that we need an upstream clarification because I also don't understand why they singled out the IIS server. I'll try to get in contact with them. signature.asc Description: OpenPGP digital signature
Bug#840000: libapache-mod-jk: CVE-2016-6808
Hi Markus, On Fri, Oct 07, 2016 at 03:21:54PM +0200, Markus Koschany wrote: > On 07.10.2016 14:15, Salvatore Bonaccorso wrote: > [...] > > > > Now whilst the affected code is back present in 1.2.0, I need some > > help understanding the actual impact for us. According to the build > > log this common code is as well compiled in into the mod_jk, The > > upstream description though mention that the resulting security impact > > is seems only relevant when run under IIS. > > https://marc.info/?l=oss-security&m=147575324211141&w=2 as well states > > that a mitigation would be to "Where available, use IIS configuration > > to restrict the maximum URI length to 4095 - (the length of the > > longest virtual host name)". > > > > Can you clarify if this is correct? If so we would mark the CVE as > > (unimportant) and thus as well not release a DSA, and a 1:1.2.42 > > upload to unstable can then mark the CVE as fixed. > > > > Please let me know if the above statement about the issue beeing > > relevant only under IIS is correct this way. > > Looking at native/common/jk_uri_worker_map.c it appears that the > affected map_uri_to_worker_ext function is shared between the IIS, > Apache 1.3 and Apache-2.0 modules and the latter is used by Debian. So > for me it looks relevant to us. Thanks for your investigation! Have you good upstream contact to try to clarify why the above statement was made? Regards, Salvatore
Bug#840000: libapache-mod-jk: CVE-2016-6808
On Fri, Oct 07, 2016 at 02:15:32PM +0200, Salvatore Bonaccorso wrote: > Can you clarify if this is correct? If so we would mark the CVE as > (unimportant) and thus as well not release a DSA, and a 1:1.2.42 > upload to unstable can then mark the CVE as fixed. ... or actually (Windows specific) in that case, it turns true. Regards, Salvatore
Bug#840000: libapache-mod-jk: CVE-2016-6808
On 07.10.2016 14:15, Salvatore Bonaccorso wrote: [...] > > Now whilst the affected code is back present in 1.2.0, I need some > help understanding the actual impact for us. According to the build > log this common code is as well compiled in into the mod_jk, The > upstream description though mention that the resulting security impact > is seems only relevant when run under IIS. > https://marc.info/?l=oss-security&m=147575324211141&w=2 as well states > that a mitigation would be to "Where available, use IIS configuration > to restrict the maximum URI length to 4095 - (the length of the > longest virtual host name)". > > Can you clarify if this is correct? If so we would mark the CVE as > (unimportant) and thus as well not release a DSA, and a 1:1.2.42 > upload to unstable can then mark the CVE as fixed. > > Please let me know if the above statement about the issue beeing > relevant only under IIS is correct this way. Looking at native/common/jk_uri_worker_map.c it appears that the affected map_uri_to_worker_ext function is shared between the IIS, Apache 1.3 and Apache-2.0 modules and the latter is used by Debian. So for me it looks relevant to us. Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#840000: libapache-mod-jk: CVE-2016-6808
Control: found -1 1:1.2.37-4 Hi On Fri, Oct 07, 2016 at 01:26:00PM +0200, Salvatore Bonaccorso wrote: > Source: libapache-mod-jk > Version: 1:1.2.41-1 > Severity: important > Tags: security upstream patch > > Hi, > > the following vulnerability was published for libapache-mod-jk. > > CVE-2016-6808[0]: > buffer overflow > > If you fix the vulnerability please also make sure to include the > CVE (Common Vulnerabilities & Exposures) id in your changelog entry. > > For further information see: > > [0] https://security-tracker.debian.org/tracker/CVE-2016-6808 Now whilst the affected code is back present in 1.2.0, I need some help understanding the actual impact for us. According to the build log this common code is as well compiled in into the mod_jk, The upstream description though mention that the resulting security impact is seems only relevant when run under IIS. https://marc.info/?l=oss-security&m=147575324211141&w=2 as well states that a mitigation would be to "Where available, use IIS configuration to restrict the maximum URI length to 4095 - (the length of the longest virtual host name)". Can you clarify if this is correct? If so we would mark the CVE as (unimportant) and thus as well not release a DSA, and a 1:1.2.42 upload to unstable can then mark the CVE as fixed. Please let me know if the above statement about the issue beeing relevant only under IIS is correct this way. Regards, Salvatore
Bug#840000: libapache-mod-jk: CVE-2016-6808
Source: libapache-mod-jk Version: 1:1.2.41-1 Severity: important Tags: security upstream patch Hi, the following vulnerability was published for libapache-mod-jk. CVE-2016-6808[0]: buffer overflow If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2016-6808 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
