Hacker News Reader

Comment by mwcampbell | Hacker News Reader

I'm confused about the scope of the RCE. Can it escape the Chromium renderer sandbox? Or is that sandbox disabled? Based on the following:

> 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.)

View on HN

The article explains the technical details of the render process escape. Contrary to all the current replies to this comment, it does not look to me that this is using a generalized Electron escape; rather, it is using specific main/render IPC calls which Teams has implemented unsafely as the escape mechanism. Perhaps folks are confusing this with an electron sandbox issue because Teams happens to have called the variable containing their IPC APIs "electronSafeIpc".

What lessons can we learn from banging our heads on the wall? (No, "don't bang your head on the wall" doesn't count.)

Avoid Microsoft for stuff that is important, and don't install their software on your machines if you can help it.

Starting by anything running on top of Electron.

Especially if said machines are actually built by Microsoft.

In which case they may be nice enough to block some of their software for you https://www.techrepublic.com/article/microsoft-blocks-major-...

Yeah, because other companies or FOSS have a better track record.

E.g. we can drop Exchange for email for a safe alternative like Sendmail.

Yes, Google has a better track record. You brought open source and - totally unrelated - sendmail into it.

>Yes, Google has a better track record.

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...

That's Chrome, not meet.

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.

Or wuftpd. I once accidentally dropped my keyboard, and it turned out that the keypresses that generated were a remote root exploit for wuftpd.

What are the chances of that happening, that's pretty neat!

With wuftpd? P(x)=1

Eh, at first I thought so too, but then it turned out my neighbours nan once accidentally hacked the US Navy that way, so after that I didn't feel all that special any more :(

Hehe, that's hilarious.

Maybe I’m in a filter bubble, but I’ve never heard of anyone else assigning such low priority to exploits like this.

Reminds me of the old joke: VirusScanner: We found a virus on your machine called Windows. You you like to remove it?

Bang our heads on the wall at the appropriate angle. It's only our fault if we get hurt, we must learn to properly use the tools we have

I bang my head against a wall everyday for a living.

Don't use Teams app, but connect through browser instead... that is if there is no other way to avoid Teams, because you're company has already migrated from Slack.

Correct me if I’m wrong but the XSS stuff still works then. Having all your Office 365 data stolen may be a problem.

Yeah, because remote code exploits are particularly an issue with Electron, as opposed an order of magnitude less likely to happen with it compared to native code.

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).

Complexity leads to RCEs like the one in TFA, not “unsafe” languages.

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.

>No, "don't use Electron" doesn't count

Why would it count? The situation would have more easily occured and be even worse with a C/C++ native app.

would it though - in a C++ app there'd be way less places where people could send you arbitrary code to run over the network ; and if you use any kind of high-level network library you'd be well pressed to have any kind of buffer overflow, as all the buffer handling is done in already-vetted libs, such as Qt, Boost, cpp-rest-sdk, etc

It's in the IPC invocation, so for this app in particular, it'd be in the exact same place.

I have a hard time seeing how. It seems to work by having some JS code to create a webview getting executed. In a pure C++ app there would be no place that would even be able to interpret that js, or any other "script language" in that pipeline.

there are different levels of security for ElectronJS, some, like in this case are not enough.

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

The OP is asking for more detail than “not enough”, though:

“Can it escape the Chromium renderer sandbox? Or is that sandbox disabled?”

to simplify - no it’s not enabled

the real answer is more complicated as it is not necessarily a global setting and depends on what you call a “sandbox”

Thanks. I'd pay (moderately) for the more complicated answer. An ebook on Electron security might be a good idea.

I'm not an expert on Electron security!

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

Best Electron security is not using it in first place.

Rather just keep it in the browser? ;-P

This is safer to a significant degree.

Yeah, let's stick with raw C/C++, that would be much safer...

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 :-)

Telegram Desktop is a cross-platform C++ app. What similar remote code execution exploit has existed in the wild for it?

FYI it's not just PL that factors into security. The engineers, for example.

The exact same kind of RCE?

https://securelist.com/zero-day-vulnerability-in-telegram/83...

and others...

https://www.notebookcheck.net/Researchers-at-Symantec-discov...

One of them requires the user to click run on a file, much like running an EXE. The other, simply saves potentially malicious data to external storage which would then have to be run by a separate malicious third-party app. This are far from RCE exploits that execute immediately without poor user decision making, and Rust is not impervious to security exploits similar to these.

C'mon. Just because there is one C++ app without remote exploits doesn't mean all C++ apps are immune.

For starters, leave it on the browser.

I didn't mention any programming language.

They could ummm.... build a cross-platform UI framework that rivals Electron without the security and memory bloat issues? I think that's the plan with MAUI.

Reply on news.ycombinator.com