
From Markdown to remote code execution in Atom - xh3n1
https://statuscode.ch/2017/11/from-markdown-to-rce-in-atom/
======
mattbierner
As soon as I saw the title I suspected the exploit was probably markdown
related, as I had fixed pretty much the exact same issues in VS Code. Two
things to keep in mind when developing electron apps:

\- The potential impact of an XSS or other security exploits is much higher.
You can limit the impact of most of these with additional layers of security,
such as running untrusted html in isolated environments with node integration
disabled. However, also remember that...

\- Many security features are opt-in. Content security policies (CSP) are a
good example. Pages without a CPS default to allowing anything, which sort of
makes sense in browser world for backwards compatibility, but is not a good
idea for desktop apps.

~~~
scoot
> _As soon as I saw the title I suspected the exploit was probably markdown
> related_

The title literally says "from Markdown to remote code execution" what else
were you expecting?!

~~~
ovis
The title was changed after the original post.

~~~
mattbierner
Yes, thank you. This was originally posted as: "An XSS in Atom Editor That
Turned into RCE". XSS + Electron instantly made me think markdown

------
cabalamat
I've an idea. Let's write GUI apps using GUI libraries, like everyone used to,
instead of writing them for a web browser.

Not only will this be more secure, it'll also be 10s or 100s of times more
performant.

~~~
jeswin
I understand the sentiment and dislike laggy UIs, but browsers have been
running millions of apps securely on billions of computers for ages. No
browser exploit has led to worldwide data compromise. In fact, being able to
run untrusted code at this scale represents the pinnacle of security
engineering feats.

There have also been plenty of exploits in applications written entirely with
native code.

~~~
blub
Browsers can barely open a simple web page without getting owned. They're
probably the number one infection vector nowadays...

This has lead to some pretty bad hacks. I'm not sure what more you could want
really, a vulnerability where people can be punched in the face over the
internet?

~~~
username223
> a vulnerability where people can be punched in the face over the internet?

That sounds like a mild form of swatting, which is already a thing.

------
hoodoof
I wish there was a dead-simple, you-cannot-get-it-wrong, step-by-step,
nothing-left-out, no-knowledge-assumed, all-in-one-document, not-spread-out-
over-various-pages, tutorial/checklist on how to ensure your Electron app is
as secure as possible.

It shits me that it is a research task with all the attendant uncertainty
about whether or not I did in fact make it secure.

I do appreciate that security is complex and even such a document would not
guarantee security, or that you had not somehow created your own security
hole, but I just want to do the very best possible effort at security and
currently that is too hard with Electron.

UPDATE: this post has led me to attempt to redesign my application to not use
Electron. I just can't afford some misconfiguration or coding error leading to
user machines being cracked.

~~~
zghst
Security is never easy. It is always a battle. Maybe AI is the answer

~~~
beisner
AI is decidedly not the answer. Formal verification is the answer, and tooling
around it.

~~~
tdb7893
My impression is that making everything formally verified is a lot of work and
it would be very hard to make formally verified code as easy to write as non-
verified code.

~~~
sewer_bird
The central dilemma is that there are myriad ways to do it wrong for every one
way to do it correctly.

------
jsnar
Electron makes things worse: it is not secure. Electron has many security
vulnerabilities. The latest version is still based on old Chromium (58 & 59)
so it inherits many of the security vulnerabilities published in Chromium 60,
61 and 62

~~~
megous
As long as you don't load untrusted code or content... I guess many of the
issues are moot if untrusted code can't get access to javascript and is only
exposed to HTML parser (DOMParser).

The way I'm using electron for my pet projects is only passing untrusted HTML
to DOMParser and then sanitizing with strict whitelist of attributes/html
elements. Only then will any HTML code get interpreted by the browser engine.

Feels somewhat safe, but I haven't read the bug list. :)

Image format decoding and HTTP/TLS/request processing layer bugs may be other
source of issues in any case. But hopefully that runs in some restricted
environment.

~~~
sigzero
"As long as you don't load untrusted code or content..."

Because end users are soooo good at that?

~~~
AgentME
They're referring to the application developer.

If the developer uses Electron only to open the application's own html files
and doesn't render user-provided HTML anywhere, then there won't be any XSS
vulnerabilities.

------
eptcyka
Whilst it's very hard to write a secure C application because writing C is
hard, it seems it's very hard to write a secure application in javascript
because javascript is too easy. Maybe we should stop blaming language
complexity and start blaming the complexity (or lack thereof) of the designs
that fail us?

~~~
pjc50
Neither of those is about "hard" versus "easy". C pre-dates a modern
understanding of security boundaries and tries a little bit too hard to be
"close to the machine" (so long as the machine looks a lot like a PDP-11).
Javascript-the-language is not the problem, but _having the whole browser
infrastructure present in order to render a document_ is the problem here in
Electron.

The challenge in language design is to erect the right number of boundaries
and barriers, in the right places. Too many, and you get people complaining
that they can't write Rust because of the borrow checker. Too few, and you get
people vaporising multi-million-dollar Etherum contracts by mistake.

~~~
eptcyka
I don't think you understand. I am not blaming languages, or indeed making a
statement about how hard or simple they are to use. I'm just trying to point
out that application design is hard - and in fact I do consider the fact that
a text editor has pulled in the whole browser infrastructure to render a
document a design error.

------
zx2c4
This is why I don't run any Electron apps on my computers at all, ever.

That means I'm stuck with the web browser version of Slack, Skype, Signal
(going away), and so forth, which is a shame. But it's better than the
security nightmare that is Electron.

I wish developers wanting to make cross platform GUI applications would look
instead at Qt. It's extremely easy to use, really fast, and generates great
GUIs. It's been around for ages and continually sees updates. Usually people
who see the Qt light are pretty satisfied. It can also be used from a wide
variety of languages, in case you're not into writing C++.

I sort of suspect that Electron's popularity is due to it being accessible to
the hordes of JavaScript developers who otherwise wouldn't have had any clue
how to make desktop/native applications. However, do I really want to be
running unsandboxed xss==>rce code written by clueless devs? No, no I do not.
So, in the end, refusing to run Electron apps turns out to be a somewhat
reasonable security posture.

~~~
scrollaway
Look, I love Qt; I worked with it a ton, I contributed back to it, I even
still work on LXQt sometimes.

But the rise of web apps, and Electron along with it, have turned the Linux
desktop from a "you need to dual boot or use wine" machine into one where all
my tools and apps are Linux compatible and have feature parity with Windows
and macOS.

I also wish Qt would see more use, I also wish more people would write desktop
apps using desktop frameworks when it's meant to be a desktop app, and I
really wish people would start writing tiny CLI apps in nodejs and include 70
dependencies. But truth be told, I'm happy to live in a world where I can do
100% of what I do on Linux without feeling like a second class citizen.

I think the "Web on desktop" paradigm is the future, even if it's currently a
bleak one. Ten years ago, it was becoming pretty clear that Javascript would
be the future, and at the time that was a bleak prospect -- but tooling
improved and today, things like Typescript, React, the plethora of incredible
development tooling and excellent cross-platform compatibility have turned
what used to be bleak into an excellent environment.

There's a lot of improvements that can happen with Electron, if rather than
fight it we actually embrace it. Running 10 different web browser engines for
10 different apps may be silly, but what if Electron was global to the desktop
instead of included in every fat app?

You'll note that Google has been dipping their toe in that water for years
with ChromeOS; Mozilla also tried their version of it with FirefoxOS, which
failed for a plethora of reasons that don't undermine the concept at its core.

Basically, JS on the desktop is in the same uncanny valley as it was on the
web a decade ago. It's ugly, slow, overwhelming and changing too fast. But
there's an end goal there, which doesn't have to suck.

~~~
chrisweekly
> “really wish people would start writing tiny CLI apps in nodejs and include
> 70 dependencies”

did you mean /s/start/stop/ above?

~~~
scrollaway
Uh, yeah. People have definitely started.

------
brepl
> Bringing web security issues to desktop apps

Wonderful :)

------
scotty79
Why does anyone think that blacklisting things they know about makes html more
secure?

I guess whitelisting only the things they are absolutely sure are harmless is
way more work.

~~~
barkingcat
Even whitelisting is dangerous for web/html. Given any tag, there's probably a
large number of things you can do with them that boggles the mind as in "whoa
I didn't know you could do that..." including things that are not in the w3c
specs but are coded into the interpreters.

Basically the experience of a web developer every day, no matter how
experienced you are.

~~~
scotty79
I you whitelist tags and then whitelist attributes and then whitelist
attribute values and for attributes that have values with its own structure,
like style whitelist allowed things in that structure, you should be fine.

But it's hard to restrain yourself from doing: allow any (possibly except
some) at any stage of whitelisting.

Even to a point of not allowing string of any characters as attribute value.

------
seanwilson
Is there a good reason to allow unsafe eval in the Content Security Policy?

~~~
mattbierner
Not really, except when you are first adding a CSP to an older site that
relies on eval (probably in a some crazy old jquery library). The name
'unsafe-eval' and the fact that 'unsafe-eval' has to be explicitly enabled are
strong hints that you should move off of it as soon as possible

------
thesmallestcat
This is horrifying. And they only applied a bandage as a fix.

------
saagarjha
Unrelated: the article kept sending blurry low-res images and downloading the
full version as I scrolled past them. I found this very annoying since I have
a poor internet connection and had to wait for each image to load. I’d much
rather prefer a slightly longer initial page load than waiting for each image.

------
chatmasta
The author suggests a malicious attacker might typosquat common packages and
embed the exploit in a readme.

But if the user is already downloading your package, why bother with an
exploit? You’ve got all the permissions allocated to packages (which I imagine
are most permissions). You can just execute the malicious code directly from
the package.

Edit: nvm

~~~
detaro
from the article:

> _So a malicious attacker would just have to register a bunch of malicious
> packages for every letter or offer a few packages with similar names to
> existing ones. As soon as someone clicked on the name to see the full entry
> (not installing it!), the malicious code would already be executed._

~~~
chatmasta
My bad, missed that part. Yikes.

