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.

                                        Teams is an universally hated application. I have never met anyone who actually likes it, everyone who uses it is because it was mandated by their employer. It has so many usability and quality problems that it is almost like a joke. With that in mind, I'm not surprised at the slightest that a report like this is ignored when much more serious issues (in the sense of being user-facing) are ignored.

                                        I presume that the Teams development team/process at Microsoft is not in a healthy state at all, if it ever was.