CVE-2016-9775: privilege escalation via removal

Debian Bug report logs - #845385
CVE-2016-9775: privilege escalation via removal

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Paul Szabo <paul.szabo@sydney.edu.au>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: Privilege escalation via removal

Date: Wed, 23 Nov 2016 09:35:34 +1100

Package: tomcat8
Version: 8.0.14-1+deb8u4
Severity: critical
Tags: security

Having installed tomcat8, the directory /etc/tomcat8/Catalina is set
writable by group tomcat8, as per the postinst script. Then the tomcat8
user, in the situation envisaged in DSA-3670 and DSA-3720, see also
  http://seclists.org/fulldisclosure/2016/Oct/4
could use something like commands
  touch /etc/tomcat8/Catalina/attack
  chmod 2747 /etc/tomcat8/Catalina/attack
to create a file:
  # ls -l /etc/tomcat8/Catalina/attack
  -rwxr-Srwx 1 tomcat8 tomcat8 0 Nov 23 09:00 /etc/tomcat8/Catalina/attack
Then if the tomcat8 package is removed (purged?), the postrm script runs
  chown -Rhf root:root /etc/tomcat8/
and that will leave the file world-writable, setgid root:
  # ls -l /etc/tomcat8/Catalina/attack
  -rwxr-Srwx 1 root root 0 Nov 23 09:00 /etc/tomcat8/Catalina/attack
allowing "group root" access to the world.

Cheers, Paul

Paul Szabo   psz@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of Sydney    Australia

Message #10 received at 845385@bugs.debian.org (full text, mbox, reply):

From: Emmanuel Bourg <ebourg@apache.org>

To: Paul Szabo <paul.szabo@sydney.edu.au>, 845385@bugs.debian.org

Subject: Re: Bug#845385: Privilege escalation via removal

Date: Wed, 23 Nov 2016 00:30:54 +0100

Hi Paul,

Thank you very much for reporting this issue. I confirm this happens
when purging the package only. The offending chown was first introduced
in the tomcat6 package 6 years ago [1] as part of the fix for #567548.
The same issue is also found in the tomcat7 package.

Do you think running something like "chmod -R 640 /etc/tomcat8" right
before the chown is an appropriate solution to this issue?

Emmanuel Bourg

[1] https://anonscm.debian.org/cgit/pkg-java/tomcat6.git/commit/?id=f67781f

Message #15 received at 845385@bugs.debian.org (full text, mbox, reply):

From: paul.szabo@sydney.edu.au

To: 845385@bugs.debian.org, ebourg@apache.org

Subject: Re: Bug#845385: Privilege escalation via removal

Date: Wed, 23 Nov 2016 11:46:28 +1100

Dear Emmanuel,

> Do you think running something like "chmod -R 640 /etc/tomcat8" right
> before the chown is an appropriate solution to this issue?

Might protect against "static" things, but vulnerable to a race.

Your postrm script might want to kill all tomcat8 processes, also.
That might be a "good thing": deluser or delgroup might not "work"
with left-over, running processes; and might protect against a race.

But really... why do you care about leaving some "dangling" useless
object, owned by some long-gone UID or GID?

Cheers, Paul

Paul Szabo   psz@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of Sydney    Australia

Message #22 received at 845385@bugs.debian.org (full text, mbox, reply):

From: Markus Koschany <apo@debian.org>

To: 845385@bugs.debian.org

Subject: Re: Privilege escalation via removal

Date: Tue, 29 Nov 2016 23:45:52 +0100

[Message part 1 (text/plain, inline)]

On Wed, 23 Nov 2016 09:35:34 +1100 Paul Szabo <paul.szabo@sydney.edu.au>
wrote:
> Package: tomcat8
> Version: 8.0.14-1+deb8u4
> Severity: critical
> Tags: security
> 
> Having installed tomcat8, the directory /etc/tomcat8/Catalina is set
> writable by group tomcat8, as per the postinst script. Then the tomcat8
> user, in the situation envisaged in DSA-3670 and DSA-3720, see also
>   http://seclists.org/fulldisclosure/2016/Oct/4
> could use something like commands
>   touch /etc/tomcat8/Catalina/attack
>   chmod 2747 /etc/tomcat8/Catalina/attack
> to create a file:
>   # ls -l /etc/tomcat8/Catalina/attack
>   -rwxr-Srwx 1 tomcat8 tomcat8 0 Nov 23 09:00 /etc/tomcat8/Catalina/attack
> Then if the tomcat8 package is removed (purged?), the postrm script runs
>   chown -Rhf root:root /etc/tomcat8/
> and that will leave the file world-writable, setgid root:
>   # ls -l /etc/tomcat8/Catalina/attack
>   -rwxr-Srwx 1 root root 0 Nov 23 09:00 /etc/tomcat8/Catalina/attack
> allowing "group root" access to the world.

I don't understand why this is a security issue when
/etc/tomcat8/Catalina/attack is owned by root:root after the purge and
the tomcat8 user doesn't even exist anymore.

Markus

[signature.asc (application/pgp-signature, attachment)]

Message #27 received at 845385@bugs.debian.org (full text, mbox, reply):

From: Markus Koschany <apo@debian.org>

To: 845385@bugs.debian.org

Subject: Re: Privilege escalation via removal

Date: Tue, 29 Nov 2016 23:59:16 +0100

[Message part 1 (text/plain, inline)]

> I don't understand why this is a security issue when
> /etc/tomcat8/Catalina/attack is owned by root:root after the purge and
> the tomcat8 user doesn't even exist anymore.

Nevermind. I missed the "world". However dpkg warns about that
/etc/tomcat8/Catalina is not empty on purge, so the admin will be
informed that something requires his attention. Besides all tomcat
processes are killed on purge.

[signature.asc (application/pgp-signature, attachment)]

Message #32 received at 845385@bugs.debian.org (full text, mbox, reply):

From: Markus Koschany <apo@debian.org>

To: 845385@bugs.debian.org

Subject: Re: Privilege escalation via removal

Date: Wed, 30 Nov 2016 00:20:35 +0100

[Message part 1 (text/plain, inline)]

I think the solution is quite simple.

Let's replace

chown -Rhf root:root /etc/tomcat8/ || true

with

rm -rf /etc/tomcat8

I mean purge means purge. Remove all files, don't leave anything behind.

As another improvement suggestion for Tomcat 9, we could stop deleting
the tomcat user on purge and let the admin decide. I believe this is
even consensus within the project and will protect against reusing files
with the old GID and UID for something unintended.

[signature.asc (application/pgp-signature, attachment)]

Message #37 received at 845385@bugs.debian.org (full text, mbox, reply):

From: Emmanuel Bourg <ebourg@apache.org>

To: Markus Koschany <apo@debian.org>, 845385@bugs.debian.org

Subject: Re: Bug#845385: Privilege escalation via removal

Date: Wed, 30 Nov 2016 00:29:23 +0100

Le 29/11/2016 à 23:45, Markus Koschany a écrit :

> I don't understand why this is a security issue when
> /etc/tomcat8/Catalina/attack is owned by root:root after the purge and
> the tomcat8 user doesn't even exist anymore.

My understanding is that the file is left with execution permissions for
all users and setgid root after the purge. Any local user can then take
control of the system.

Emmanuel Bourg

Message #42 received at 845385@bugs.debian.org (full text, mbox, reply):

From: Emmanuel Bourg <ebourg@apache.org>

To: Markus Koschany <apo@debian.org>, 845385@bugs.debian.org

Subject: Re: Bug#845385: Privilege escalation via removal

Date: Wed, 30 Nov 2016 13:13:10 +0100

Le 30/11/2016 à 00:20, Markus Koschany a écrit :

> rm -rf /etc/tomcat8
> 
> I mean purge means purge. Remove all files, don't leave anything behind.

That's tempting but I wonder if we aren't missing something.

Other packages are installing things under /etc/tomcat8, for example
solr-tomcat and jspwiki, but fortunately in these cases the packages are
installing symlinks to other configuration files, and by the time
tomcat8 is purged these links have already been removed.

Is there another case where removing the files in /etc/tomcat8 is
undesirable? What about files created by the sysadmin in this directory
(like the ones we avoided to chmod on upgrades in #825786) ?


> As another improvement suggestion for Tomcat 9, we could stop deleting
> the tomcat user on purge and let the admin decide. I believe this is
> even consensus within the project and will protect against reusing files
> with the old GID and UID for something unintended.

I thought the users created by a package were supposed to be removed
when the package is purged, but this isn't a requirement in the policy.
I've found #621833 that deals with this topic and the consensus is
indeed not to remove the user.

If we follow the consensus I would also suggest reusing the same user
when switching to a new version to Tomcat. The last time I switched from
tomcat7 to tomcat8 it was annoying to chmod manually the log files of my
web applications. If there was a unique tomcat user for the
tomcat{7,8,9} package that would be easier.

This would be similar to the jetty8 and jetty9 packages sharing the same
'jetty' user (but in this case the user is also removed when the package
is uninstalled, this is problematic when the old package is removed
after the new one is installed).

Emmanuel Bourg

Message #47 received at 845385@bugs.debian.org (full text, mbox, reply):

From: Emmanuel Bourg <ebourg@apache.org>

To: paul.szabo@sydney.edu.au, 845385@bugs.debian.org

Subject: Re: Bug#845385: Privilege escalation via removal

Date: Wed, 30 Nov 2016 14:17:13 +0100

Hi Paul,

Le 23/11/2016 à 01:46, paul.szabo@sydney.edu.au a écrit :

> Might protect against "static" things, but vulnerable to a race.

I'm not sure to understand, what kind of race could happen here?


> But really... why do you care about leaving some "dangling" useless
> object, owned by some long-gone UID or GID?

I don't know the motivations behind this complexity. I can imagine a
case where an administrator switches from tomcat8 to tomcat9 and doesn't
expect the old package to remove files unknown to him so they can be
moved to the configuration directory of the new package.

The upgrade scenario could look like this:

1. Install tomcat8
2. Declare a web application in /etc/tomcat8/Catalina/localhost
3. Uninstall tomcat8
4. Install tomcat9
5. Move /etc/tomcat8/Catalina/localhost/* to /etc/tomcat9/Catalina/localhost

If the step 3 also removes the webapp configuration the administrator is
going to be angry (but arguably less than having his system hacked).

Emmanuel Bourg

Message #52 received at 845385@bugs.debian.org (full text, mbox, reply):

From: Emmanuel Bourg <ebourg@apache.org>

To: Paul Szabo <paul.szabo@sydney.edu.au>, 845385@bugs.debian.org, Markus Koschany <apo@debian.org>

Subject: Re: Bug#845385: Privilege escalation via removal

Date: Wed, 30 Nov 2016 14:17:51 +0100

Le 22/11/2016 à 23:35, Paul Szabo a écrit :

> Then if the tomcat8 package is removed (purged?), the postrm script runs
>   chown -Rhf root:root /etc/tomcat8/
> and that will leave the file world-writable, setgid root

What about switching the files left to nobody:nogroup instead of
root:root? That would be less disruptive for the stable and oldstable
updates than removing /etc/tomcat8 completely.

Emmanuel Bourg

Message #57 received at 845385@bugs.debian.org (full text, mbox, reply):

From: Markus Koschany <apo@debian.org>

To: Emmanuel Bourg <ebourg@apache.org>, 845385@bugs.debian.org

Cc: Paul Szabo <paul.szabo@sydney.edu.au>

Subject: Re: Bug#845385: Privilege escalation via removal

Date: Wed, 30 Nov 2016 15:18:08 +0100

[Message part 1 (text/plain, inline)]

On 30.11.2016 14:17, Emmanuel Bourg wrote:
> Le 22/11/2016 à 23:35, Paul Szabo a écrit :
> 
>> Then if the tomcat8 package is removed (purged?), the postrm script runs
>>   chown -Rhf root:root /etc/tomcat8/
>> and that will leave the file world-writable, setgid root
> 
> What about switching the files left to nobody:nogroup instead of
> root:root? That would be less disruptive for the stable and oldstable
> updates than removing /etc/tomcat8 completely.

I guess just removing /etc/tomcat8/Catalina would be an option too. As
far as I know nothing else requires it to be present after the removal
of Tomcat. If there were applications with such a dependency we should
take a look at them.

Markus

[signature.asc (application/pgp-signature, attachment)]

Message #62 received at 845385@bugs.debian.org (full text, mbox, reply):

From: paul.szabo@sydney.edu.au

To: 845385@bugs.debian.org, apo@debian.org, ebourg@apache.org

Subject: Re: Bug#845385: Privilege escalation via removal

Date: Thu, 1 Dec 2016 07:32:29 +1100

Emmanuel wrote:

>> Might protect against "static" things, but vulnerable to a race.
> I'm not sure to understand, what kind of race could happen here?

Hmm... You suggested some chmod before chown. Your attacker sits tight,
waits for the chmod, then creates the "bad thing" in readiness for your
chown. The chmod takes time to complete, the chown takes time to get up
and start: plenty of time in between for the attacker to act.

>> But really... why do you care about leaving some "dangling" useless
>> object, owned by some long-gone UID or GID?
>
> I don't know the motivations behind this complexity. I can imagine a
> case where an administrator switches from tomcat8 to tomcat9 and doesn't
> expect the old package to remove files unknown to him so they can be
> moved to the configuration directory of the new package.
>
> The upgrade scenario could look like this:
>
> 1. Install tomcat8
> 2. Declare a web application in /etc/tomcat8/Catalina/localhost
> 3. Uninstall tomcat8
> 4. Install tomcat9
> 5. Move /etc/tomcat8/Catalina/localhost/* to /etc/tomcat9/Catalina/localhost
>
> If the step 3 also removes the webapp configuration the administrator is
> going to be angry (but arguably less than having his system hacked).

You misunderstood. Do not remove things in "step 3": leave alone, do not
chown. (Remove the chown from your script.) Leave it being owned by the
tomcat8 UID, not bother that the UID will be "gone" and un-named.

>> Then if the tomcat8 package is removed (purged?), the postrm script runs
>>   chown -Rhf root:root /etc/tomcat8/
>> and that will leave the file world-writable, setgid root
>
> What about switching the files left to nobody:nogroup instead of
> root:root? That would be less disruptive for the stable and oldstable
> updates than removing /etc/tomcat8 completely.

That would be less dangerous, but still wrong; would still be privilege
escalation, though to a less useful entity.

---

Markus wrote:

>>> Then if the tomcat8 package is removed (purged?), the postrm script runs
>>>   chown -Rhf root:root /etc/tomcat8/
>>> and that will leave the file world-writable, setgid root
>>
>> What about switching the files left to nobody:nogroup instead of
>> root:root? That would be less disruptive for the stable and oldstable
>> updates than removing /etc/tomcat8 completely.
>
> I guess just removing /etc/tomcat8/Catalina would be an option too. As
> far as I know nothing else requires it to be present after the removal
> of Tomcat. If there were applications with such a dependency we should
> take a look at them.

Yes you could "forcibly" remove /etc/tomcat8/Catalina. But then, just
remove all of /etc/tomcat8 so there is definitely nothing left to chown.

---

I now notice a typo in your postrm script. It has lines like:

        if [ -d /var/lib/tomcat8/common ] && [ -z "`(find var/lib/tomcat8/common/classes -type f)`" ] ; then

and are missing a "/" in front of "var". (Of course the "if" are
superfluous, just do the "rmdir".)

---

I now notice that the Debian bug contraption does not CC me on messages:
just being the submitter does not add you to the CC list, you need to
explicitly "subscribe". So I missed a number of intermediate messages.

---

Markus wrote previously:

> ... Besides all tomcat processes are killed on purge.

Where does that happen? I do not think that is true.

Neither are any possible setuid-tomcat8 or setgid-tomcat8 files removed.

---

Cheers, Paul

Paul Szabo   psz@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of Sydney    Australia

Message #65 received at 845385@bugs.debian.org (full text, mbox, reply):

From: pkg-java-maintainers@lists.alioth.debian.org

To: 845385@bugs.debian.org, 845385-submitter@bugs.debian.org

Subject: Pending fixes for bugs in the tomcat8 package

Date: Thu, 01 Dec 2016 07:57:23 +0000

tag 845385 + pending
thanks

Some bugs in the tomcat8 package are closed in revision
e8cd8585faebe1ba1312ef6452ced16d6e7998c7 in branch '  experimental'
by Emmanuel Bourg

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/tomcat8.git/commit/?id=e8cd858

Commit message:

    The tomcat8 user is no longer removed when the package is purged (Closes: #845385)

Message #75 received at 845385-close@bugs.debian.org (full text, mbox, reply):

From: Emmanuel Bourg <ebourg@apache.org>

To: 845385-close@bugs.debian.org

Subject: Bug#845385: fixed in tomcat8 8.5.8-2

Date: Thu, 01 Dec 2016 18:20:30 +0000

Source: tomcat8
Source-Version: 8.5.8-2

We believe that the bug you reported is fixed in the latest version of
tomcat8, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 845385@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Emmanuel Bourg <ebourg@apache.org> (supplier of updated tomcat8 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


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

Format: 1.8
Date: Thu, 01 Dec 2016 18:41:14 +0100
Source: tomcat8
Binary: tomcat8-common tomcat8 tomcat8-user libtomcat8-java libtomcat8-embed-java libservlet3.1-java libservlet3.1-java-doc tomcat8-admin tomcat8-examples tomcat8-docs
Architecture: source all
Version: 8.5.8-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Java Maintainers <pkg-java-maintainers@lists.alioth.debian.org>
Changed-By: Emmanuel Bourg <ebourg@apache.org>
Description:
 libservlet3.1-java - Servlet 3.1, JSP 2.3, EL 3.0 and WebSocket 1.0 Java API classes
 libservlet3.1-java-doc - Servlet 3.1, JSP 2.3, EL 3.0 and WebSocket 1.0 Java API documenta
 libtomcat8-embed-java - Apache Tomcat 8 - Servlet and JSP engine -- embed libraries
 libtomcat8-java - Apache Tomcat 8 - Servlet and JSP engine -- core libraries
 tomcat8    - Apache Tomcat 8 - Servlet and JSP engine
 tomcat8-admin - Apache Tomcat 8 - Servlet and JSP engine -- admin web application
 tomcat8-common - Apache Tomcat 8 - Servlet and JSP engine -- common files
 tomcat8-docs - Apache Tomcat 8 - Servlet and JSP engine -- documentation
 tomcat8-examples - Apache Tomcat 8 - Servlet and JSP engine -- example web applicati
 tomcat8-user - Apache Tomcat 8 - Servlet and JSP engine -- tools to create user
Closes: 833261 843135 845385 845393 845661
Changes:
 tomcat8 (8.5.8-2) unstable; urgency=medium
 .
   * Team upload.
   * Upload to unstable.
   * No longer make /etc/tomcat8/Catalina/localhost writable by the tomcat8 user
     in the postinst script (Closes: #845393)
   * The tomcat8 user is no longer removed when the package is purged
     (Closes: #845385)
   * Compress and remove the access log files with a .txt extension
     (Closes: #845661)
   * Added the delaycompress option to the logrotate configuration
     of catalina.out (Closes: #843135)
   * Changed the home directory for the tomcat8 user from /usr/share/tomcat8
     to /var/lib/tomcat8 (Closes: #833261)
   * Aligned the logging configuration with the upstream one
   * Set the proper permissions for /etc/tomcat8/jaspic-providers.xml
   * Install the new library jaspic-api.jar
   * Install the Maven artifacts for tomcat-storeconfig
   * Simplified debian/rules
Checksums-Sha1:
 ba39e853718cc71f25f039caec4849756efc50dd 2930 tomcat8_8.5.8-2.dsc
 d622980772d71749d69006f4fefd28132397ae73 40980 tomcat8_8.5.8-2.debian.tar.xz
 8776a1921fd655bacd4194740400bea7fdc45c28 240680 libservlet3.1-java-doc_8.5.8-2_all.deb
 bf22e6a60afea4410b29052b238ad56d341a8e0c 391618 libservlet3.1-java_8.5.8-2_all.deb
 eb3a667eced8f3a8a8d2261f8bc04c509a318bc9 3831334 libtomcat8-embed-java_8.5.8-2_all.deb
 591d25c063c10ba6e64a97a1c7772b44bb368fa7 4773086 libtomcat8-java_8.5.8-2_all.deb
 d3d1605723a80d180bb853f0404cbe3dcb1f4fd6 35414 tomcat8-admin_8.5.8-2_all.deb
 5f1748f4f875725454a7db3feec32e09c1b915e5 60942 tomcat8-common_8.5.8-2_all.deb
 797da9f9b03ad998519ae81a69ddfaefb5906c67 714994 tomcat8-docs_8.5.8-2_all.deb
 b43c8ecf7ff5b45a4afb19af0284ed1625bcc662 187274 tomcat8-examples_8.5.8-2_all.deb
 e89a7be273859cea3473ac6bf4eb2f6c494e81fb 37524 tomcat8-user_8.5.8-2_all.deb
 cb6d5e3711bda1f1370c1b8a2291867a91bfed25 49712 tomcat8_8.5.8-2_all.deb
 f3679354e62e7249ba488d419f1c1c40c809dd9e 12383 tomcat8_8.5.8-2_amd64.buildinfo
Checksums-Sha256:
 4516dbf9034a416786e00c4aa6f9a712bb2a7e065b0ffd401c5e6c8015fcc4b2 2930 tomcat8_8.5.8-2.dsc
 a0c8545e9d0d608a0d12c8c4d37da7204875a20b2ef078c199fe53dbe603b983 40980 tomcat8_8.5.8-2.debian.tar.xz
 3d6dc54667b58b88a1f8302872dd93e0ffd5eea74534bcacb131ee846a8b78b2 240680 libservlet3.1-java-doc_8.5.8-2_all.deb
 f72a160fe805cae9d783a0edf3989553122938c39b8528d538905bcfa719f3b6 391618 libservlet3.1-java_8.5.8-2_all.deb
 e560b3abcc74b3322d0132bb69425157b8687a02e27efc9e92c0905e1d4aca40 3831334 libtomcat8-embed-java_8.5.8-2_all.deb
 0e81f00cc5e902ec600928bf63634f873d39fd0b7c2fbea8ab0e1d935bbe217e 4773086 libtomcat8-java_8.5.8-2_all.deb
 d6ff595c2a2032762f8cea739ee06a14b429a8a8ebff8ee012950a58889f93a5 35414 tomcat8-admin_8.5.8-2_all.deb
 18735f210595a5b3220883b4860d6fa832fd6aebb742ff3d8c20d7435f267229 60942 tomcat8-common_8.5.8-2_all.deb
 579bd560339d7ba7f5a78c73e1e47cd813a373d05d5e9578c4f41e39d38145be 714994 tomcat8-docs_8.5.8-2_all.deb
 74b037d0817f2e14d20ca64c97c474bb1633de787d8be89c2f47316fcb0f2067 187274 tomcat8-examples_8.5.8-2_all.deb
 895e34e12f49d6bc204e9b5af0a894d58434554647519cc4be8f9c04326067a2 37524 tomcat8-user_8.5.8-2_all.deb
 8098d6df3c3179f98be93ecbbe6f447f89b889b3fa98fbe5030bd4fe89af054a 49712 tomcat8_8.5.8-2_all.deb
 e907d926af2687ac6a883124aa759a2ff75de063f0a772404ac1b6dfe6ced67c 12383 tomcat8_8.5.8-2_amd64.buildinfo
Files:
 4dd761d1267de9bed906d6b9029f88f0 2930 java optional tomcat8_8.5.8-2.dsc
 d408cb39066cd2df0bd9def6b34ce937 40980 java optional tomcat8_8.5.8-2.debian.tar.xz
 fee006037870888a998d8b8316e458c6 240680 doc optional libservlet3.1-java-doc_8.5.8-2_all.deb
 645e5d60470e45e7b791b5935f8bb9b7 391618 java optional libservlet3.1-java_8.5.8-2_all.deb
 fb139ce768e4092900a3630313f27134 3831334 java optional libtomcat8-embed-java_8.5.8-2_all.deb
 b064fe7990fc79ac25ac6d84f4d64aea 4773086 java optional libtomcat8-java_8.5.8-2_all.deb
 6465f43fae9b3aee94b59446fe466027 35414 java optional tomcat8-admin_8.5.8-2_all.deb
 3e282c0f91fc403c6486991742c0510c 60942 java optional tomcat8-common_8.5.8-2_all.deb
 86c28dd1f8e7c05fca6ce4aae3e792c6 714994 doc optional tomcat8-docs_8.5.8-2_all.deb
 846dc7b74e1aeeaf11806da65dfb658b 187274 java optional tomcat8-examples_8.5.8-2_all.deb
 92721323ea40fba9c86bece597b649f5 37524 java optional tomcat8-user_8.5.8-2_all.deb
 9d603d0185b9cd8f3490bb669944eb8e 49712 java optional tomcat8_8.5.8-2_all.deb
 51e7bf0de8daa8291e5fc39e77b644d8 12383 java optional tomcat8_8.5.8-2_amd64.buildinfo

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEuM5N4hCA3PkD4WxA9RPEGeS50KwFAlhAYUQACgkQ9RPEGeS5
0KyLxQ/8C6yhVXyy0BMb2Iu2Vl6mS47FCgCDs+6GJ5ZLWQtgxwq1IZ2enECqBVSd
zuzlk1rwFJRtd7oskDcQYS/ptIjsbp98Tu1Blw65aF2afzfJwF28/cfL1j4rghp0
U+GYWuZbMK3v6mK8W7J08iKg26e31ox9IF9RxFqVNWXtHBg9igfwOtJrGtITttkc
Rbh/DBFXDQ9WJnBUgl1FyHQp5gPVIyEL63noga857aTKfljkOkM4CT/59mR5sxbM
C/JAR87AJ0fU9xPwTGa+Po8yeJkmgJX6sy6XYfvQ5H9s7SV9zBqhu/JXPYhDSP/X
5mN6rocfGbwn8f3Kn1dF3fDTu3uEhQd/bkNe28/xsIM2peppWHfnjKRS2Ip94MwT
9q5v+uKoUK0eDcdkR7hkcVaAQjrOWC7yK6W08eErUx8j4+Zy5hyDs+UFYi6EoqYQ
9ES//VCC9tm7kmp0u2kqU8mIGyGG2Len2TvgMTG2EEf+xmvPo4D5yTU73cbl8r9w
hB1/R0p9hIYdHZagbKAxQrKVt7toSvuXSUaJRTX1ySCSQsWLE35hPigcd96Wj7c/
Px37s74481pyBq7BNAbDUF2ZkCGLB6Zb1gHjksdsCYmmSpZqpL5RwfRYFIQKeJUX
ujUt4lqNOIheYkiqoORjEzqGIX7yTvfqUCdLgdbRHAmL82HKXYs=
=3l4e
-----END PGP SIGNATURE-----

Message #78 received at 845385@bugs.debian.org (full text, mbox, reply):

From: pkg-java-maintainers@lists.alioth.debian.org

To: 845385@bugs.debian.org, 845385-submitter@bugs.debian.org

Subject: Pending fixes for bugs in the tomcat8 package

Date: Fri, 02 Dec 2016 09:33:38 +0000

tag 845385 + pending
thanks

Some bugs in the tomcat8 package are closed in revision
4f321e73a19688d2605bf284b448c22ae02ddee0 in branch '  jessie' by
Emmanuel Bourg

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/tomcat8.git/commit/?id=4f321e7

Commit message:

    Fixed a privilege escalation when the package is purged (Closes: #845385)

Message #90 received at 845385-close@bugs.debian.org (full text, mbox, reply):

From: Emmanuel Bourg <ebourg@apache.org>

To: 845385-close@bugs.debian.org

Subject: Bug#845385: fixed in tomcat8 8.0.14-1+deb8u5

Date: Fri, 23 Dec 2016 18:32:35 +0000

Source: tomcat8
Source-Version: 8.0.14-1+deb8u5

We believe that the bug you reported is fixed in the latest version of
tomcat8, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 845385@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Emmanuel Bourg <ebourg@apache.org> (supplier of updated tomcat8 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Sat, 17 Dec 2016 09:19:36 +0100
Source: tomcat8
Binary: tomcat8-common tomcat8 tomcat8-user libtomcat8-java libservlet3.1-java libservlet3.1-java-doc tomcat8-admin tomcat8-examples tomcat8-docs
Architecture: source all
Version: 8.0.14-1+deb8u5
Distribution: jessie-security
Urgency: high
Maintainer: Debian Java Maintainers <pkg-java-maintainers@lists.alioth.debian.org>
Changed-By: Emmanuel Bourg <ebourg@apache.org>
Description:
 libservlet3.1-java - Servlet 3.1, JSP 2.3, EL 3.0 and WebSocket 1.0 Java API classes
 libservlet3.1-java-doc - Servlet 3.1, JSP 2.3, EL 3.0 and WebSocket 1.0 Java API documenta
 libtomcat8-java - Apache Tomcat 8 - Servlet and JSP engine -- core libraries
 tomcat8    - Apache Tomcat 8 - Servlet and JSP engine
 tomcat8-admin - Apache Tomcat 8 - Servlet and JSP engine -- admin web application
 tomcat8-common - Apache Tomcat 8 - Servlet and JSP engine -- common files
 tomcat8-docs - Apache Tomcat 8 - Servlet and JSP engine -- documentation
 tomcat8-examples - Apache Tomcat 8 - Servlet and JSP engine -- example web applicati
 tomcat8-user - Apache Tomcat 8 - Servlet and JSP engine -- tools to create user
Closes: 845385 845393
Changes:
 tomcat8 (8.0.14-1+deb8u5) jessie-security; urgency=high
 .
   * Fixed CVE-2016-9774: Potential privilege escalation when the tomcat8
     package is upgraded. Thanks to Paul Szabo for the report (Closes: #845393)
   * Fixed CVE-2016-9775: Potential privilege escalation when the tomcat8
     package is purged. Thanks to Paul Szabo for the report (Closes: #845385)
   * Fixed CVE-2016-6816: The code that parsed the HTTP request line permitted
     invalid characters. This could be exploited, in conjunction with a proxy
     that also permitted the invalid characters but with a different
     interpretation, to inject data into the HTTP response. By manipulating the
     HTTP response the attacker could poison a web-cache, perform an XSS attack
     and/or obtain sensitive information from requests other then their own.
   * Fixed CVE-2016-8735: The JmxRemoteLifecycleListener was not updated to take
     account of Oracle's fix for CVE-2016-3427. Therefore, Tomcat installations
     using this listener remained vulnerable to a similar remote code execution
     vulnerability. This issue has been rated as important rather than critical
     due to the small number of installations using this listener and that it
     would be highly unusual for the JMX ports to be accessible to an attacker
     even when the listener is used.
   * Backported the fix for upstream bug 57377: Remove the restriction that
     prevented the use of SSL when specifying a bind address for the JMX/RMI
     server. Enable SSL to be configured for the registry as well as the server.
   * CVE-2016-5018 follow-up: Applied a missing modification fixing
     a ClassNotFoundException when the security manager is enabled (see #846298)
   * CVE-2016-6797 follow-up: Fixed a regression preventing some applications
     from accessing the global resources (see #845425)
   * CVE-2015-5345 follow-up: Applied a missing modification to DefaultServlet
   * Backported a fix for a test failure in Test*NonLoginAndBasicAuthenticator
     with recent JREs
   * Backported a fix disabling the broken SSLv3 tests
   * Refreshed the expired SSL certificates used by the tests
   * Set the locale when running the tests to prevent locale sensitive tests
     from failing
   * Added asm-all.jar to the test classpath to fix TestWebappServiceLoader
   * Fixed a test failure in the new TestNamingContext test added with the fix
     for CVE-2016-6797
   * Test failures are no longer ignored and now stop the build
Checksums-Sha1:
 863b3c4d475bde4e869f4ebaebf67118dae4b9f9 2842 tomcat8_8.0.14-1+deb8u5.dsc
 9ad63d0fddca86cfd97e8fca65563247e80a718b 70888 tomcat8_8.0.14-1+deb8u5.debian.tar.xz
 c983ffb5480273647fbc13c0dfcd845fd4cdaf38 57498 tomcat8-common_8.0.14-1+deb8u5_all.deb
 c758773f15b912d448024e4495125af61bb093a8 47000 tomcat8_8.0.14-1+deb8u5_all.deb
 b2c8c6de94ce645dcbafcfd4ea597293f063a78f 34530 tomcat8-user_8.0.14-1+deb8u5_all.deb
 feef6365326e829ebf29af02e6c9395a7294f824 4587212 libtomcat8-java_8.0.14-1+deb8u5_all.deb
 aaa54d72e7ecf58eb9c7e342771cfded676b1650 391938 libservlet3.1-java_8.0.14-1+deb8u5_all.deb
 0e664137717a28a462964aef6effb4ccf88b0f74 247386 libservlet3.1-java-doc_8.0.14-1+deb8u5_all.deb
 2e4b17b7870ded1623f89ee22bf61d7bcc835c5e 35942 tomcat8-admin_8.0.14-1+deb8u5_all.deb
 c7c874c57df41fdf45c8932136bfd86777716960 194150 tomcat8-examples_8.0.14-1+deb8u5_all.deb
 cc2e6a53b27dda1e2ad95d0a7abe92fc7eaed4d2 688960 tomcat8-docs_8.0.14-1+deb8u5_all.deb
Checksums-Sha256:
 03a05dc2b15e3241270a7e99c7f5a6afde2fc875dcda8461727970cf5f1b88c8 2842 tomcat8_8.0.14-1+deb8u5.dsc
 2c56c1343672f97fd42b1b38b82716f92fd7a7d3f1006782de3b014973daa30d 70888 tomcat8_8.0.14-1+deb8u5.debian.tar.xz
 e83161efde88bb3f0fd8c146439df5c99be73f61280ed631095f13c98403d498 57498 tomcat8-common_8.0.14-1+deb8u5_all.deb
 dcd7534cf403f239ee8c570795d8d139bb4aaa7556c17a4859cd44fc365f4be6 47000 tomcat8_8.0.14-1+deb8u5_all.deb
 77d611b6c3cc4623f2909fdd04a9ee956d234f5b79ea18fde2135e2e0e696ab4 34530 tomcat8-user_8.0.14-1+deb8u5_all.deb
 e0883845d2e042768363e1425ede323fdc60cbdd95c1d4bcf3323f7422466672 4587212 libtomcat8-java_8.0.14-1+deb8u5_all.deb
 d8c41a1aaecf1e0bab2b28158070e0d2750cf2f0434e917c23b63c7a5a1d5879 391938 libservlet3.1-java_8.0.14-1+deb8u5_all.deb
 f04d84a02294cdc9a6afa8c9dd6007b040bf26ab5b7dd248855bcb9bbc316479 247386 libservlet3.1-java-doc_8.0.14-1+deb8u5_all.deb
 6c4cc9f3793df8702a17b62b55abd7e11e482928f755f00ac00b50b3411b1141 35942 tomcat8-admin_8.0.14-1+deb8u5_all.deb
 9979fdb3802afad02db5a5645a269640e086eb07ecfa200c2b375bfbeadd4595 194150 tomcat8-examples_8.0.14-1+deb8u5_all.deb
 4b85438c34275b10b62757ee5cbe618dce772551d75948a1243265a8bc48a7c7 688960 tomcat8-docs_8.0.14-1+deb8u5_all.deb
Files:
 25c13a968a8dc7daa066d594f05b0dcb 2842 java optional tomcat8_8.0.14-1+deb8u5.dsc
 95e06df78dc1c9398884e55044a237ef 70888 java optional tomcat8_8.0.14-1+deb8u5.debian.tar.xz
 1abdee40b2cde01e1e65cebff7ef7ee6 57498 java optional tomcat8-common_8.0.14-1+deb8u5_all.deb
 2bae4143a2997470561ed1709586a26b 47000 java optional tomcat8_8.0.14-1+deb8u5_all.deb
 f626fcac4e1903ed3eda43968f4fc22f 34530 java optional tomcat8-user_8.0.14-1+deb8u5_all.deb
 8d9fe2adfa73a4dcb4d8c80e0143d5ac 4587212 java optional libtomcat8-java_8.0.14-1+deb8u5_all.deb
 8a457e5d67dc7609f7966af22d56ebea 391938 java optional libservlet3.1-java_8.0.14-1+deb8u5_all.deb
 4192b6c66a1081ce709c37b33a5e6e9d 247386 doc optional libservlet3.1-java-doc_8.0.14-1+deb8u5_all.deb
 9a72fe5cc3bc07a0286004313845381f 35942 java optional tomcat8-admin_8.0.14-1+deb8u5_all.deb
 5e4adc0169686723ffcffc538458120d 194150 java optional tomcat8-examples_8.0.14-1+deb8u5_all.deb
 30156d2df7f5b012bc9858114d16d394 688960 doc optional tomcat8-docs_8.0.14-1+deb8u5_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJYVUMMAAoJEPUTxBnkudCsKvkP/RNqmuIFBgz0PWVleUf1QVXm
7/LJO3Xoc+WAsWjeynEMcZV13+TqeDoPrc6CahstCG7dv5odZffpbelbDNSInxQ+
ka1okoxoUsQCC29109Rh6pLy1j2lX6BovlRzTYgJ7H/a3VcsD+UeJH3TFTqncgG1
GrSmrqi8cTf2Nr3YqEqhpEwGB0EkkHTEXp03GEH8DIKj84oC72ERa5vkkgFNATzp
2YFnzEQLIDCQkcY/gJgEL3k9jNZVI94QOzGmaXiAfhChTRAL39k7NCVgKguNpIdJ
wX1h6nK0UlGfbfUvkQJO93zMVujbzrnFf1htM8uqdfskVcGxlogi0yRKi8ZHBa1t
R7izOWOUTCxem/anWY1Zkt8p9hyXnFr3jalnHmPGRgIfXnM3inPu2FvuOh0bLAMv
pkl1lWVFCYI2ea8X+tl1Mao1JJOJULijGot6QiWYDv1qadqxKkBSByt62vF3PBAn
/udHpYmF+obFe1mAAzunQyhtafeUZyJNIWKthHPszL5pb2D2K7ZB3gtLfAEKG1vk
gMyHsOTXhn51WrfEjcHer12SkUTbmZBNcCE9jjO8/62XPC2dATzMFRQEozjQ5Szr
4ggqqKMHPqDWx3PkjjEESxAjMlT1l+C2+GNvOrKhmIIsRL2vl9brka7ZLEdQ8TZY
U32bDL1Spp1aHg9RzmfP
=C3ZY
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.