• Edited

Memory tagging crashes Microsoft's Teams app, which consequentially means there is a memory corruption occuring, as MTE doesn't report false positives. It can be reproduced every time you try to sign in to the app with a Microsoft account, and every time you open the app when already signed in. I think it's safe to say that the bug has a high occurence ratio.

This bug is not new, and has been occurring for several months. At the time I sent Microsoft a report using the feedback feature within the app. I received no response, but I am somehow suspecting – given that Microsoft likely receives thousands of feedback submissions every day – that not all feedback submitted through the app is likely to be examined by a human, and probably even less likely to be forwarded to a software developer. After having reported it several months ago I do not know if anyone at Microsoft is aware of it.

I finally attempted to write a report to the Microsoft Security Response Center today, but their form requires detailing a proof of concept and an attack scenario which, as an amateur, I do not have and cannot draft without lying.

Has anyone else reported this to Microsoft, and if so, what response – if any – did you get from them?

I'm considering calling their customer support, explain the situation, and ask them to forward the report. Although I'm not looking forward to that conversation, as I doubt that most first-line support staff will know what I am talking about.

For anyone with a technical interest, here is the backtrace produced by MTE:

type: crash
osVersion: google/shiba/shiba:14/AP2A.240905.003/2024091900:user/release-keys
uid: 1010195 (u:r:untrusted_app:s0:c195,c256,c522,c768)
cmdline: com.microsoft.teams
processUptime: 44s

signal: 11 (SIGSEGV), code 9 (SEGV_MTESERR), faultAddr d26daaa83360
threadName: Thread-50
MTE: enabled

backtrace:
    /data/app/~~xwMqC8ghK0c-2OQLnCG14w==/com.microsoft.teams-mAA0BXYk1WFPLtr9x8UaIw==/split_config.arm64_v8a.apk!libRtmMediaManagerDyn.so (pc 13592cc)
    /data/app/~~xwMqC8ghK0c-2OQLnCG14w==/com.microsoft.teams-mAA0BXYk1WFPLtr9x8UaIw==/split_config.arm64_v8a.apk!libRtmMediaManagerDyn.so (pc dcd864)
    /data/app/~~xwMqC8ghK0c-2OQLnCG14w==/com.microsoft.teams-mAA0BXYk1WFPLtr9x8UaIw==/split_config.arm64_v8a.apk!libRtmMediaManagerDyn.so (pc e2f0a4)
    /data/app/~~xwMqC8ghK0c-2OQLnCG14w==/com.microsoft.teams-mAA0BXYk1WFPLtr9x8UaIw==/split_config.arm64_v8a.apk!libRtmMediaManagerDyn.so (pc e2efb0)
    /data/app/~~xwMqC8ghK0c-2OQLnCG14w==/com.microsoft.teams-mAA0BXYk1WFPLtr9x8UaIw==/split_config.arm64_v8a.apk!libRtmMediaManagerDyn.so (pc f48d24)
    /data/app/~~xwMqC8ghK0c-2OQLnCG14w==/com.microsoft.teams-mAA0BXYk1WFPLtr9x8UaIw==/split_config.arm64_v8a.apk!libRtmMediaManagerDyn.so (pc ff2fb4)
    /data/app/~~xwMqC8ghK0c-2OQLnCG14w==/com.microsoft.teams-mAA0BXYk1WFPLtr9x8UaIw==/split_config.arm64_v8a.apk!libRtmMediaManagerDyn.so (pc ff6700)
    /data/app/~~xwMqC8ghK0c-2OQLnCG14w==/com.microsoft.teams-mAA0BXYk1WFPLtr9x8UaIw==/split_config.arm64_v8a.apk!libRtmMediaManagerDyn.so (pc 91e8b0)
    /data/app/~~xwMqC8ghK0c-2OQLnCG14w==/com.microsoft.teams-mAA0BXYk1WFPLtr9x8UaIw==/split_config.arm64_v8a.apk!libRtmMediaManagerDyn.so (pc 91e2c4)
    /data/app/~~xwMqC8ghK0c-2OQLnCG14w==/com.microsoft.teams-mAA0BXYk1WFPLtr9x8UaIw==/split_config.arm64_v8a.apk!libRtmMediaManagerDyn.so (pc 914cf4)
    /data/app/~~xwMqC8ghK0c-2OQLnCG14w==/com.microsoft.teams-mAA0BXYk1WFPLtr9x8UaIw==/split_config.arm64_v8a.apk!libRtmMediaManagerDyn.so (pc 854024)
    /data/app/~~xwMqC8ghK0c-2OQLnCG14w==/com.microsoft.teams-mAA0BXYk1WFPLtr9x8UaIw==/split_config.arm64_v8a.apk!libRtmMediaManagerDyn.so (pc 853aa8)
    /data/app/~~xwMqC8ghK0c-2OQLnCG14w==/com.microsoft.teams-mAA0BXYk1WFPLtr9x8UaIw==/split_config.arm64_v8a.apk!libRtmMediaManagerDyn.so (pc 7fe48c)
    /data/app/~~xwMqC8ghK0c-2OQLnCG14w==/com.microsoft.teams-mAA0BXYk1WFPLtr9x8UaIw==/split_config.arm64_v8a.apk!libRtmMediaManagerDyn.so (pc 800de8)
    /data/app/~~xwMqC8ghK0c-2OQLnCG14w==/com.microsoft.teams-mAA0BXYk1WFPLtr9x8UaIw==/split_config.arm64_v8a.apk!libRtmMediaManagerDyn.so (pc 800da8)
    /data/app/~~xwMqC8ghK0c-2OQLnCG14w==/com.microsoft.teams-mAA0BXYk1WFPLtr9x8UaIw==/split_config.arm64_v8a.apk!libRtmMediaManagerDyn.so (pc 13632c4)
    /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+204, pc 7969c)
    /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+68, pc 6a064)

    fid02 Just write that it is a potentially exploitable memory safety issue detected by MTE, and submit it to their security response team like you tried. That is what I would have done anyway. Developing exploits or even confirming something isn't exploitable is very hard and time-consuming without access to the source code, so I wouldn't expect them to require to do that.

    The backtrace looks pretty useless, I would have cried if I got that one on my table. But if you say which exact version of Microsoft Teams (e.g. version so-and-so installed from Google Play) and the exact phone model and GrapheneOS version you are running, they should be able to reproduce the problem with debug symbols.

      ryrona Just write that it is a potentially exploitable memory safety issue detected by MTE, and submit it to their security response team like you tried.

      That might make sense to do, on reflection. I admit that the thought made me a bit nervous, but at worst, I guess they will just close the issue as invalid.

      I will provide them with as much detail as I can. Hopefully a developer will not shed too many tears as long as the corruption is as reproducible on a development device running stock PixelOS as it is on GrapheneOS. Disabling hardened_malloc while running the app with memory tagging on GrapheneOS also produces the crash, which I think might indicate that Scudo with MTE will pick this up as well.

      Thank you for your reply.

        fid02 If you submit and it goes nowhere, maybe see if Dan Goodin at Ars Technica or Jessica Lyons at The Register will write an article. It seems clear (example example) that Microsoft's security response can be very difficult to get fully engaged.

        • Edited

        The report I filed (designated "VULN-135913") has now received a response from MSRC. Quote of their response in its entirety:

        Subject: RE: Other - Memory corruption bug in the Teams app for Android that is revealed by MTE usage on GrapheneOS VULN-135913 CRM:0104000273

        Hello,

        Thank you for contacting the Microsoft Security Response Center (MSRC). We appreciate the time you have taken to submit this report to help protect our customers.

        To investigate your report, we require a valid proof of concept (PoC), ideally with attached images or video showing your vulnerability. Since we have not heard from you, we will need to close this report.

        If you decide to send us a new report, please include:

        • Name of the product and a description of the vulnerability

        • Detailed steps on how to consistently reproduce the issue

        • Short explanation on how an attacker could use the issue/information to exploit another user remotely

        • Proof-of-concept (PoC), such as a video recording, crash reports, screenshots, or relevant code samples

        For more information on how to submit actionable reports, please see:

        Thank you for your submission, and we look forward to seeing more reports from you in the future!

        Regards,

        MSRC

        Needless to say I feel pretty disappointed. My report was of course not one made by a security researcher, and it is likely obvious to those reading it that it's submitted by an amateur. But I do genuinely feel that I included enough information for them to be able to easily reproduce the memory safety issue – given they have the right equipment. I spent at least an hour in double-checking the instructions I provided, and in phrasing the report as clearly as I could manage within the limits of my knowledge of English.

        Microsoft can highly likely reproduce the issue with memory tagging running on the stock PixelOS as well (Arm has published an official guide on how to do this), because it was equally reproducible on GrapheneOS when Teams was being run with hardened_malloc disabled but memory tagging enabled. How that latter point works is explained here, as part of a GrapheneOS developer describing GrapheneOS' implementation of MTE: https://github.com/mullvad/mullvadvpn-app/issues/6349#issuecomment-2381665133

        Quite clearly it looks like I received a canned response from MSRC, which might not be the fault of the reviewer of the report (perhaps they are obliged to make sure that any security report contains specific points of information before they are allowed to start an investigation into it), but it still feels disappointing to me that Microsoft appears to disregard reports of memory corruption even when it's made clear to them that the bug was discovered because their app was being run with a seemingly a industry-accepted method of detecting memory vulnerabilities (MTE).

        I know this issue has been present in Teams for Android for months – while I no longer have the crash logs back then to prove it, there have at least been one report of this a few months ago by another community member (although admittedly that might not be considered sufficient evidence for any potential investigator looking into the history of when the bug was first present in the software). If I remember correctly, that user also said that they reported the issue to Microsoft through the Teams app's Feedback feature, but that they had not received a response.

        I'll consider what to do about this further, but I'm not giving up on it.

        For clarity, and so readers can make up their own minds about my report, here is a quote of the full report I submitted to MSRC (except for the backtrace that I also attached) – MSRC doesn't seem to have an export system for filed tickets, so this is copy-pasted from the report (I edited some of the formatting so that it displays better in this forum):

        Memory corruption bug in the Teams app for Android that is revealed by MTE usage on GrapheneOS

        VULN-135913


        Description
        When being run with ARMv9 hardware memory tagging on a Pixel 8 device with GrapheneOS, memory tagging detects an issue in the Teams app for Android and crashes it. This can be reproduced by signing in to the Teams app with a Microsoft account, and also by opening the app when it is already signed in to an account.

        Consequentially, and noting that memory tagging extension (MTE) does not report false positives, this means there is a potentially exploitable memory safety issue within the Teams app.

        When the below steps to reproduce are followed, the issue can be reproduced every time.

        The attached text file contains the full backtrace that is reported when the app is crashed by MTE usage on GrapheneOS. While the backtrace is potentially useless in itself, and I am not an engineer and not capable of providing you with a detailed issue log, the below steps to reproduce ought to be enough for an engineer to reproduce the issue with debug symbols.

        Kindly note that I do not have a "Proposed attack scenario" here (but the submission form obliged me to select one).


        Description
        Reproduction steps

        Device used to produce the crash: Google Pixel 8

        OS used to produce the crash: GrapheneOS version 2024091900

        1. Obtain a Google Pixel device that has hardware support for memory tagging – currently Pixel 8 and Pixel 9 series devices support this

        2. Flash GrapheneOS onto the Pixel device by following the operating system's install instructions: https://grapheneos.org/install/

        3. Boot the device and go through the GrapheneOS setup wizard (the settings of which are irrelevant here)

        4. Go to the Settings app → Security & privacy → Exploit protection → Memory tagging, and select "Enable by default"

        5. Go to App Store → Google Play services → select "Install" and approve the install prompts

        6. After the install has finished, go to Play Store, sign in with a Google account and install Microsoft Teams

        7. Open the Teams app, select "Get started", enter the email of a Microsoft account and select "Next"

        8. Complete the sign-in process

        9. Observe that memory tagging crashes the app a few seconds after the sign-in process has completed

        10. Open the app again and observe the same crash

        Note: When I submitted their form I did specify the version of the Teams app that I tested on, but that was not included in the report summary that was generated after I submitted it. I also removed my email address from the above quote (I submitted the report in my name) to avoid it getting abused by spammers that are looking at this thread.

          fid02 I massively respect the effort you put in and I'm very disappointed to see the response.

          I wonder if there is anything you could have said that would actually get them to do anything, or if you were doomed from the start? For example, I wonder if they see a 'non standard' OS, and that means they don't bother. Or is it just because not many phones even have ARMv9 yet (I know the issue is there regardless of the hardware, but I wonder how much understanding about these things the people have who look at these before passing it on to the devs).

          I wish we could know what the best way is to actually get them to do something, so there would be less wasted effort from people in your position

            roamer4223 For example, I wonder if they see a 'non standard' OS, and that means they don't bother.

            I would have liked them to comment on that if that was the case. It's true that I could've reproduced in on the stock PixelOS, send them more detailed debug logs and steps to reproduce on that OS. Pretty confident that I can follow the AOSP and Arm guides on MTE without trouble. I frankly did not think about that, but I see foresee issues if I attempt that route now: it still would not satisfy their spoken requirements of a PoC and a delineation of the exploitability of the bug, and so I have a feeling I will be wasting my time. But importantly I think that me making another report (which is bound to be similar to the first) might appear to them as an attempt at spamming an issue that was already rejected. Which is not likely to please any MSRC reviewer.

            Currently considering other avenues.