Bug#845385: Privilege escalation via removal

[paul . szabo]

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   p...@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of SydneyAustralia

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#845385: Privilege escalation via removal

[Markus Koschany]

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
Description: OpenPGP digital signature
__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#845385: Privilege escalation via removal

[Emmanuel Bourg]

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

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#845385: Privilege escalation via removal

[Emmanuel Bourg]

Hi Paul,

Le 23/11/2016 à 01:46, paul.sz...@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

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#845385: Privilege escalation via removal

[Emmanuel Bourg]

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

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#845385: Privilege escalation via removal

[Emmanuel Bourg]

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

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#845385: Privilege escalation via removal

[Markus Koschany]

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
Description: OpenPGP digital signature
__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#845385: Privilege escalation via removal

[Markus Koschany]

> 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
Description: OpenPGP digital signature
__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#845385: Privilege escalation via removal

[Markus Koschany]

On Wed, 23 Nov 2016 09:35:34 +1100 Paul Szabo 
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
Description: OpenPGP digital signature
__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#845385: Privilege escalation via removal

[paul . szabo]

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   p...@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of SydneyAustralia

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#845385: Privilege escalation via removal

[Paul Szabo]

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   p...@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of SydneyAustralia

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.