From Markdown to remote code execution in Atom • Hacker News Board

Re: From Markdown to remote code execution in Atom

#41

Post by Klathmon » Thu, Nov 23, 2017, 5:19 PM UTC

pjmlp wrote: post #36

pjc50 wrote: post #26

Earlier quoted context omitted.

So you're saying software OEMs need to pick one of Windows or MacOS and not support any other platforms?

No, you create a proper abstraction layer that maps to native plaform elements. For example, IFileDialog maps to a Cocoa dialog on macOS, file picker on UWP, open dialog on Win32, document selector on Android and so on. Yes, it takes some initial effort, but it only needs to be done once.

That's easy to say for a file picker on desktop OSs, but what happens when you need to layout a page on all 3 desktop plus Android and iOS?

Do you need to design 5 designs that include 5 different buttons, 5 ways of navigating through the app, 5 different sets of icons, 5 different styles of animation, etc...

Hell even with a file picker, what happens when you use it on a platform that doesn't really have the concept of "files" like iOS or up to recently Android (at least in what is normally exposed to the user)

Roll in various versions of each OS and you are up to needing 10+ ways of doing most things. How are you supposed to create anything even remotely complicated?

Re: From Markdown to remote code execution in Atom

#42

Post by tcd » Thu, Nov 23, 2017, 5:24 PM UTC

DandyDev wrote: post #40

qudat wrote: post #16

Earlier quoted context omitted.

All your positives about Qt can be applied to electron but even better. From a business point of view electron is a winner. For example at our company we have built a desktop app, web app, salesforce plugin, chrome extension, outlook plugin, cli app, and are working on mobile apps all using one JavaScript codebase. It’s a business and developers dream. There really is no competition and any claim to the contrary woul…

It's not a developers dream if that developer loathes Javascript, like I do. Even Typescript just feels like lipstick on a pig.

Sure, you can hate a programming language. It changes absolutely nothing, except your potential revenue streams.

It's like saying "I loathe Linux!!" and knowing nothing about it; sure, but in this industry, you're going to have a tough time :)

Re: From Markdown to remote code execution in Atom

#43

Post by chatmasta » Thu, Nov 23, 2017, 5:43 PM UTC

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

Re: From Markdown to remote code execution in Atom

#44

Post by AluminiumPoint » Thu, Nov 23, 2017, 5:48 PM UTC

gcb0 wrote: post #29

styfle wrote: post #22

Earlier quoted context omitted.

As 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…

when it works for containers, it would have worked just the same for shared lib, but with one less step. containers: update the lib, rebuild. sane software: update the lib. now, to the complicated case which containers claim to solve, when the lib update breaks compatibility. container: update lib, application dont compile, leave like that because we think we are not vulnerable anyways. sane sotware: update lib, appl…

Sort of. You are missing the ephemeral of containers, which has a net security advantage. Ephemeral containers mean that its harder for an attacker to obtain persistence, and easier to cycle out and swap bad containers than it is to patching servers.

I would argue that container orchestration infrastructure is objectively more secure than plain old servers; I get where you are coming from, but this tech is solving real problems, the cool aid is good

Re: From Markdown to remote code execution in Atom

#45

Post by detaro » Thu, Nov 23, 2017, 5:49 PM UTC

chatmasta wrote: post #43

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

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.

Re: From Markdown to remote code execution in Atom

#46

Post by sigzero » Thu, Nov 23, 2017, 5:55 PM UTC

megous wrote: post #11

jsnar wrote: post #3

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

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

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

Because end users are soooo good at that?

Re: From Markdown to remote code execution in Atom

#47

Post by pfooti » Thu, Nov 23, 2017, 6:12 PM UTC

Klathmon wrote: post #41

pjmlp wrote: post #36

Earlier quoted context omitted.

No, you create a proper abstraction layer that maps to native plaform elements. For example, IFileDialog maps to a Cocoa dialog on macOS, file picker on UWP, open dialog on Win32, document selector on Android and so on. Yes, it takes some initial effort, but it only needs to be done once.

That's easy to say for a file picker on desktop OSs, but what happens when you need to layout a page on all 3 desktop plus Android and iOS? Do you need to design 5 designs that include 5 different buttons, 5 ways of navigating through the app, 5 different sets of icons, 5 different styles of animation, etc... Hell even with a file picker, what happens when you use it on a platform that doesn't really have the concept…

I agree; if you build a system that completely covers specifying layouts for all widget needs and a DSL that handles wiring views into models, for all operating systems and device formfactors, you will have invented HTML, CSS, and JavaScript, with the DOM api and a browser as the default interface.

Re: From Markdown to remote code execution in Atom

#48

Post by chatmasta » Thu, Nov 23, 2017, 6:20 PM UTC

detaro wrote: post #45

chatmasta wrote: post #43

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

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.

My bad, missed that part. Yikes.

Re: From Markdown to remote code execution in Atom

#49

Post by NMDaniel » Thu, Nov 23, 2017, 6:25 PM UTC

DandyDev wrote: post #40

qudat wrote: post #16

Earlier quoted context omitted.

All your positives about Qt can be applied to electron but even better. From a business point of view electron is a winner. For example at our company we have built a desktop app, web app, salesforce plugin, chrome extension, outlook plugin, cli app, and are working on mobile apps all using one JavaScript codebase. It’s a business and developers dream. There really is no competition and any claim to the contrary woul…

It's not a developers dream if that developer loathes Javascript, like I do. Even Typescript just feels like lipstick on a pig.

And many developers loathe C++. Why should I have to use such a low level and antiquated language for developing a GUI?

Nowadays you don't even have to use JS/TS, there are many languages that target JS and have decent bindings to its ecosystem, such as Scala, Purescript, Clojure. This doesn't seem to be the case with Qt which lacks decent bindings to languages other than Python.

Re: From Markdown to remote code execution in Atom

#50

Post by empath75 » Thu, Nov 23, 2017, 6:31 PM UTC

jeswin wrote: post #12

cabalamat wrote: post #8

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.

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.

I guess you don’t remember internet explorer.