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.

              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.

                      5 months later

                      Did anything ever happen with this? Did they ever fix it? Or did they contact you again?

                      fid02 After having reported it several months ago I do not know if anyone at Microsoft is aware of it

                      fid02 At the time I sent Microsoft a report using the feedback feature within the app. I received no response

                      I know this is an old thread, which I wouldn't find if someone else did not resurface it, but one think I can tell you about such bugs is, that unless you're a corp customer reporting this through 'official' channels to which non customers don't have access, don't expect anything to happen. Even if you are a customer its often hard to get enough attention unless someone on their end is getting tagged to help you.

                      Unless you'd find an exploitable bug and wrote a full report with poc as you said, then it gets reviewed. But for a bug like this, unless everyone gets it, they won't care. Its simply too much money with zero roi.

                          You can bugs uncovered by MTE as a security vulnerability since MTE doesn't have false positives and is finding actual memory corruption bugs with a good chance of them being exploitation. It's their job to figure out if it is or isn't and they should take any MTE report seriously. Doesn't mean they will, but reporting it as a security vulnerability is how to deal with it if another approach isn't working. In some cases it might be caused by something like the OS GPU driver but that's generally obvious in the traceback. This one is definitely a Microsoft Teams bug.

                          If you have a way to reproduce the bug, give them that. Some MTE bugs will also happen with the much less capable implementation on the stock Pixel OS so you could try enabling it via developer options + turning on using MTE via ADB if you have a spare device to see if you can reproduce it in the stock OS. If you can make a report they can reproduce on the stock OS without bringing up GrapheneOS, that's perfect. but not all bugs uncovered by MTE on GrapheneOS will be possible to detect with it on the stock OS since it doesn't use it for as many size classes or quarantine as much. The main security advantages of our approach shouldn't really be very relevant though as long as they try it a few times if it doesn't crash the first time.

                            I also encountered this handling issue with the Amazon Shopping app. I've reported it to them through every channel possible, including through the form on HackerOne which doesn't require registration and even has an option to report generic memory corruption bugs without an exploit PoC, and there's no response and no fix for it roughly a year since I first tried to report it to them.

                            I've also encountered another app that's actually based on their cross-platform library embedded within it that contains a memory corruption bug found by memory tagging, also reproducible without the hardened memory allocator. I told them that it's potentially exploitable. The developer downplayed the severity of this, says it isn't prioritized, and continues to ignore it for roughly a year now.

                            GrapheneOS Some developers don't care about security, but I imagine that all developers care about bugs. I don't know any reason why a developer would ever want a memory corruption bug in their app.

                                Watermelon Developers do not decide on themselves what is going to be prioritized in a company such as amazon or Microsoft. Unless a bug is widespread, there's no management involved so it lingers. You could try to make it publicly known, maybe then it would get some attention. Otherwise? Nah.

                                And its not even that the developers don't care about security, many do. But the management is the problem.

                                  Yes, there is an update: I have spent several hours on this bug in total, testing new versions and writing (I think, quite clear and detailed) reports to MSRC and a journalist whose work I respect, but I no longer have the energy to pursue this.

                                  GrapheneOS Doesn't mean they will, but reporting it as a security vulnerability is how to deal with it if another approach isn't working.

                                  Indeed, I used MSRC's researcher portal: https://msrc.microsoft.com/report/vulnerability/new

                                  GrapheneOS If you have a way to reproduce the bug, give them that. Some MTE bugs will also happen with the much less capable implementation on the stock Pixel OS so you could try enabling it via developer options + turning on using MTE via ADB if you have a spare device to see if you can reproduce it in the stock OS.

                                  Indeed, it does. It's so easy to reproduce it's almost funny. I probably have over a dozen tombstones in total, from different app versions over the past months. From stock OS, yes.

                                  1.
                                  adb shell
                                  shiba:/ $ setprop arm64.memtag.bootctl memtag
                                  shiba:/ $ setprop persist.arm64.memtag.app_default sync
                                  shiba:/ $ reboot

                                  1. Install Microsoft Teams from Play Store and open the app
                                  2. Sign in with a Microsoft account
                                  3. When the app crashes, run adb bugreport or use the Bug report option in Developer options
                                  4. Close the app and open it again to trigger the bug anew

                                  It occurs every time you open the app when it's signed in to an account. It's not a one-time thing that only occurs during sign-in.

                                  If you can make a report they can reproduce on the stock OS without bringing up GrapheneOS, that's perfect.

                                  I did do exactly that a few weeks ago. I can even send you a transcript of the vuln issues if you're curious. Actually it was suggested by an MSRC employee that I created a new vuln issue about it. In my humble opinion, I gave a report with a clear description and clear steps to reproduce, including a full tombstone. I had experimented with MTE on stock OS so I knew how to use it. MSRC again responded by informing me that without an attack scenario, they won't look into it. After some back and forth, they closed the new report and marked it a non-case.

                                  They also informed me that instead, I could report the bug through either the Windows or the web app, which of course is nonsense. I already reported it through the Android app probably a year ago. No support employee is going to understand what I'm talking about.

                                  I approached a journalist with the story a couple of weeks ago, but they don't have the bandwidth for this at the moment. Currently, neither have I. :-)

                                        I feel like they will only really start caring about this, when MTE is more widely used, and more people are affected.
                                        Like Amazon shopping and Kindle both have also MTE issues, and i cant find it but the amazon shopping one is soon a year old already. (If this is not a different one) Or Tiktok also has one.

                                        (I assume it is not related to the graphic driver like mentioned before, but i didnt really check that)

                                          dhhdjbd Their users are already impacted by their apps having memory corruption bugs including the potential for attackers to exploit them. Each issue reported by MTE is a real invalid memory access.

                                            @fid02 story time

                                            I reported an Android vulnerability, my first, around the same time you did. I first reported it to GrapheneOS on github but GOS told me to report to Google. I had no idea what I was doing. They clearly expect anyone who reports security issues to essentially be a bug bounty hunter or security researcher. They don't have a separate process for "normies". I was somewhat motivated by their "up to $100,000" reward. The vulnerability I reported was of S2 severity (severe). Turns out it was a duplicate. I wondered whether they just said that to avoid having to pay me. I'll never know.

                                            I recently read this blog post about a guy who accidentally found a lock screen bypass on Android and got $70k for it. The vulnerability I reported was also a lock screen bypass but it was only brief. The process reminded me of my own. Someone posted the link on this forum, so you might have seen it already: https://bugs.xdavidhu.me/google/2022/11/10/accidental-70k-google-pixel-lock-screen-bypass/

                                            I don't really understand how to identify whether or not something is a bug or security vulnerability. When an app stops working / keeps crashing, I'll occasionally look at the log but I don't really know what to look for, and even if I found something, I probably wouldn't know what I was looking at. I seem to recall seeing memory out of bounds or buffer overflow errors, these are terms I've heard of before but don't know how severe they are for the specific crashes I experienced.

                                              gk7ncklxlts99w1 I don't expect to receive any kind of bounty from them, even if the report was acknowledged. All I've really done is to enable a toggle in GrapheneOS and forward an MTE crash report with a description and steps to reproduce and tried to get some attention towards it.

                                              It's possible that someone running Teams with MTE in SYNC mode on stock PixelOS would've discovered it by either deliberately testing the app or accidentally, but I think there's a much higher chance of GrapheneOS users discovering it because it's so easy to enable MTE for user-installed apps. On stock PixelOS it's not even enough to enable MTE in Developer options (I don't even know what that option does; perhaps it enables MTE in ASYNC mode?), you need to use adb to run specific commands.

                                              If someone with security expertise takes an interest in this and discovers a vuln, I expect them to receive the bounty.

                                              gk7ncklxlts99w1 When an app stops working / keeps crashing, I'll occasionally look at the log but I don't really know what to look for, and even if I found something, I probably wouldn't know what I was looking at.

                                              On GrapheneOS you just look for a notification from memory tagging that it discovered an issue. In the stacktrace, you'll see "code 9 (SEGV_MTESERR)".

                                              Here's some background material on MTE:

                                              Documentation from Arm: https://developer.arm.com/documentation/108035/0100/Introduction-to-the-Memory-Tagging-Extension?lang=en

                                              Android documentation:
                                              https://developer.android.com/ndk/guides/arm-mte
                                              https://source.android.com/docs/security/test/memory-safety/arm-mte
                                              https://android.googlesource.com/platform/bionic/+/main/docs/mte.md
                                              https://source.android.com/docs/security/test/memory-safety/mte-configuration
                                              https://source.android.com/docs/security/test/memory-safety/mte-reports

                                              Some Project Zero posts about MTE:
                                              https://googleprojectzero.blogspot.com/2023/11/first-handset-with-mte-on-market.html
                                              https://googleprojectzero.blogspot.com/2023/08/mte-as-implemented-part-1.html
                                              https://googleprojectzero.blogspot.com/2023/08/mte-as-implemented-part-2-mitigation.html
                                              https://googleprojectzero.blogspot.com/2023/08/mte-as-implemented-part-3-kernel.html

                                                  goslife if you have a twitter account you could tweet it at David Weston from Microsoft.

                                                  I don't have a Twitter account. But this sounds like something most people could do without overstretching themselves. Not just me.