4 ms·

Vulnerabilities are bugs a threat actor can abuse to compromise a security state of a program. Vulnerability IDs are not issued unilaterally, the vendor must ac

by _8j50 4y ago

Vulnerabilities are bugs a threat actor can abuse to compromise a security state of a program. Vulnerability IDs are not issued unilaterally, the vendor must acknowledge it as one or respond explaining why it is not. Given all that, the incentives OP talks about are rightfully aligned. People spending time finding security issues deserve recognition. Finding a lot of small vulns is as valuable as finding a few vulns, specifically because they are not just bugs but something a malicious actor can use to harm the user of the product. Many researchers get the "it's a feature not a bug" or rather it is a bug but not a vulnerability response. A software maintainer can do that with these bugs the author is talking about. Just another git issue to resolve eventually. Since these are *Dos vulns, the specific security property affected is availability. Does the reported bug allow a hostile actor to reduce the availability of the software, given users of the software have a reasonable expectation of the software being available? If so, then treat it seriously as a security vuln with the right severity, else reply stating you will fix or not fix the bug but it isn't a vulnerability. This isn't different than people opening git issues for small things. Also, since having a good reputation is a (correct) incentive, having a reputation for creating frivulous vuln reports is very bad. No one wants to be the researcher who cried wolf.

jwilk 4y ago
> the vendor must acknowledge it as one or respond explaining why it is not. Huh? So what happens when they do neither?
- _8j50 4y ago
  You release a PoC and try to get mitre or whoever maintains the system to override the vendor if it is serious enough.
  - rurban 4y ago
    And then you can argue with Mitte about their wrong CVE's. I got plenty of garbage CVE's for development versions, which were never released, marked them as invalid CVE, but they are still in the CVE database. Mitre doesn't care, the reporter doesn't care, and I don't care neither.
tptacek 4y ago
Yes. It's not different from people opening git issues for small things. It's exactly like that Digital Ocean "Hacktoberfest" thing, which incentivized people to submit bogus PRs in open source projects to get swag, forcing open source maintainers to do the labor of sifting out the (voluminous) chaff.
saagarjha 4y ago
Vulnerability IDs are not cred. Nobody who has cred thinks they are cred. They are just numbers that the database will just hand out to you if you request one; the vendor doesn't have to be involved. They are essentially isomorphic to issue numbers; some issues are really good but some are just straight up garbage. The value to having issue numbers is you get a stable identifier for a problem, not something that you can wave around thinking it has some sort of inherent reputational boost.
- _8j50 4y ago
  They are an accomplishment, you spent time and improved security on something. I am only familiar with CVEs where unless MITRE overrides, it is up to the vendor to issue a CVE. Vuln IDs to researchers are what git merged PRs are to devs. It is "creds" but the amount of reputation depends on the amount of work you did. So finding a minor DoS on a little used app isn't the samr as logstash. This is an important incentive because they could have silently sold it to zerodium or on raid/xss using an alias. Bug bounties are better imo but a vuln id is a resume item at least. Having creds and bragging about them are different things imo.
  - akerl_ 4y ago
    If the expectation is that you get "cred" based on how much work went into a merged PR or a vuln ID, it doesn't sound like vuln IDs or merged PRs are cred at all. Unless whenever I talk to somebody I'm expected to read through all their recent vulns/PRs to calculate how much cred they've earned based on the contents?
    - _8j50 4y ago
      Yeah, you should knoe based on the description. Not the amount neccesarily but the value. If you PR 3 lines that improve performance 10x or find 1 line that causes kernel rce , that's cred no?
      - akerl_ 4y ago
        The work is the “cred”. Knowing that somebody found a kernel RCE lets me know they’ve done interesting security work in the kernel space. It doesn’t matter whether or not they had a CVE assigned for that work. PRs and CVEs are mechanisms for interacting with work. They’re not status symbols, they’re not “cred”.

by _8j50 4y ago

jwilk 4y ago

> the vendor must acknowledge it as one or respond explaining why it is not. Huh? So what happens when they do neither?

_8j50 4y ago
You release a PoC and try to get mitre or whoever maintains the system to override the vendor if it is serious enough.
- rurban 4y ago
  And then you can argue with Mitte about their wrong CVE's. I got plenty of garbage CVE's for development versions, which were never released, marked them as invalid CVE, but they are still in the CVE database. Mitre doesn't care, the reporter doesn't care, and I don't care neither.

tptacek 4y ago

Yes. It's not different from people opening git issues for small things. It's exactly like that Digital Ocean "Hacktoberfest" thing, which incentivized people to submit bogus PRs in open source projects to get swag, forcing open source maintainers to do the labor of sifting out the (voluminous) chaff.

saagarjha 4y ago

Vulnerability IDs are not cred. Nobody who has cred thinks they are cred. They are just numbers that the database will just hand out to you if you request one; the vendor doesn't have to be involved. They are essentially isomorphic to issue numbers; some issues are really good but some are just straight up garbage. The value to having issue numbers is you get a stable identifier for a problem, not something that you can wave around thinking it has some sort of inherent reputational boost.

_8j50 4y ago
They are an accomplishment, you spent time and improved security on something. I am only familiar with CVEs where unless MITRE overrides, it is up to the vendor to issue a CVE. Vuln IDs to researchers are what git merged PRs are to devs. It is "creds" but the amount of reputation depends on the amount of work you did. So finding a minor DoS on a little used app isn't the samr as logstash. This is an important incentive because they could have silently sold it to zerodium or on raid/xss using an alias. Bug bounties are better imo but a vuln id is a resume item at least. Having creds and bragging about them are different things imo.
- akerl_ 4y ago
  If the expectation is that you get "cred" based on how much work went into a merged PR or a vuln ID, it doesn't sound like vuln IDs or merged PRs are cred at all. Unless whenever I talk to somebody I'm expected to read through all their recent vulns/PRs to calculate how much cred they've earned based on the contents?
  - _8j50 4y ago
    Yeah, you should knoe based on the description. Not the amount neccesarily but the value. If you PR 3 lines that improve performance 10x or find 1 line that causes kernel rce , that's cred no?
    - akerl_ 4y ago
      The work is the “cred”. Knowing that somebody found a kernel RCE lets me know they’ve done interesting security work in the kernel space. It doesn’t matter whether or not they had a CVE assigned for that work. PRs and CVEs are mechanisms for interacting with work. They’re not status symbols, they’re not “cred”.