Live data from Hacker News

Remote Code Execution in Slack desktop apps

hackerone.com

161–170 of 201 posts

Re: Remote Code Execution in Slack desktop apps

#161

Earlier quoted context omitted.

Sure, some of it is open to interpretation, but I disagree with it not being taken seriously. This is the basis for CVEs, most bounty tables, and most audit reports (that I've seen).

I'm a practitioner, I've managed bug bounties for several companies, and spent 15 of the last 20 years doing assessment work almost exclusively, and nobody takes CVSS seriously. It doesn't say anything to point out that some people structure "bounty tables" based on CVSS, because, as I said, it's a ouija board; the actual rules for what bugs are worth are still ad hoc , they're just used to determine the CVSS instead…

CVSS being used as a basis for bounty payments is certainly evidence that it is taken seriously. Of course there are details that have to be factored in after that calculation, since CVSS is simplified for general usage.

I'm not aware of any programs on HackerOne that don't follow this practice, so it's not "super uncommon".

Re: Remote Code Execution in Slack desktop apps

#162

Earlier quoted context omitted.

CVSS is a ouija board and you can make it say whatever you want, which is why very few practitioners take it seriously.

Sure, some of it is open to interpretation, but I disagree with it not being taken seriously. This is the basis for CVEs, most bounty tables, and most audit reports (that I've seen).

I've been in security for a while and once received a report of a CVSS score that was egregiously high at Critical.

I modified the assumptions that were made by the reporter and came out with Low.

This is one example of why this is a nonsense metric.

Re: Remote Code Execution in Slack desktop apps

#163
post #162

Earlier quoted context omitted.

Sure, some of it is open to interpretation, but I disagree with it not being taken seriously. This is the basis for CVEs, most bounty tables, and most audit reports (that I've seen).

I've been in security for a while and once received a report of a CVSS score that was egregiously high at Critical. I modified the assumptions that were made by the reporter and came out with Low. This is one example of why this is a nonsense metric.

Any metric is nonsense if used improperly.

Re: Remote Code Execution in Slack desktop apps

#164
post #162

Earlier quoted context omitted.

I've been in security for a while and once received a report of a CVSS score that was egregiously high at Critical. I modified the assumptions that were made by the reporter and came out with Low. This is one example of why this is a nonsense metric.

Any metric is nonsense if used improperly.

I am arguing that there is no proper way to use this.

Re: Remote Code Execution in Slack desktop apps

#165

Earlier quoted context omitted.

Dropbox and co pay $10,000 for the same exploit.

Then you should sell it to Dropbox, because $10,000 is extremely high for an XSS vulnerability.

I do not have the market rates for vulnerabilities, but I do know some pen testing companies charge $10,000 for a few days of work that may not return any concrete bugs.

Compared with hiring a pen testing team, offering high bounties seems like a bargain as you get actual exploits that would impact the company.

Re: Remote Code Execution in Slack desktop apps

#166

Earlier quoted context omitted.

I realise it’s a medium on that scale and I cannot argue otherwise. But I think how private that data is to the end user should also be taken into account. It’s a medium for technical risk (relative to server remote exec), but it should be seen as a high priority for the company and rewarded as such. If an end user were to ask that company “why did you leak all my private data” their response would be “your data is w…

The authenticated one-click social engineering aspect of this significantly lowers exploit probability and overall risk.

This is true, but this attack could work in an Iframe in the background without that click. An attacker could buy a popular blog on the note taking app, and run the Iframe in the background collecting data for years. The bug was at least 5 years old.

Re: Remote Code Execution in Slack desktop apps

#167

Earlier quoted context omitted.

Then you should sell it to Dropbox, because $10,000 is extremely high for an XSS vulnerability.

I do not have the market rates for vulnerabilities, but I do know some pen testing companies charge $10,000 for a few days of work that may not return any concrete bugs. Compared with hiring a pen testing team, offering high bounties seems like a bargain as you get actual exploits that would impact the company.

Yes, that is the premise behind bug bounties. If you're a vulnerability researcher with a track record, you will probably make better money and certainly more consistent money as a pentester. Many pentesters just do both.

I have, uh, some experience with the rates here.

Re: Remote Code Execution in Slack desktop apps

#168
post #50

Earlier quoted context omitted.

Unfortunately, we live in a world governed by money as a motivator. While you might not be in it for the money, many people are, to a certain degree (you know, to make a living and to be able to afford a decent life). If companies are unwilling to pay anything remotely close to what researchers' time is worth, then they shouldn't wonder when people prefer to sell the exploits that they find to those who do value thei…

I agree with you. It's super low, but I and others will just ignore it in the future and ultimately they lose. However, bug bounties are not a job. Nobody is forced or obligated to do anything. I'm giving them 'a pass' in the future :) It's great people are discussing this and surely it will improve things for future researchers. I consider bug bounties like competitions. The 'prize money' is defined beforehand. You…

In my country there is a sort of obligation to get 10% of value in case you find something valuable but is more applied to found money. Many times people just return what they have found without taking any reward. This could be extrapolated to bug bounties as well. How much would Slack or its clients potentially loose, if this bug was exploited? I think that everybody could agree on some sum, lets say 200k USD. In that case 20k should be paid.

Another approach is to take invoice for last security audit and simply pay the whole amount of that invoice to the researcher. If none was ever done (good God!), just some usual quote for pen testing the targeted application could be applied.

HackerOne could also enforce minimum payouts per exploit category.

Re: Remote Code Execution in Slack desktop apps

#169
post #34

Earlier quoted context omitted.

You can’t just substitute different transgressions and use the same reasoning. There are plenty of crimes where it’s reasonable to be more lenient to a first-time offender, but murder is not one of them.

There are no crimes where it is reasonable to be lenient to a first-time offender. It's a matter of intent: Lenience is given to accidents (usually still only the first occurrence), which may or may not have caused a crime. What they did was to silence a security researcher, produce marketing material with falsehoods, and as a result ultimately damage their customers by allowing a security vulnerability to remain pre…

Technically there are plenty of crimes where it is not only reasonable but morally obligatory to be lenient to a first-time offender. Like copyright infringement or sodomy. But in those cases it's also obligatory to be lenient to a second-/third-/etc-time offender, because the law criminalizing them is unjust. Similarly, I strongly suspect that the law unjustly fails to criminalize Slack's negligent disregard for their users security in this case.

I agree that, crime or not, it was intentionally committed, and does not warrant lenience, though.

Re: Remote Code Execution in Slack desktop apps

#170
post #12

Earlier quoted context omitted.

> since Electron brings XSS to the desktop, it is a hackers paradise. Just curious - what makes XSS on the desktop different from other kinds of RCE vulnerability?

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)?
Post reply on HN