Comment 7 for bug 1830858
Revision history for this message
| kev (kbackhouse2000) wrote Re: [Bug 1830858] Re: TOCTOU vulnerability in _get_ignore_dom (report.py) | #7 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
Hi Alex,
Yes, 9 July sounds good to me. No problem if it slips to a different day
though: just let me know and I will delay my announcement too. (The 90 day
deadline is really only there for when we're dealing with an irresponsible
vendor who cannot be bothered to fix something.) I hope you don't mind that
I am planning to write a blog post about the bug (something similar to
https:/
describe the exact details of the exploit though. I usually wait around 1
month before posting the exploit code on
https:/
Thanks,
Kev
On Thu, Jun 13, 2019 at 1:41 PM Alex Murray <email address hidden>
wrote:
> Kevin, do you have a preferred disclosure date / time for this? I notice
> your policy says 90 days after initial report or 30 days after patch
> availability - I will be working on a patch for this issue and hope to
> have something together in the next week or so - and so would prefer a
> CRD in about 3-4 weeks time. How would 9th July suit you as a tentative
> date for now?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https:/
>
> Title:
> TOCTOU vulnerability in _get_ignore_dom (report.py)
>
> Status in apport package in Ubuntu:
> New
>
> Bug description:
> Dear Ubuntu Security Team,
>
> I would like to report a privilege escalation vulnerability in Apport.
> The vulnerability is a TOCTOU which enables me to trick Apport into
> reading any file on the system and including it in a crash report
> file.
>
> I have attached a proof-of-concept which triggers the vulnerability. I
> have tested it on an up-to-date Ubuntu 18.04. Run it as follows:
>
> bunzip2 PoC.tar.bz2
> tar -xf PoC.tar
> cd PoC
> make
> ./gencrashreport /etc/shadow
>
> At this point the following file has been created:
>
> /var/crash/
>
> You can use the apport-unpack tool to decompress this file. If you
> look at the contents of the CoreDump file then you will see that it
> contains the contents of /etc/shadow (or whichever other file you
> passed on the command line of gencrashreport).
>
> The bug has a couple of mitigations:
>
> 1. My PoC does not work if a file named /var/crash/.lock already
> exists and is owned by root. This file will only exist if Apport has
> previously generated a crash report. Based on an informal survey of my
> own 4 computers (yes - maybe I don't need that many), it usually does
> not exist (unless the computer is used for security research).
>
> 2. The generated crash report file,
> /var/crash/
> and by the whoopsie user. It will be uploaded to daisy.ubuntu.com if
> you create a file named /var/crash/
> but that is not a huge security concern because it wouldn't be of much
> benefit to an attacker. However, I have found some integer overflow
> vulnerabilities in whoopsie (which I will report separately). If those
> overflows can be exploited to gain code execution in whoopsie, then
> this will enable an attacker to read the contents of the crash report
> file.
>
> To improve the effectiveness of the first mitigation, I would
> recommend that you make sure that /var/crash/.lock is created (and
> owned by root) by the Ubuntu installer and/or whoopsie when it starts
> up. It does not fix the root cause though, which I will describe next.
>
> This is the source location of the TOCTOU vulnerability:
>
>
> https:/
> /bionic-
>
> Apport allows the user to place a file in their home directory named
> `~/.apport-
> intended to check that this file belongs to the correct user. But on
> line 967, the file is read again using xml.dom.
> creates a window of opportunity for an attacker to replace the file
> with a symlink. The symlink does not need to point to a valid XML
> file, because there is a try-except around the call to the parser, so
> if the file is invalid then Apport just ignores it and continues.
> However, the contents of the file still ends up in Apport's heap.
>
> Here's a summary of how the PoC works:
>
> 1. Start a /bin/sleep and kill it with a SIGSEGV.
> 2. Apport starts up to generate a crash report for /bin/sleep
> 3. Replace ~/.apport-
> moment, so that Apport loads a forbidden file into memory.
> 4. Wait until Apport drops privileges so that we can kill it with a
> SIGTRAP.
> 5. A second Apport starts up to generate a crash report for the first
> Apport.
> 6. The second Apport writes out a crash report for the first, containing
> a copy of the forbidden file in the core dump.
>
> Apport tries quite hard to not run recursively on itself, so I had to
> jump through a few hoops to make the PoC work:
>
> 1. Apport sets a lock on /var/crash/.lock, using lockf. But locks
> created by lockf are only "advisory". If I own the file, then I can
> replace it with a different file, thereby deactivating the lock. This
> is why my PoC only works if /var/crash/.lock doesn't already exist. I
> need to create it before Apport does, so that I can maintain ownership
> of it.
>
> 2. Apport has signal handlers for most of the core-generating signals,
> like SIGSEGV. But it doesn't have a handler for SIGTRAP, so that's
> what my PoC uses.
>
> 3. Apport is started with an RLIMIT_CORE value of 1, which is another
> recursion detection mechanism (see
> https:/
> But it is possible for another process to change it to zero, using
> prlimit.
>
> As I mentioned earlier, I have also found a few other vulnerabilities
> in whoopsie and Apport. I will file them as separate bugs and include
> a link to this issue.
>
> Please let me know when you have fixed the vulnerability, so that I
> can coordinate my disclosure with yours. For reference, here is a link
> to Semmle's vulnerability disclosure policy:
> https:/
>
> Thank you,
>
> Kevin Backhouse
>
> Semmle Security Research Team
>
> To manage notifications about this bug go to:
>
> https:/
>