Date: Fri, 14 Mar 2014 09:04:16 +0300
From: Jerome Athias <athiasjerome@...il.com>
To: Michal Zalewski <lcamtuf@...edump.cx>
Cc: full-disclosure <full-disclosure@...ts.grok.org.uk>,
 "Nicholas Lemonias." <lem.nikolas@...glemail.com>
Subject: Re: Google vulnerabilities with PoC

Hi

I concur that we are mainly discussing a terminology problem.

In the context of a Penetration Test or WAPT, this is a Finding.
Reporting this finding makes sense in this context.

As a professional, you would have to explain if/how this finding is a
Weakness*, a Violation (/Regulations, Compliance, Policies or
Requirements[1])
* I would say Weakness + Exposure = Vulnerability. Vulnerability +
Exploitability (PoC) = Confirmed Vulnerability that needs Business
Impact and Risk Analysis

So I would probably have reported this Finding as a Weakness (and not
Vulnerability. See: OWASP, WASC-TC, CWE), explaining that it is not
Best Practice (your OWASP link and Cheat Sheets), and even if
mitigative/compensative security controls (Ref Orange Book), security
controls like white listing (or at least black listing. see also
ESAPI) should be 1) part of the [1]security requirements of a proper
SDLC (Build security in) as per Defense-in-Depth security principles
and 2) used and implemented correctly.
NB: A simple Threat Model (i.e. list of CAPEC) would be a solid
support to your report
This would help to evaluate/measure the risk (e.g. CVSS).
Helping the decision/actions around this risk

PS: interestingly, in this case, I'm not sure that the Separation of
Duties security principle was applied correctly by Google in term of
Risk Acceptance (which could be another Finding)

So in few words, be careful with the terminology. (don't always say
vulnerability like the media say hacker, see RFC1392) Use a CWE ID
(e.g. CWE-434, CWE-183, CWE-184 vs. CWE-616)

My 2 bitcents
Sorry if it is not edible :)
Happy Hacking!

/JA
https://github.com/athiasjerome/XORCISM

2014-03-14 7:19 GMT+03:00 Michal Zalewski <lcamtuf@...edump.cx>:
> Nicholas,
>
> I remember my early years in the infosec community - and sadly, so do
> some of the more seasoned readers of this list :-) Back then, I
> thought that the only thing that mattered is the ability to find bugs.
> But after some 18 years in the industry, I now know that there's an
> even more important and elusive skill.
>
> That skill boils down to having a robust mental model of what
> constitutes a security flaw - and being able to explain your thinking
> to others in a precise and internally consistent manner that convinces
> others to act. We need this because the security of a system can't be
> usefully described using abstract terms: even the academic definitions
> ultimately boil down to saying "the system is secure if it doesn't do
> the things we *really* don't want it to do".
>
> In this spirit, the term "vulnerability" is generally reserved for
> behaviors that meet all of the following criteria:
>
> 1) The behavior must have negative consequences for at least one of
> the legitimate stakeholders (users, service owners, etc),
>
> 2) The consequences must be widely seen as unexpected and unacceptable,
>
> 3) There must be a realistic chance of such a negative outcome,
>
> 4) The behavior must introduce substantial new risks that go beyond
> the previously accepted trade-offs.
>
> If we don't have that, we usually don't have a case, no matter how
> clever the bug is.
>
> Cheers (and happy hunting!),
> /mz
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists