race condition in apport lead to Local Privilege Escalation

Bug #1948376 reported by hen
258
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Apport
Fix Released
Critical
Unassigned
apport (Ubuntu)
Fix Released
Critical
Unassigned

Bug Description

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.

CVE References

Revision history for this message
hen (523416700-j) wrote :
  • PoC Edit (10.7 KiB, application/x-tar)
hen (523416700-j)
description: updated
Revision history for this message
Seth Arnold (seth-arnold) wrote :

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

Thanks

Revision history for this message
Seth Arnold (seth-arnold) wrote :

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

Thanks

hen (523416700-j)
summary: - race condition in apport lead to Linux Privilege Escalation
+ race condition in apport lead to Local Privilege Escalation
description: updated
hen (523416700-j)
description: updated
Revision history for this message
hen (523416700-j) wrote :

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

Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

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!

Revision history for this message
hen (523416700-j) wrote :

Hi, any updates on this issue?

Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

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.

Revision history for this message
hen (523416700-j) wrote :

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

Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

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.

Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

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

Steve Beattie (sbeattie)
Changed in apport (Ubuntu):
status: New → In Progress
Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

This was published here:

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

Thanks!

Changed in apport (Ubuntu):
status: In Progress → Fix Released
information type: Private Security → Public Security
Benjamin Drung (bdrung)
Changed in apport:
milestone: none → 2.21.0
status: New → Fix Committed
Benjamin Drung (bdrung)
Changed in apport:
status: Fix Committed → Fix Released
importance: Undecided → Medium
importance: Medium → Critical
Benjamin Drung (bdrung)
Changed in apport (Ubuntu):
importance: Undecided → Critical
To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.