race condition in apport lead to Local Privilege Escalation

[hen]

Hello. I'm Muqing Liu @Singurlar Security Lab. I would like to report a vulnerability that lead to Local Privilege Escalation. I found this vurlnebiltiy together with neoni

An attacker can use this vulnerability to get a root shell, if one of the following conditions is satisfied:
1. If an unprivilieged user ( e.g. nobody ) is allowed to run a command (e.g. ping) as root via sudo.
2. Or `sendmail` package is installed on system (It's may possible but I have not tested.)

Here is the detail:
Apport will check if pid is reused, by check if the start time of the process is later than apport self:
  # /usr/share/apport/apport
  594 apport_start = get_apport_starttime()
  595 process_start = get_process_starttime()
  596 if process_start > apport_start:
  597 error_log('process was replaced after Apport started, ignoring')
  598 sys.exit(0)

But an attacker could reused pid just after apport launched. In such case, get_apport_starttime() == get_process_starttime().

So, an attacker can get root shell under Condition 1, by following steps.
1. prepare a process X to crash, whose pid is A
2. repeating fork process, until current pid reaches A - 2
3. make process X crash, apport will be launched by kernel with pid A - 1. Then attacker kill process X, so pid A is now available.
4. attacker run command `sudo ping 8.8.8.8` with current directory /etc/logrotate.d/. a process running under root:root will re-occupy pid A.
5. Since the start time of sudo and apport are same, line 596 is by-passed. Apport then drop a core file of process X in /etc/logrotate.d

For Condtion 2:
Sudo will execute sendmail to send incident report if sendmail is installed. So arbitrary user can run sudo to trigger sendmail at /etc/logrotate.d. I have not tested this case, but I think it's possible to win the race.

PoC of Condition 1 is attached.

[Seth Arnold (seth-arnold)]

Hello Muqing Liu, thanks for the report; we'll investigate and get back to you shortly.

Thanks

[Seth Arnold (seth-arnold)]

Hello, please use CVE-2021-3899 for this race condition.

Thanks

[hen (523416700-j)]

I found this patch applied four days ago fixed this issue. https://git.launchpad.net/ubuntu/+source/apport/commit/?id=d529748c052e149abf06cc1e6df3f53dd114bb8b

now core file is dropped only in /var/lib/apport/coredump

[Marc Deslauriers (mdeslaur)]

Hi,

Yes, we were working on an Apport update when you filed this bug. The update happens to prevent the privilege escalation your proof-of-concept uses.

But the race condition you found is still there which may allow fooling Apport into using the wrong UID/GID. Though, I'm not sure how it could be used to actually escalate privileges now.

We will work on another Apport update soon which will attempt to harden this further. We will update this bug once we have a fix ready and are ready to propose a public date.

Thanks!

[hen (523416700-j)]

Hi, any updates on this issue?

[Marc Deslauriers (mdeslaur)]

Since we can't totally eliminate the race condition, our current plan is to add an additional check in our next update to make sure the process uid/gid match the ones provided by the kernel. To do so, we need to change the way apport processes the command line, and this has an impact on apport usage inside containers that will require extensive testing.

Since this issue is mitigated by the current Apport versions, we haven't had a chance to test these scenarios yet. Work on this will resume in January. Apologies in the delay in making this issue public.

[hen (523416700-j)]

no problem :-), thank you for quick reply.

[Marc Deslauriers (mdeslaur)]

Here's the current state of the changes to attempt to improve the issue listed in this bug.

While there's no way to completely eliminate the race condition, I think we can make things better by switching over to using non-positional arguments, getting the real UID and GID from the kernel and making sure they match the process.

Switching over to non-positional arguments is going to require a lot of testing to make sure the patched Apport will work with older versions of Apport in containers, and vice-versa.

[Marc Deslauriers (mdeslaur)]

We will be publishing Apport updates including a fix for this issue on 2022-05-17, 18:00 UTC. Thanks!

[Marc Deslauriers (mdeslaur)]

This was published here:

https://ubuntu.com/security/notices/USN-5427-1

Thanks!