WASC's definition of "weakness": "The underlying vulnerability within
the application that is exploited." It seem weakness is equal to
vulnerability, and WASC's Glossary
(http://projects.webappsec.org/w/page/13246967/The%20Web%20Security%20
Glossary) doesn't include the terms.

However, according to "http://cwe.mitre.org/about/faq.html#A.1",
"Software  weaknesses are errors that can lead to software
vulnerabilities. A software  vulnerability is a mistake in software
that can be  directly used by a hacker to gain access to a system or
network.", so they are different concepts.

The situation is confused. so what's the differences between weakness
and vulnerability? thanks!

-Matt

A vulnerability is a flaw that prevents legit access or grants unauthorized
access. A weakness is a flaw that reduces the effectiveness of an
interactivity control. A concern is is a flaw that reduces the effectiveness
of a process control. All vulns are weaknesses or concerns, but not all
weaknesses or concerns are vulnerabilities. See OSSTMM for more on the topic
under the section on limitations.

Sent from my Verizon Wireless 4GLTE Phone

-----Original message-----
From: matthew chao mathewchao@gmail.com
To: websecurity@lists.webappsec.org
Sent: Sun, Nov 6, 2011 19:23:43 GMT+00:00
Subject: [WEB SECURITY] What's the differences between weakness and
vulnerability?

WASC's definition of "weakness": "The underlying vulnerability within
the application that is exploited." It seem weakness is equal to
vulnerability, and WASC's Glossary
(http://projects.webappsec.org/w/page/13246967/The%20Web%20Security%20
Glossary) doesn't include the terms.

However, according to "http://cwe.mitre.org/about/faq.html#A.1",
"Software  weaknesses are errors that can lead to software
vulnerabilities. A software  vulnerability is a mistake in software
that can be  directly used by a hacker to gain access to a system or
network.", so they are different concepts.

The situation is confused. so what's the differences between weakness
and vulnerability? thanks!

-Matt

The Web Security Mailing List

WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss

Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates

websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

Per  http://en.wikipedia.org/wiki/Vulnerability_(computing)

In computer security, a vulnerability is a weakness which allows an attacker
to reduce a system's information assurance.

Regards,
Celestain.

-----Original Message-----
From: websecurity-bounces@lists.webappsec.org
[mailto:websecurity-bounces@lists.webappsec.org] On Behalf Of matthew chao
Sent: Sunday, November 06, 2011 2:35 AM
To: websecurity@lists.webappsec.org
Subject: [WEB SECURITY] What's the differences between weakness and
vulnerability?

WASC's definition of "weakness": "The underlying vulnerability within the
application that is exploited." It seem weakness is equal to vulnerability,
and WASC's Glossary
(http://projects.webappsec.org/w/page/13246967/The%20Web%20Security%20
Glossary) doesn't include the terms.

However, according to "http://cwe.mitre.org/about/faq.html#A.1",
"Software  weaknesses are errors that can lead to software vulnerabilities.
A software  vulnerability is a mistake in software that can be  directly
used by a hacker to gain access to a system or network.", so they are
different concepts.

The situation is confused. so what's the differences between weakness and
vulnerability? thanks!

-Matt

The Web Security Mailing List

WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss

Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates

websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

While I basically agree with Michal's sentiment, I'll use a code
example to highlight the difference between a "weakness" and a
"vulnerability" - at least, as we use those terms in CWE and CVE
respectively.  (Both terms are used in a lot of different ways, and
it's even been a struggle to come up with good definitions in CVE and
CWE).

This may also help people understand why code analysis tools can
generate many "false positives."

I am going to avoid precise terms here, and just speak informally.

A software weakness, as we use in CWE, is a property of
software/systems that, under the right conditions, may permit
unintended or unauthorized behavior.  For example, if a routine does
not perform input validation, then it might permit unintended or
unauthorized behavior.  (In the CWE world, we generally think of a CWE
entry as a weakness "type.")

A software vulnerability, as we use in CWE, is a collection of one or
more weaknesses that contain the right conditions to permit
unauthorized parties to force the software to perform unintended
behavior.

So - a weakness identifies patterns or behaviors that could
contribute to unintended behavior.  When the weakness can be used by
an attacker against the software or another user, then that's a
vulnerability.

Apologies to the web crowd for the C code example below:

char *copyUserName (int nameSize, char *name) {
int bufferSize;
char *dupeName;

/* CWE-20: Improper input validation /
bufferSize = (nameSize * sizeof(char));
/ Potential integer overflow (CWE-190) and incorrect buffer
size calculation (CWE-131). /
dupeName = malloc(bufferSize);
/ CWE-252: Unchecked Return Value /
strcpy(dupeName, name);
/ Potential heap-based buffer overflow (CWE-122), NULL
pointer dereference (CWE-476) */
return(dupeName);
}

This routine could be described as containing several weaknesses.  No
input validation (CWE-20) is performed on the nameSize argument.  If
nameSize contains unexpected values, then an integer overflow
(CWE-190) might occur.  Sometimes an integer overflow is a
valid/correct calculation (e.g. if you're using it for some kind of
randomness).  At a higher level of abstraction, in this particular
piece of code, the integer overflow could generate an inconsistent
value, which means there could be an incorrect buffer size calculation
(CWE-131).  Then a malloc is performed, but its return value isn't
checked (CWE-252).

At this stage, the code has not caused any real trouble.  But, further
down this weakness chain, we could potentially run into a heap-based
buffer overflow (CWE-122) or NULL pointer dereference (CWE-476).

There are probably other weaknesses here too, but anyway...

Now, when does this pose a vulnerability?  It all depends on context:
where is this code used, and how?

If there's only one call in the program that's like this:

copyUserName(6, "Steve");

then this is correct code, and thus, there is no vulnerability (unless
you're some kind of smartass who invents new vulnerability classes or
looks for vulnerabilities in secure coding examples for fun).

But if you have this code:

copyUserName(atoi(argv[1]), argv[2]);

Then it's receiving input from the command line.

If this program isn't running with special privileges, then in many
contexts, this wouldn't be a vulnerability - if a user can directly
invoke the program, then they already have "privileges" to crash it,
or if they leverage the buffer overflow to execute code, then
(usually) they already have privileges to execute their own programs
with their own code, so they don't gain anything they don't already
have.  Many people might consider it a bug, though.

But, what if this program is (1) called from a URI handler, (2) called
from a restricted shell, (3) separately called from a privileged
program such as sudo without sufficient restrictions on arguments, or
(4) assigned special privileges by an administrator?  Well, in those
contexts, the user isn't expected to be able to execute any code they
want (or maybe not even cause a crash), so then this could be a
vulnerability.

Suppose you have this pseudo-code:

Packet = ReadNetworkPacket(20);
Size = ParseInteger(Packet);
Name = ParseString(Packet);
copyUserName(Size, Name);

That code is reading stuff directly off the network.  There's fairly
universal agreement that this context poses some kind of
vulnerability, unless you're a vendor who assumes that your products
are only deployed on closed networks with fully trusted individuals
But I digress.

In the security industry, there are broader usages of the
"vulnerability" term than just what we cover in CVE.  For example,
some people view "the use of a memory-unsafe language" as a
vulnerability.  Sometimes, a vulnerability that's covered by CVE is
called a "weakness" by the original vendor or researcher.  There's no
way that we will be able to get everyone to agree to use the terms in
the same way.  See other posts in this thread.  The "vulnerability
research" specialty is in its infancy, only decades old as opposed to
centuries like medicine and sciences like chemistry (the original
inspiration for CVE by the way).  I'm inclined to believe that it's
going to take a long time before there's anything close to agreement
on various terms, and then, only within certain narrow specialties.

A current-day example is demonstrated when people talk about problems
with "false positives" in automated code scanning tools.  Generally,
these tools operate to find and report individual WEAKNESSES within
the code, but users often only want to see VULNERABILITIES.  If a
weakness doesn't contribute to a vulnerability, then a user may treat
the tool's finding as a false positive.  Some tools may try to omit
findings that don't seem to have an attack vector (and thus unlikely
to be vulnerabilities), but this logic isn't always perfect, and you
can have false negatives or false positives.  How does a tool know
whether an argument from the command line is under an attacker's
control or not?  That's entirely dependent on context, which tools
can't do - at least, not out of the box.

I hope this explains some of the thinking behind "vulnerability" and
"weakness," at least as we use those terms in CVE and CWE.

• Steve