Live data from Hacker News

Remote Code Execution in Slack desktop apps

hackerone.com

171–180 of 201 posts

Re: Remote Code Execution in Slack desktop apps

#171
post #79

Earlier quoted context omitted.

> If you haven't had food for a few days everything is indeed about money I doubt anybody capable of finding an exploit like this is in that situation

Most software is made entirely free with no source of income. The job market for software is terrible, and those people work entirely seperate jobs from it. Many program on a very minimum life expenditure.

"Most software is made entirely free with no source of income"

No. Most software that is actually used, is not made 'for free'.

Re: Remote Code Execution in Slack desktop apps

#173
post #39

I wrote that exploit & report. Just some thoughts on comments here. Sure the bounty is low, but ultimately it's their money and their decision. They will deal with the 'consequences' of others skipping their program and some public shaming. I find everyone talking about black markets etc. kind of ridiculous. Really? You would sell something like this, so someone can be spied upon or maybe literally chopped to pieces?…

> I find everyone talking about black markets etc. kind of ridiculous. Really? You would sell something like this, so someone can be spied upon or maybe literally chopped to pieces? I work with some security engineers who in previous jobs used to write exploits for the highest bidder. Their stuff ended up being used for exactly this. One of them even told me quite proudly, you know that exploit that was in the news,…

> being used for exactly this

That refers to "spied upon" or sth like "chopped to pieces"?

In which continent?

Re: Remote Code Execution in Slack desktop apps

#174

Earlier quoted context omitted.

This might be unpopular, but if you don't feel like the compensation adequately reflects your effort, then you're free to do whatever you think is fair. It's your work. Slack isn't entitled to that work. Ideally, you'd check beforehand what a bug bounty program usually pays out and then decide whether to work on some other company's product that pays better. But you're always going to have people who are interested i…

> Slack isn't entitled to that work. Sure, but that isn’t the user’s fault, and they’re the ones who are going to get attacked. I don’t disagree with your other points but I don’t think selling an exploit on the black market is the right solution. Perhaps the best compromise, as I think about it, is to just make the exploit public with no prior warning to the vendor. That’s not great for users either, but at least th…

> Sure, but that isn’t the user’s fault, and they’re the ones who are going to get attacked.

This is true, but the responsibility to protect these users is ultimately on Slack, not the researcher. If Slack's bounties are nowhere near competitive with black market prices, they are failing to protect their users and should be called out on it.

Re: Remote Code Execution in Slack desktop apps

#175
post #130
post #73

Earlier quoted context omitted.

> You would sell something like this, so someone can be spied upon or maybe literally chopped to pieces? Jesus, not everything is about money If you haven't had food for a few days everything is indeed about money. Either you reward someone properly for the work that they can do or they'll find someone else who does. I doubt most people get fuzzy warm feelings helping a big US corporation that's too greedy to actuall…

Technically true, but kind of ridiculous. How many people can't get food, but have a computer, electricity, internet connection, a reasonably quiet place to work, deep knowledge of web technology, and enough free time and mental energy to try to build exploits of computer software against an uncertain and distant bug bounty payout? If you're really desperate for food, you should be looking for a salaried position or…

Lots. Many more than you’d expect. To believe otherwise is privilege.

It took many years to understand this.

Re: Remote Code Execution in Slack desktop apps

#176

Earlier quoted context omitted.

XSS isn't ordinarily RCE, and XSS is generally much more common than the attacks that do reliably give RCE. It's notable that un-hardened Electron elevates XSS to RCE, because it means there are a lot more opportunities for RCE. That's the subtext of the comment you're replying to.

Yes it is? XSS lets you execute javascript code remotely; that's literally a subset of RCE. Are you talking about virtual machine escapes (running native machine code)?

No, that is not remotely what practitioners mean by RCE.

Re: Remote Code Execution in Slack desktop apps

#177

Earlier quoted context omitted.

Yes it is? XSS lets you execute javascript code remotely; that's literally a subset of RCE. Are you talking about virtual machine escapes (running native machine code)?

No, that is not remotely what practitioners mean by RCE.

"Remote Code Execution" means the attacker can Execute Code Remotely, right? I guess you could classify the virtual machine as a (virtually) separate machine from the physical one, so that it's not a RCE on the machine you actually want to attack, but it's clearly executing code on some machine that the remote attacker isn't supposed to be able to execute code on.

Re: Remote Code Execution in Slack desktop apps

#178
post #126

Earlier quoted context omitted.

> The bug value also shows how much Slack here values their security, and makes me wary of them if I was in the place to be a customer of theirs. Most directly it shows how they value a bug bounty program. There are companies that spend hundreds of millions of dollars per year and have thousands of people in their infosec program that don’t have bug bounty programs. You can extrapolate that to how they value security…

>There are companies that spend hundreds of millions of dollars per year and have thousands of people in their infosec program that don’t have bug bounty programs. Such as?

Large banks in the US.

Re: Remote Code Execution in Slack desktop apps

#179

Earlier quoted context omitted.

No, that is not remotely what practitioners mean by RCE.

"Remote Code Execution" means the attacker can Execute Code Remotely, right? I guess you could classify the virtual machine as a (virtually) separate machine from the physical one, so that it's not a RCE on the machine you actually want to attack, but it's clearly executing code on some machine that the remote attacker isn't supposed to be able to execute code on.

No. RCE is a term of art. It implies arbitrary native code execution.

Re: Remote Code Execution in Slack desktop apps

#180

Earlier quoted context omitted.

"Remote Code Execution" means the attacker can Execute Code Remotely, right? I guess you could classify the virtual machine as a (virtually) separate machine from the physical one, so that it's not a RCE on the machine you actually want to attack, but it's clearly executing code on some machine that the remote attacker isn't supposed to be able to execute code on.

No. RCE is a term of art. It implies arbitrary native code execution.

> It implies arbitrary []native[] code execution.

This is simply not true in a plurality of cases (eg, it implies that applications running under qemu are incapable of having RCE vulnerabilities) and frankly sounds like a distinction that was made up to avoid admitting that script tags are RCE bugs in web browsers.

Post reply on HN