Zero-click, wormable, cross-platform remote code execution in Microsoft Teams
github.com
github.com
If it turned out it was deemed to be a real bug, I would be refunded my $100 money. If it wasn't, well that should teach me for wasting their time.
Guess the folks running the bug program got promoted.
Unfortunately, this was the only way to report a bug at the time.
We’d end up with a surplus of hours, and leverage the threat of slashing those hours to get the execs on the support side to push for concessions from the other parts of the business. Premier was basically a revenue generator for us :)
When they introduced IE7, they broke ClickOnce launchers all around the globe due to the new download prompting. I raised a defect with my MS Partner support dude and normal MS support. All they managed was a registry fix shipped out to turn an old flag on that was removed from the UI but was still in the code inside IE. I did the diagnostic work to get that far.
After arguing for months with various support people at Microsoft I managed to get hold of people on both the IE and CLR teams and they both pointed at each other and refused to fix anything blaming the other team.
They called me every 6 months to ask me to close the ticket and I denied it because it wasn't fucking fixed. Eventually they stopped calling when Microsoft Connect was shut down. I wonder how many millions of issues they solved at that time!
Oh no wait, the issue still exists in IE11. They fixed it in old Edge.
This was a manual registry fix we had to deploy to 20,000 users at over 500 companies for 10 years.
Eventually we rewrote the software so it didn't use ClickOnce, instead passing context to the application via a shell protocol handler (much like Slack does).
Incidentally we're no longer an MS Gold partner and have no certified staff any more. This is not a coincidence. They did a shitty job and like hell we were paying any further. Amazon got our business in the end.
The issue?
You can't set window.location.href=""; to a clickonce activation link because of a race condition in the download bar in IE.
I don't even... shakes head in dismay
I put the cost of this bug for us just in the $100k range.
With the acquisition of Github and NPM, MSFT might just be the new ally of the open source movement.
"This is what we use to keep track all purchase orders! It's GRRREEEAT!"
Neat, so it's a big Excel spreadsheet we all use at the same time? I can get into—hang on, some of this stuff doesn't have a da—should I worry about—are 'Michel' and 'Michell' the same—what about 'Msh', and why are her rows purple?
"Old, all old. If someone from lab needs something, they will tell you."
But I still gotta—
"Everything in the SharePoint."
By enough marketing power you can sell almost anything.
Windows is basically a glorified games console UI for me now but thanks to my actual consoles and VM-able games I don’t really miss Windows at all.
I had not used anything by Microsoft for 10 years ago until they bought GitHub. Fuck.
This is the most apt analogy I've yet seen. I went "back" to Microsoft in the mid 2010s right around the time they started gaining a reputation for sucking less. Big mistake. But at least it gave me enough perspective to realize that the competing non-microsoft products and OSes (even the FOSS ones!) really aren't lacking as much as you'd expect.
Wow, they’re still treating .NET as a second class citizen?? That’s one of the biggest reasons I jumped off the MS boat.
At least Apple is going all-in on Swift and actually using their latest tech in core parts of their OSes (unlike MS and things like WPF etc.)
They could have an official .NET wrapper for DirectX, but then it's not "direct" :) anymore.
Of course then the next question is whether it works on Mac/Linux/... in dotnet.core
which is in conflict with their inner lockin tendency
http://bjarneh.github.io/ie/index.html
Strange bug where input fields added to the DOM containing non-ASCII characters (whether you escape them or not) trigger 'input' events. So the example page loaded in IE will already have triggered 2 'input' events, since the last 2 input-elements contain the letter 'å' (escaping it as å makes no difference).
After getting through the trouble of submitting the bug, nothing happened. About 6 months later I got an email saying the ticket was closed; as they were not able to reproduce the bug. The bug is still here today 5 years later.
Basically a total hack was required for every AJAX request that could return input fields with non-ASCII characters, as the page itself listened for input events on these elements. I.e. we basically have to wait for the AJAX-elements to be added to the DOM (removing any 'input' listener as they are), then add the same event-listeners again after every AJAX-call etc, not exactly an elegant solution...
> and get Microsoft to fix it or even pay you!
That would be nice...
The only downside is the fee is now $500, not $100
I tried to make a video demonstrating it a couple years ago, but VBox video recording mangled it due to a bug. I found it amusing that one bug preventing me from demonstrating another bug.
I tried figuring out how to report something like that to MS and gave up. It’s way too much hassle.
Even outside RCE, just consider the impact of access to SSO tokens and wormability :)
As for when it was fixed - I have no idea, as they never told me, one day it just was.
I agree the categorisation is very bad.
I hope raising this here will help you getting rewarded properly.
I disagree. If MS is going to treat major issues like this then researchers should be selling them to the highest bidder. Maybe that way they'll actually treat disclosures properly.
But what about all of the innocent people who would be harmed by such a callous approach? I'm glad some researchers have a conscience.
They should then think again about their choice of using teams. Why should Microsoft rake in money from a shabby product while volunteers have to fix their shit?
Assigning a ridiculously low score to significantly lower the bounty as a billion dollar company is disgusting.
What percentage of Teams users do you think have a choice in their use of Teams?
Necessity is the mother of invention, I have no doubt that the opportunities created by blowing away poorly-behaved incumbents will cause a healthy collections of startups who will be operating within the required framework.
I work at an university and I've been forced to install that crap on my home computer because I need to teach from home. And so do all the professors in around half the universities I know in my country.
In Australia, the emp is generally responsible for providing any necessary tools or equipment needed to do the job (contractors are another matter though)
Anyway, those of us who have research projects (as is my case) typically do have computers provided by the university at home, because research has strange schedules and working from home has always been a need (meeting with colleagues in different timezones, waiting for experiments to complete at night, rushing for deadlines, etc.).
But... it's not really practical to make room for two different desktop computers for my own use in an already spaced-starved flat, or to work in a laptop for many hours when I could do so in a desktop. So in practice, my home computer and my work computer are one and the same. And it's like that here for most, if not all, people I know.
We are a Latin country and also tend to live in small flats, maybe in other places it's different. I can imagine that if I had one of those American McMansions, it would make sense to have a home office with a sober, black work computer, a good camera setup and a green screen, and then a gaming room with a flashy gaming computer and huge speakers (near the billiards and darts room, probably :)). But that's not really how things work about here. Here, separation of home and work computers at home is almost exclusive of jobs with high security restrictions. Most people in normal jobs just don't do it because it's not practical.
Try saying that to a student who is using Teams on a school-issued laptop, by no choice of their own.
I'm not in any way defending how Microsoft handled this. Frankly, I'm ashamed of my former employer (though I worked in a completely different division). But your outrage toward the company should not extend to its unwitting users.
And thinking these huge metrics get changed by selling black hat exploits to what? Teach Microsoft a lesson? While harming an already vulnerable population (not just children are obligated to use Teams). As if the long term goal of educating "unwitting" users is advanced at all by blackhat behaviour.
Deschooling is done on discord
Let's see how Ring goes over the next few years... ;)
Personally I would prefer just having all new vulnerabilities immediately disclosed once found. No selling, but letting people decide for themselves if they want to continue to use a product after someone has found a vulnerability. I also think the incentives this creates would mean that Microsoft and similar shops would put more effort into testing their own software because they would no longer have the safety net of a grace period when someone finds a problem.
The amount of damage the NSA or some other state sponsored actor could do with this... It would be very bad to say the least. How bad depends on which state acquires it.
If a script kiddy got it they would likely do a mass randomware infection, hospitals would get hit, people would die. Millions in crypto would be lost to unencrypted wallets found on the vulnerable machines (yes people do that..), this could cause some to lose their life savings... People have commit suicide for less.
My point is its important to look past FAANG being cheap and look at 2nd and 3rd order effects from something this powerful and widespread.
That isn’t to advocate for brokering to a government, just to say that the market already exists and contains comparable exploits. It’s only a matter of time until we see the next EternalBlue to WannaCry lifecycle.
From a business perspective, the reason exploits are bad for companies is because they generate bad press, right? Well, it's not obvious to me that an exploit which was being used in the wild gets significantly worse press than one which was not. There's also the possibility the buyer will reserve an exploit for super-targeted attacks, and the public won't find out at all until year later.
Profiting from the very likely unethical use of the exploit would be unethical.
Instead this mishandling by M$ should rather cause researchers to publicly announce the vulnerabilities which would hopefully cause M$ to change their ways in future dealings.
It is ofcourse easy for me to say this, not being a researcher who lives off of the discoveries made.
My point is that in the case of M$ the defects could be publicly announced to all parties at once as a way of making M$ realize that how bad their handling is/was. In all likelyhood this shouldn't have to happen for too long before they would realize their mistake.
Many other corporations do indeed value the discoveries of researchers and do pay accordingly for being notified. Never did I suggest that this should become the industry norm (i.e not paying for private disclosures).
Now what ever your personal feelings on that idea is, it does not change the fact that selling exploits to other parties would be unethical.
Furthermore, participating in a system that promotes assumptions and flawed reading comprehension is not conductive to a good discourse. That means you.
This thing sounds like it is mostly pretty straight forward to find once you start looking - "you" being somebody experienced in this field of research, that is. At least you don't have to construct fancy weird machines (with type confusion, heap spraying and all those shenanigans). It comes down to finding something that can perform code execution in their internal API (here: "electronSafeIpc") and then finding a way to get there (here: angular escape bypass/not-properly-sanitized user provided data) and you can do both in javascript and don't have to read tons of machine code.
Given that Teams is a great target because of it's large and often corporate user base, I'd be surprised if none of the usual industrial espionage suspects (e.g. China, NSA, etc) had a look at Teams before. And I'd think the chance of them having found the same bug, or a related bug, once they looked is pretty good too.
From what I am hearing even the (US) military uses Teams sometimes... If that isn't incentive to look at this thing for "interested parties", then I don't know.
(it’s more than 30MB of compressed JS)
I have analyzed foreign code bases of similar dimensions in the past myself and found critical bugs. The size doesn't say much, it comes down to identifying the "interesting" bits (like the electronSafeRpc in this case), which can be hard and tedious, but greatly reduces the code you have to look at in detail. My assertion is that if your name is e.g. China then you will not be turned off by that.
No, I do agree - from my perspective C/C++ class bugs are more difficult. Maybe they see this as magic as well.
Still, it was painstaking work and in either case CountryX will easily surpass those difficulties.
With that much code I'd expect an AI to talk to people so I don't have to.
Most security bugs with 20/20 hindsight are "obvious" when explained well. Personally, I think that is an insulting and immature thing to say IMHO.
Lol, no.
That crufty electron apps are a security risk is not. So yes, you do need someone to run out into the streets and yell that the emperor has no clothes. Otherwise common knowledge will not be established.
Then people will move to some understuffed FOSS alternative with 5 people working part-time on it, with as severe bugs that nobody notices (remember Heartbleed and countless others?)...
Imagine thinking PHBs at most companies even care about security.
Hoping for a reward now is obviously not going to happen - the best you can hope for as a response to an act like this is legal action. In a vindictive way, you can definitely hope they will get significantly damaged by this and in that way learn their lesson, but I doubt it.
There is little value in going through the email chains to note each date:(. Final decision was made 2020-11-19
At the moment the 'has been fixed' is the only clue to this in terms of resolution, and it's tucked away; without it it looks like most of the README is attempting to capitalize on the shock/outrage factor.
Edit: Thanks, author has added some dates.
https://github.com/oskarsve/ms-teams-rce/commit/35eac619fdef...
not saying you are safe - I don’t know :)
(Yes this assumes the RCE escalates to a reasonably high privilege, but that's just a matter of chaining. You can try to go for things like sealed logs, but ultimately arbitrary code can put your machine in an arbitrary state.)
Particularly insidious for this would be the case of data theft. The RCE might load some code to upload your company secrets and keep itself strictly in RAM, and then erase itself when done. With enough blackhat craftiness you'd never be able to pinpoint the exact location of the leak.
He is a longtime friend and collaborator of Paul Graham. Graham dedicated his book ANSI Common Lisp to Morris. Graham lists Morris as one of his personal heroes, saying "he's never wrong."
to be friends with Paul Graham, i should make a worm. Got it.
First "real" worm code, multi-platform, multiple payloads, "staging", first practical buffer overflow exploit and it does credential brute-forcing.
Heck it was not until nearly a decade later that people were really doing buffer overflows, and there were a LOT of easy overflows to be found.
I'd make the case rtm didn't just "make a worm" he foreshadowed the next few decades of computer exploitation.
Took a whole bunch of research and ideas, synthesised them, built an actual working "product" a decade or two ahead of its time and released it in a transgressive way.
If you are the kind of person who can do that I'm sure lots of people would like to be friends with you.
In 1989, Morris was indicted for violating United States Code Title 18 (18 U.S.C. § 1030), the Computer Fraud and Abuse Act (CFAA).[2] He was the first person to be indicted under this act. In December 1990, he was sentenced to three years of probation, 400 hours of community service, and a fine of $10,050 plus the costs of his supervision. He appealed, but the motion was rejected the following March.[4] Morris' stated motive during the trial was "to demonstrate the inadequacies of current security measures on computer networks by exploiting the security defects [he] had discovered."[2] He completed his sentence as of 1994.
That's not to say - of course - it's not abuse-able, it just gives some context to the fact threat MS calls this "Spoofing", since presumably, your Teams contact is someone you trust. So the bad actor is "spoofing" as someone trustable within your org (or outside it). But is does prob need some social-engineering for a bad actor to truly exploit this.
But the threat is still sever since the above logic only holds up to the point-of-entry, once the worm has infected someone the people forwarding it around are truly trusted.
That sounds..interesting.
I suspect with the on-going pandemic lots of tools are getting used in interesting ways they where never really designed for just to keep things going.
The old P2P Skype had better video quality and latency, even when talking to people 4000 miles away, than every video product I’ve used in the last year. Probably not coincidentally, every video product I’ve used in the last year has been web-based. WebRTC is an enormous disappointment.
https://www.microsoft.com/en-us/microsoft-365/microsoft-team...
I can’t call this “spoofing” as there are many many things you can do wih it
> MS Teams ElectronJS security: remote-require is disabled & filtered, nodeIntegration is false, webview creation is filtered and normally removes insecure params/options. You cannot simply import child_process and execute arbitrary code or create a webview with a custom preload option.
it looks like they did everything right.
I would like this thread to go beyond outrage at how Microsoft handled this, or another excuse to bash Electron. What lessons can developers using Electron take from this? (No, "don't use Electron" doesn't count.)
I think it will take a long time before we can call ElectronJS secure. there are regular sandbox escapes and that is from what we know publicly
“Can it escape the Chromium renderer sandbox? Or is that sandbox disabled?”
the real answer is more complicated as it is not necessarily a global setting and depends on what you call a “sandbox”
But if not addressed to me, there is no need to pay, you can start here: - https://www.electronjs.org/docs/tutorial/security - https://github.com/electron/electron/security/advisories
As you can see there are plenty of considerations and pitfalls to take into account. Best option is to enable contextIsolation for everything.
Further, Electron security is closely tied to Chrome security so that is one deep rabbit hole
Or maybe let's use some research language made by Wirth, and get access to all 10 of packages and 5 devs worldwide using it :-)
https://securelist.com/zero-day-vulnerability-in-telegram/83...
and others...
https://www.notebookcheck.net/Researchers-at-Symantec-discov...
I didn't mention any programming language.
E.g. we can drop Exchange for email for a safe alternative like Sendmail.
Do they? This is just from last month: https://www.zdnet.com/article/google-patches-second-chrome-z...
>You brought open source and - totally unrelated - sendmail into it.
No, you brought the totally unrelated "Avoid Microsoft for stuff that is important, and don't install their software on your machines if you can help it." as if Microsoft is the only place to ever had a RCE...
As for bringing in unrelated stuff, no that was still within the context of Microsoft's meeting software. It was someone else that brought in the OS.
Basically you got it completely backwards. The typical native app (which is not Rust or Java but C/C++/Obj-C, etc) only keeps the unsafe part of Electron, and even drops the sandbox (whose holes can always be patched, but total absense cannot).
It is very disingenuous to say that other native apps keep the unsafe parts; there are no such parts at all.
It should be telling that Microsoft, in one of their most successful products of late, have punched an RCE sized hole in that sandbox unwittingly.
Why would it count? The situation would have more easily occured and be even worse with a C/C++ native app.
The absurdly low rating by Microsoft is horrendous.
This is beyond believe: a RCE classified as "Spoofing".
So that is basically a giant middle finger to the security researchers.
Source: https://www.microsoft.com/en-us/msrc/bounty-microsoft-cloud
To be fair the impact on the desktop app is higher since it also has access to the OS and the attacker is not stuck inside the browser sandbox. But from my understanding it still is possible to steal the SSO token. When i think about O365 setups with OneDrive for Business and Sharepoint that means the attacker would have access to all files stored there. That usually means all company related files that person has. Additionally the attacker would have access to all emails and messages of the user.
How is that not critical?
And according to the Bug Bounty side, Spoofing bugs "do not qualify for this severity category".
Isn't that precisely what spoofing is?
The thing is that according to Microsoft critical spoofing is not possible.
Not in my opinion. I’ve always thought of spoofing as a write only type thing where you can impersonate someone, but not have access to any of their existing data. Email spoofing is a good example of this.
Token theft is WAY more severe because it gives you complete access to everything. It’s total control. You can exfiltrate data and that’s what I’d consider the biggest difference, at least in my opinion.
To prevent the appeals process being abused, the appellant should have to pay for the time spent by the independent researchers verifying their complaint. For a successful appeal, the company offering the bounty should have to pay that extra cost, encouraging them not to be stingy with the awards they give out in the first place.
So there isn't much choice here
The truth is that the exploit acquisition market has many legal issues. Zerodium, who is often thought to be the leading buyer, publishes misleading guides and has had unusual timing in between the initial disclosure and hacking attempts on the researcher themselves. Other buyers have non-negotiable sale (not license!) contracts that may result in your zeroday being misused, and you may find yourself in a conspiracy. And those are the reputable and responsible buyers, there are others outside the US that are fronts for Israel/UAE/China. The market has plenty of room for correction, but there's a shortage of ethical buyers.
If you could easily sell an exploit outside of a bug bounty program for more money, you'd see more people doing it regardless of the ethics (see: the NSA doing a bulk of the hiring in infosec, noone I spoke with that applied cared about the illegal surveillance disclosures and said they chose it because they offered 100k+). So the researchers currently have no choice, and the bounty programs take advantage of that. When the pendulum swings the other direction, you'll see bounty programs becoming more fair/lucrative.
I wonder whom you'd consider an ethical buyer apart from the software maker for a closed source software since no one else can realistically patch it?
MSFT has a market cap of $1.62T. A quick Google says "The median net worth of the average U.S. household is $97,300." That works out to 0.1¢.
I think bounties are an unbalanced system; as you say, pentesters don’t get paid for their time and often don’t get paid at all, like in this case. There must be a better way, where an independent third-party can judge actual severity of the hole and sanction payments.
I work at a BigCo as a recipient of some of these XSSs and I'm awed by the amount of work that goes into them. I always try to overstate the impact to boost the reward- it's not just the bug that they found, but how much of the system they had to look at before they found this. The security folks at BigCo that I interact with are badasses, but it's just so hard to get this level of attention.
The technicality is still absurd and beyond belief, but I'd say the responsibility for that absurdity falls with company policy, not with the MS security staffer's classification.
I mean, do you look at that demo and think "yeah, that's technically just 'important' let's fix it in 2 months"?
I got one automated email from them since, that's all.
I don't expect to get paid, I was just curious to see what the "process" is, and how they treat security vulnerability reports.
The verdict: Badly.
literally unbelievable. wow.
Here https://www.microsoft.com/en-us/msrc/bounty-microsoft-cloud is a header "IN-SCOPE DOMAINS AND ENDPOINTS" with alist of domains and that is described with the following: "Only the following domains and endpoints are eligible for bug bounty awards."
I couldn't find something that would match the Teams app on general bug bounty website either (https://www.microsoft.com/de-de/msrc/bounty)
a) Paid out a bonus anyways for the finding (bug bounties do this often, certainly we did at Dropbox)
b) Made this scoping issue more explicit somewhere
They are just pushing new features in and hoping that everything will hold together until they dominate the market. I'm not saying that this is wrong, just that this is a fact for anyone that uses Teams on a daily basis.
Like, If I found a exploit for something random like skype/slack/etc.. that let you run code on any targets machine with zero interaction, there is zero chance my first stop would be the bug bounty program. For serious exploits, I believe you can get up to 2 million bucks with zerodium. Just seems like a no brainer.
Now that said, I would definitely use the bug bounty program for boring/low impact stuff like XSS and whatnot that has limited value/impact as nobody else would likely ever buy it for that much higher of a price.
If someone still wants to put in all the work, that's great, submit the vuln and reap the good karma but they shouldn't expect more, even if the org they're reporting it to promises otherwise.
One option is life changing and the “ethical” side might not pay enough to buy a gaming PC. Meanwhile the executives at the companies that claim security research needs ethics are making millions of dollars selling insecure apps. It’s like a church asking poor people to tithe IMO.
I actually think it would be better if there were no laws regarding the sale of security exploits. Everything should go onto an anonymous marketplace and the companies that have affected products should have to pair fair market value for bug discoveries.
Skimping on security and guilting researchers into being ethical is a total scam.
* The money otherwise goes to the pockets of completely-useless C-suites.
* The exploit is likely out anyway.
* Nation state actors may indeed prevent yet another 9/11 attack. In worst case they don't use it to spread ransomware.However, the idea that security researchers are guilted into "being ethical" while the (rich) executives for massive, multi-billion dollar tech companies are saving money on security, plus skimping on paying security researchers fair value when bugs are discovered, frustrates me.
It's hypocritical for big tech to expect "ethical" behavior from security researchers when it's a lot closer to "let us take advantage of you" IMO. If it becomes a debate about ethics, I think every time an exploit is sold to a company like Zerodium it's primarily the fault of the tech companies that are exploiting security researchers.
As you say, clamoring for ethical behaviour at all in this context is terrible and completely missing the point.
I blame the constant bloat of unwanted features. Each comes with it's own inherent risk of vulnerability, yet it seems like these companies can help themselves but to add "integrations" that nobody wants or asks for from a chat application.
I'm not a big fan of Google, but the video meeting software (and the little pc that you can buy with a dedicated setup including super good echo cancellation) is at the moment best of the litter.
At least that's what I can do, and I'm in multiple orgs.
That's like Apple beating you on price. Or open-source beating you on look-and-feel.
At least E2E chat is better than MS, Google or Zoom.
[1]: https://wire.com
[2]: https://matrix.org/
[Desktop Entry]
Version=1.0
Name=Microsoft Teams
Comment=Teams without Electron
GenericName=Teams
Exec=/usr/bin/chromium-browser --user-data-dir=/home/prussian/.config/ms-teams --app=https://teams.microsoft.com/_#/conversations/General
Terminal=false
X-MultipleArgs=false
Type=Application
Icon=ms-teams
Categories=Network;InstantMessaging;
Keywords=teams;messaging;internet;
X-Desktop-File-Install-Version=0.23Maybe the local version wouldn't have had that problem.
Then the clients of Microsoft will put pressure to get it paid for and fixed - because they are the ones that bear the true cost of security violations (Microsoft only has indirect costs).
The only info shown publicly should be a severity rating. If an exploit is fixed, published, or used before a company buys it, the 3rd party could publish proof of previous knowledge about the exploit.
There are a lot of good incentives in that system. The trusted third party will want to do a high quality job of verifying and categorizing exploits because overselling them will deter companies from buying and companies would be increasing their liability when they fail to buy bugs.
For example, in this case, what’s the damage? IMO you could do millions of dollars in damage. In fact, if you went hog wild exfiltrating or destroying data, I bet the industry would value the damage over $1 billion dollars when you’re being prosecuted.
I wonder what kind of legal hurdles a company would face trying to set something like that up. I think it makes a lot more sense than having companies working on the honor system because they’ve demonstrated they don’t play fair and bugs are severely undervalued.
This is a $1 million bug IMO.
I was even busier back then than now and found no application besides getting information about an already filled in password, but I was still massively underwhelmed by the response which basically boiled down to "that's funny, thanks, bye".
Last year I found a really ugly glitch were you can easily get files unencrypted past an older (but still available) version of Azure Information Protection tooling.
This time I haven't bothered to report it yet.
In the short-term, MS buying these discoveries would allow them to close vulnerabilities, ensure researchers are compensated appropriately, and establish a clear financial cost to poor security. The long-term effects would be increased security research, shorter windows of vulnerability, and more secure software.
This is a bug that should have a minimum payment of $1 million.
Immediate money saved, long term rep damage incurred.
Whatever happened to user agency?
When was it ever an expected thing with the likes of MS? I'm hard-pressed to think of much examples where they haven't pushed themselves forward using anticompetitive market-practices when it made sense for em.
Mods, can you please update the title?
So, if you use Teams for your work comms, you should know that they do not care about security or privacy.
We use Slack, but have to use Teams with one partner only for video. One day I found a message that that was weird (in the sense that it was from nobody within the organization) also marked as "(no title)". When I clicked on it gave an error "We weren't able to access your conversation".
Here's the screenshot https://imgur.com/a/C2IKK2b
Can someone please explain how the "electronSafeIpc" might be implemented? Naively this functionality seems to be the very dangerous part of this exploit, and seems to be a workaround of electron's intent to sandbox your application?
Yeah, so? He makes it sound like some novel nightmare, but that has been the case with 0-day, RCE bugs for half a century, and we have had tons of those...
I would consider this a bit more unique.
I'm assuming what happened, is that the expression filtering code stopped analyzing the string after the null byte, but other parts of the code continue past the null byte (eg, because the string indicates its length at the start of the string, which extends beyond the null byte) and the code that processes that (supposedly sanitized string) interprets beyond that null byte (to the payload).