Add Insecure Binary category

Let’s consider adding a new category for the purpose of classifying binary oriented security issues. The entry names including the category as well as the structure are up for discussion. The baseline severity ratings are in line with our current policies.

Current “Lack of Binary Hardening” can be converted into “Insecure Binary”: Insecure Binary -> Runtime Instrumentation-Based P5 Insecure Binary -> Lack of Obfuscation P5 Insecure Binary -> Lack of Jailbreak Detection P5 Insecure Binary -> Lack of Exploit Mitigations P5

“Binary Planting” is currently under “Client-Side Injection” and could potentially be relocated like so: Insecure Binary -> Binary Planting -> No Privilege Escalation P5 Insecure Binary -> Binary Planting -> Non-Default Folder Privilege Escalation P5 Insecure Binary -> Binary Planting -> Default Folder Privilege Escalation P3

Considering adding these missing entries (alternatively we could expand on existing categories like RCE or DoS):

Option 1: Insecure Binary -> Local Attack Vector -> Denial-of-Service (DoS) P5 Insecure Binary -> Local Attack Vector -> No Privilege Escalation P5 Insecure Binary -> Local Attack Vector -> Privilege Escalation P3 Insecure Binary -> Limited Attack Vector -> Denial-of-Service (DoS) P4 Insecure Binary -> Limited Attack Vector -> Remote Code Execution (RCE) P2 Insecure Binary -> Unlimited Attack Vector -> Denial-of-Service (DoS) P3 Insecure Binary -> Unlimited Attack Vector -> Remote Code Execution (RCE) P1

Option 2 (alternative structure for the above): Insecure Binary -> Local Privilege Escalation P3 Insecure Binary -> Denial-of-Service (DoS) -> Local Attack Vector P5 Insecure Binary -> Denial-of-Service (DoS) -> Limited Attack Vector P4 Insecure Binary -> Denial-of-Service (DoS) -> Unlimited Attack Vector P3 Insecure Binary -> Remote Code Execution (RCE) -> Limited Attack Vector P2 Insecure Binary -> Remote Code Execution (RCE) -> Unlimited Attack Vector P1

[truemongo]

Couple things:

1. What is a limited attack vector vs unlimited?
2. Application-level DoS (easy/critical) is currently P2. How do these new DoS ratings fit in with that?
3. For binaries, often a bug which can be used for RCE is shown in a proof-of-concept as a DoS (for example, for a stack overflow its usually enough to show a crash with PC=0x41414141 to reasonably demonstrate RCE would be achievable, without going through all the trouble of actually making a weaponized exploit). Will it be considered RCE or DoS for VRT purposes?

Finding binary bugs is considerably more work than web bugs. If they’re going to be further devalued or if the bar for proof-of-concepts is raised, I’m afraid they might stop being worth the time investment altogether.

[theGmoney]

I’m inclined to agree with Justin here - not to say we don’t want the VRT to be exhaustive as possible, but in my experience of setting up programs, it’s almost always contextual in terms of what the client wants to reward when it comes to binaries. The real problem here, not to drag this off into a very deep and dark hole, is that we need to have more p-levels or weighting based on the target type. While we normally would have a post-auth RCE as a P2, the insanity begins when that same program has a web target that also has stored xss as a P2. We simply don’t have enough options to truly convey the real relative severity of a given finding.

That said, I do want to ensure that a couple points are covered that I’ve seen when running programs that target binaries:

1. We need to ensure there’s a way to call out RCE that isn’t weaponized. This has been done on my side via offering a % of the total reward amount, downgrading to a P2, or even saying “we get it, that’s enough to prove RCE”. It’s a lot of additional work to weaponize something, despite the vulnerability being present, and it’s something that almost always comes up on these programs. It’s absolutely a P1, and I feel dirty marking something like that as a P2, but then what are we to do with a weaponized P1? Give it the same reward as the one that wasn’t weaponized? And so on. Again, this is why trying to build it into the VRT (at this time) may only hurt binary hunters. They’re rare enough as is - I prefer we not do that 😃

2. The limited vector bit is, once again, extra contextual. If it’s just “post-auth” I get that (though, what if the app is also vulnerable to CSRF, what then? Does it become a P1?). And what about a limited vector that requires one to plug in a USB stick to a device? For clients where that’s possible, that’s absolutely a P1, and I don’t want to encourage anyone to call that a P2. Once more, putting it on the same page as something like stored XSS seems impractical and even insulting (not to denigrate stored XSS, but I think we’re all aware enough to know that it shouldn’t be on the same plane/priority as code execution). Again, it unfortunately comes back to context.

3. This same concept applies to the attack scenario and threat model of any given client and what their application is used for - some don’t care about LPE, others do. For some (e.g. AV/endpoint apps), being able to DoS their service remotely is a critical issue - if you can stop their app from doing its job, that’s a big deal, and often a P1 to them, etc - but so is RCE, and so is LPE, and so on. Once more, it comes back to context - and as much as I really, really, really want to stop doing custom things on programs, I also recognize that it’s likely for the best that we not add these, at least for now, until we’re able to have a better way of distinguishing based on the target type, etc.

Happy to hear thoughts, etc. Thanks!