14 ms·
From Markdown to remote code execution in Atom
- brepl 9y ago> Bringing web security issues to desktop apps Wonderful :)
- jsnar 9y agoElectron 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
- jsnar 9y agoSee here for the security issues published in Chrome stable releases in those versions: https://chromereleases.googleblog.com/2017/07/stable-channel-update-for-desktop.html https://chromereleases.googleblog.com/2017/07/stable-channel... https://chromereleases.googleblog.com/2017/09/stable-channel-update-for-desktop.html https://chromereleases.googleblog.com/2017/09/stable-channel... https://chromereleases.googleblog.com/2017/10/stable-channel-update-for-desktop.html https://chromereleases.googleblog.com/2017/10/stable-channel...
- megous 9y agoAs 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 9y ago"As long as you don't load untrusted code or content..." Because end users are soooo good at that?
- AgentME 9y agoThey'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.
- seanwilson 9y agoIs there a good reason to allow unsafe eval in the Content Security Policy?
- mattbierner 9y agoNot 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
- scotty79 9y agoWhy 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 9y agoEven 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 9y agoI 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.
- catnaroek 9y agoHow about “not using a bazooka to kill a mosquito”? There's no reason why a text editor needs a frigging browser engine as a core component.
- eptcyka 9y agoWhilst 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 9y agoNeither 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 9y agoI 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.
- wvenable 9y ago> having the whole browser infrastructure present in order to render a document This is disingenuous; the whole browser infrastructure is present to run an application. This shouldn't be surprising because that is exactly what a browser is: an application execution environment.
- syrrim 9y agoC isn't hard. C is easy, in fact. This is the main impetus behind its popularity: people liked it, in part because it was easy. Security is hard in c, in part because c tries to make things easy for the developer at the detriment if security. Javascript is in the exact same posistion. Why is javascript popular? Because its easy. Why is javascript easy? Because none of its features are focused on security.
- cabalamat 9y agoI'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 9y agoI 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.
- eptcyka 9y agoWhilst there haven't been that many data breaches, I'd argue that's because the browser is operating at the edges of your architecture, not in the centre, where the data lies. However, to say that browsers are secure is pure nonsense. Browsers get exploited all of the time, I'd argue that this is not as big of an issue as it could be because browser vendors respond to new vulnerabilities very quickly. WebGL, for instance, is still a massive mess in terms of security.
- empath75 9y agoI guess you don’t remember internet explorer.
- blub 9y agoBrowsers 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 9y ago> 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.
- zx2c4 9y agoThis 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.
- gcb0 9y agowelcome to the history loop! it is a very known fact for all unix grey beards (insert more inclusive analogy if you can think any) that containers and fat binaries lead to way more code rot than anything else. and consequently more bugs and security bugs. I blame this fad coming back on apple. linux and even Microsoft were happy with shared libraries, until osx adopted the bait and switch tactics of Microsoft and got the whole industry by playing the "but I am unix" tune. and with it the whole (webdev) industry was back to fat binaries. then people started to realize they dont have to find out the source code to patch that old application just because they have to patch openssl or something. they can just release an entire image! and they have no idea they will make it even harder to have a legacy build when that other openssl bug hit. but for now, everyone can be agile and live serverless! and users now have to update the OS, the few shared libraries, and every and each one of their fat binary applications and container images! good luck with that
- styfle 9y agoAs a developer, I find containers much easier to update, especially in scenarios where you need to update to a new patch with a fix for OpenSSL. The solution, is to bump the version in the dockerfile, rebuild, and deploy. This is especially useful when you want to test the latest version before deployment or when you need to deploy to many machines. Conversely, using a VM and trying to patch it means the updates are not part of the normal development process so you would need to spin up a new VM to test before patching production VMs. Now sysadmins and developers think differently so this is purely subjective (note I’m a dev), so surely there are merits to the other approach, but I prefer the container approach.
- mattbierner 9y agoAs 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 9y ago> 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 9y agoThe title was changed after the original post.
- mattbierner 9y agoYes, thank you. This was originally posted as: "An XSS in Atom Editor That Turned into RCE". XSS + Electron instantly made me think markdown
- 11235813213455 9y agoWell it's using marked https://github.com/atom/atom/blob/master/package.json#L50 https://github.com/atom/atom/blob/master/package.json#L50, no wonder it's vulnerable. Why not just updating to markdown-it?
- draw_down 9y agoIt’s disappointing that Electron is the only runtime with security vulnerabilities.
- thesmallestcat 9y agoThis is horrifying. And they only applied a bandage as a fix.
- chatmasta 9y agoThe 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 9y agofrom 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 9y agoMy bad, missed that part. Yikes.
- Chaturbate 9y agohttp://chaturbate.com.br http://chaturbate.com.br
- hoodoof 9y agoI 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 9y agoSecurity is never easy. It is always a battle. Maybe AI is the answer
- beisner 9y agoAI is decidedly not the answer. Formal verification is the answer, and tooling around it.
- tdb7893 9y agoMy 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 9y agoThe central dilemma is that there are myriad ways to do it wrong for every one way to do it correctly.
- saagarjha 9y agoUnrelated: 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.