Bug#845385: Privilege escalation via removal

paul.szabo at sydney.edu.au paul.szabo at sydney.edu.au
Wed Nov 30 20:32:29 UTC 2016


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



More information about the pkg-java-maintainers mailing list