Use after free

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Use after free

Steve Grubb
Hello,

I am wondering how to classify another kind of problem. When a program closes
a file descriptor and then later uses it again, the syscall will get either a
EBADFD errno. Or if a new descriptor was opened there is a high likelihood
that the same descriptor number would be used and therefore perform operations
on the wrong file.

There is CWE-416 "use after free" which clearly seems to be memory based as in
the heap allocator related.  There is also CWE-825 "expired pointer
dereference", which would seem to me to also be memory related. But I don't
see a good fit as to what this error should be classified as. How should it be
treated?

Thanks,
-Steve
Reply | Threaded
Open this post in threaded view
|

Re: Use after free

Martin Sebor
On 12/18/2012 03:26 PM, Steve Grubb wrote:

> Hello,
>
> I am wondering how to classify another kind of problem. When a program closes
> a file descriptor and then later uses it again, the syscall will get either a
> EBADFD errno. Or if a new descriptor was opened there is a high likelihood
> that the same descriptor number would be used and therefore perform operations
> on the wrong file.
>
> There is CWE-416 "use after free" which clearly seems to be memory based as in
> the heap allocator related.  There is also CWE-825 "expired pointer
> dereference", which would seem to me to also be memory related. But I don't
> see a good fit as to what this error should be classified as. How should it be
> treated?

I think the general problem that fits best here is CWE-672: Operation
on a Resource after Expiration or Release.

Martin

>
> Thanks,
> -Steve
Reply | Threaded
Open this post in threaded view
|

Re: Use after free

Steven M. Christey-3
In reply to this post by Steve Grubb
On Tue, 18 Dec 2012, Steve Grubb wrote:

> I am wondering how to classify another kind of problem. When a program
> closes a file descriptor and then later uses it again, the syscall will
> get either a EBADFD errno. Or if a new descriptor was opened there is a
> high likelihood that the same descriptor number would be used and
> therefore perform operations on the wrong file.
>
> There is CWE-416 "use after free" which clearly seems to be memory based
> as in the heap allocator related.  There is also CWE-825 "expired
> pointer dereference", which would seem to me to also be memory related.
> But I don't see a good fit as to what this error should be classified
> as. How should it be treated?

If you look at the parents of CWE-825, CWE-672 (Operation on a Resource
after Expiration or Release) seems like a good fit.  (In general, if
you're thinking "resource management," it might be useful to start from
CWE-664 and navigate to its children and descendants).

Some people may be wondering why we don't have a file-descriptor
equivalent for CWE-416.  In general, while CWE has many lower-level
entries for memory, it does not have as much detailed coverage for other
resources.

There is a specific reason for this.  The lower-level CWEs reflect the
focus of vulnerability research on memory safety issues, going back many
years.  Once we developed the resource-lifecycle model that formed
CWE-672, CWE-664, and other high-level entries, it became possible to
create lower-level CWE entries for other types of resources, by creating
Base-level or Variant-level weaknesses under these higher-level classes.
However, there are many types of resources - and many types of things that
can go wrong with the resource lifecycle - so if we tried to cover all
possible combinations, this would create a large number of new entries
that would make CWE more difficult to use.  So, in this area of CWE - and
other areas that have not been well-researched historically - we have been
conservative and avoided creating many new CWEs.

This is one of several ways that CWE's numeric ID scheme is insufficient,
and modeling weaknesses using "parameterization" (combinations of multiple
attributes) might be much more useful to the community in the long term.


Steve Christey
CWE Technical Lead
Reply | Threaded
Open this post in threaded view
|

RE: Use after free

Wheeler, David A
Steve Christey said:
> Some people may be wondering why we don't have a file-descriptor equivalent for CWE-416.  In general, while CWE has many lower-level entries for memory, it does not have as much detailed coverage for other resources.

And that's a good thing.  In theory, any defect could lead to a security vulnerability, but some are far more likely and common than others (once you start looking at real-world vulnerabilities).  As  http://cwe.mitre.org/about/faq.html#A.1 says, CWE is a list of "common software weaknesses that can occur in software's architecture, design, code or implementation that can lead to exploitable security vulnerabilities"... not a list of all possible software defects.  If it tried to list everything, it would lose its value.

That said, if it *is* common and not in the CWE set, it should be added.  And if a few higher-level constructs can be added that make it easier to understand and use (e.g., because it is a better organization) -- such a high-level "use after release of any resource" - then great!

I think key needs currently for the CWEs is to define them more clearly, more rigorously, and to better organize them in some way (e.g., identify patterns or parameterization).   Add important items where appropriate, absolutely, I'd expect to see a trickle over time.  But please don't make CWE a laundry list of all possible defects.

--- David A. Wheeler
Reply | Threaded
Open this post in threaded view
|

Re: Use after free

David Remahl
On Dec 20, 2012, at 2:14 PM, "Wheeler, David A" <[hidden email]> wrote:

> Steve Christey said:
>> Some people may be wondering why we don't have a file-descriptor equivalent for CWE-416.  In general, while CWE has many lower-level entries for memory, it does not have as much detailed coverage for other resources.
>
> And that's a good thing.  In theory, any defect could lead to a security vulnerability, but some are far more likely and common than others (once you start looking at real-world vulnerabilities).  As  http://cwe.mitre.org/about/faq.html#A.1 says, CWE is a list of "common software weaknesses that can occur in software's architecture, design, code or implementation that can lead to exploitable security vulnerabilities"... not a list of all possible software defects.  If it tried to list everything, it would lose its value.

I always interpreted it as “common” in the sense of “shared”, not “prevalent”, as in Common Vulnerability Enumeration.

> That said, if it *is* common and not in the CWE set, it should be added.  And if a few higher-level constructs can be added that make it easier to understand and use (e.g., because it is a better organization) -- such a high-level "use after release of any resource" - then great!
>
> I think key needs currently for the CWEs is to define them more clearly, more rigorously, and to better organize them in some way (e.g., identify patterns or parameterization).   Add important items where appropriate, absolutely, I'd expect to see a trickle over time.  But please don't make CWE a laundry list of all possible defects.

I don’t believe that there is an inherent conflict between being very granular and specific (“leak of mach port receive right”), highlighting the most important/prevalent (“heap memory leak”), and cataloging higher orders of organization (“unreleased resource”). I do feel CWEs potential is as a laundry list of all possible defects, ways that they have led to exposures in the past, and other defects like them. All-too-often, in examining real-world flaws, I have to drop to something generalized, e.g. “Exposure of resource to wrong sphere”, when something much more specific would have been better.

Limiting CWE to only covering “the most important” reminds me of deletionists on Wikipedia trying to determine where to set the bar for notablility. Wikipedia already has millions of pages; I don’t see how it could be worse with billions, provided I can still find the most important articles through some higher level of organization (e.g. article links, categories, etc).

> --- David A. Wheeler

Short sidenote: Right after spotting this mail in my inbox, I mysteriously decided to run sloccount on my code for the first time in ten years, spotted your name in the credits, and then went back to replying to this mail. Thanks for sloccount, I always found it a fun tool but never (consciously) knew the name of the person who wrote it :-).

/ Regards, David
Reply | Threaded
Open this post in threaded view
|

Re: Use after free

rcvalle
Hi,

To be straight to the point, it all began with an internal discussion
where I suggested that some events of the DELETE_ARRAY checker from
Coverity is best mapped to CWE-404 instead of CWE-459. The following is
an excerpt from Coverity documentation for this checker:

1.3.3. DELETE_ARRAY

The DELETE_ARRAY checker finds many instances of using delete instead of
delete[] to delete an array.

Both new and delete have two variants: one for a single structure and
one for arrays. On an allocated array, calling delete instead of
delete[] will work most of the time. However, this is not guaranteed.
Also, any array elements' destructors are not called which can lead to
memory leaks and other problems.

The best way to use arrays in modern C++ is to use the STL's vector
class. It is safer, more convenient and, in most cases, as efficient as
a regular array. For APIs requiring arrays, you can still use &front().


The particular events discussed are:

  * delete_var — The delete non-array variant was used to deallocate memory.

  * delete_array_var — delete[] was used to deallocate memory.


Quoting myself from the internal discussion:

The functional areas for CWE-404 are non-specific whereas for
CWE-459 is specific to file processing. In addition, if you look
at the examples, CWE-404 has the specific case for delete.
Furthermore, the observed examples of CWE-459 lists only file
processing -related issues. I'd definitely go with the more
generic weakness base CWE-404.

I'd like others' opinions  here.

On 12/20/2012 10:34 PM, David Remahl wrote:

> On Dec 20, 2012, at 2:14 PM, "Wheeler, David A" <[hidden email]> wrote:
>
>> Steve Christey said:
>>> Some people may be wondering why we don't have a file-descriptor equivalent for CWE-416.  In general, while CWE has many lower-level entries for memory, it does not have as much detailed coverage for other resources.
>>
>> And that's a good thing.  In theory, any defect could lead to a security vulnerability, but some are far more likely and common than others (once you start looking at real-world vulnerabilities).  As  http://cwe.mitre.org/about/faq.html#A.1 says, CWE is a list of "common software weaknesses that can occur in software's architecture, design, code or implementation that can lead to exploitable security vulnerabilities"... not a list of all possible software defects.  If it tried to list everything, it would lose its value.
>
> I always interpreted it as “common” in the sense of “shared”, not “prevalent”, as in Common Vulnerability Enumeration.
>
>> That said, if it *is* common and not in the CWE set, it should be added.  And if a few higher-level constructs can be added that make it easier to understand and use (e.g., because it is a better organization) -- such a high-level "use after release of any resource" - then great!
>>
>> I think key needs currently for the CWEs is to define them more clearly, more rigorously, and to better organize them in some way (e.g., identify patterns or parameterization).   Add important items where appropriate, absolutely, I'd expect to see a trickle over time.  But please don't make CWE a laundry list of all possible defects.
>
> I don’t believe that there is an inherent conflict between being very granular and specific (“leak of mach port receive right”), highlighting the most important/prevalent (“heap memory leak”), and cataloging higher orders of organization (“unreleased resource”). I do feel CWEs potential is as a laundry list of all possible defects, ways that they have led to exposures in the past, and other defects like them. All-too-often, in examining real-world flaws, I have to drop to something generalized, e.g. “Exposure of resource to wrong sphere”, when something much more specific would have been better.
>
> Limiting CWE to only covering “the most important” reminds me of deletionists on Wikipedia trying to determine where to set the bar for notablility. Wikipedia already has millions of pages; I don’t see how it could be worse with billions, provided I can still find the most important articles through some higher level of organization (e.g. article links, categories, etc).
>
>> --- David A. Wheeler
>
> Short sidenote: Right after spotting this mail in my inbox, I mysteriously decided to run sloccount on my code for the first time in ten years, spotted your name in the credits, and then went back to replying to this mail. Thanks for sloccount, I always found it a fun tool but never (consciously) knew the name of the person who wrote it :-).
>
> / Regards, David
Thanks,
--
Ramon de C Valle / Red Hat Product Security Team


smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

REMOVE

Parry Aftab
Lease remove me from this list

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Ramon de C
Valle
Sent: Thursday, December 20, 2012 8:08 PM
To: David Remahl
Cc: Wheeler, David A; 'Steven M. Christey'; Steve Grubb;
[hidden email]; [hidden email]
Subject: Re: Use after free

Hi,

To be straight to the point, it all began with an internal discussion
where I suggested that some events of the DELETE_ARRAY checker from
Coverity is best mapped to CWE-404 instead of CWE-459. The following is
an excerpt from Coverity documentation for this checker:

1.3.3. DELETE_ARRAY

The DELETE_ARRAY checker finds many instances of using delete instead of
delete[] to delete an array.

Both new and delete have two variants: one for a single structure and
one for arrays. On an allocated array, calling delete instead of
delete[] will work most of the time. However, this is not guaranteed.
Also, any array elements' destructors are not called which can lead to
memory leaks and other problems.

The best way to use arrays in modern C++ is to use the STL's vector
class. It is safer, more convenient and, in most cases, as efficient as
a regular array. For APIs requiring arrays, you can still use &front().


The particular events discussed are:

  * delete_var - The delete non-array variant was used to deallocate memory.

  * delete_array_var - delete[] was used to deallocate memory.


Quoting myself from the internal discussion:

The functional areas for CWE-404 are non-specific whereas for
CWE-459 is specific to file processing. In addition, if you look
at the examples, CWE-404 has the specific case for delete.
Furthermore, the observed examples of CWE-459 lists only file
processing -related issues. I'd definitely go with the more
generic weakness base CWE-404.

I'd like others' opinions  here.

On 12/20/2012 10:34 PM, David Remahl wrote:
> On Dec 20, 2012, at 2:14 PM, "Wheeler, David A" <[hidden email]> wrote:
>
>> Steve Christey said:
>>> Some people may be wondering why we don't have a file-descriptor
equivalent for CWE-416.  In general, while CWE has many lower-level entries
for memory, it does not have as much detailed coverage for other resources.
>>
>> And that's a good thing.  In theory, any defect could lead to a security
vulnerability, but some are far more likely and common than others (once you
start looking at real-world vulnerabilities).  As
http://cwe.mitre.org/about/faq.html#A.1 says, CWE is a list of "common
software weaknesses that can occur in software's architecture, design, code
or implementation that can lead to exploitable security vulnerabilities"...
not a list of all possible software defects.  If it tried to list
everything, it would lose its value.
>
> I always interpreted it as "common" in the sense of "shared", not
"prevalent", as in Common Vulnerability Enumeration.
>
>> That said, if it *is* common and not in the CWE set, it should be added.
And if a few higher-level constructs can be added that make it easier to
understand and use (e.g., because it is a better organization) -- such a
high-level "use after release of any resource" - then great!
>>
>> I think key needs currently for the CWEs is to define them more clearly,
more rigorously, and to better organize them in some way (e.g., identify
patterns or parameterization).   Add important items where appropriate,
absolutely, I'd expect to see a trickle over time.  But please don't make
CWE a laundry list of all possible defects.
>
> I don't believe that there is an inherent conflict between being very
granular and specific ("leak of mach port receive right"), highlighting the
most important/prevalent ("heap memory leak"), and cataloging higher orders
of organization ("unreleased resource"). I do feel CWEs potential is as a
laundry list of all possible defects, ways that they have led to exposures
in the past, and other defects like them. All-too-often, in examining
real-world flaws, I have to drop to something generalized, e.g. "Exposure of
resource to wrong sphere", when something much more specific would have been
better.
>
> Limiting CWE to only covering "the most important" reminds me of
deletionists on Wikipedia trying to determine where to set the bar for
notablility. Wikipedia already has millions of pages; I don't see how it
could be worse with billions, provided I can still find the most important
articles through some higher level of organization (e.g. article links,
categories, etc).
>
>> --- David A. Wheeler
>
> Short sidenote: Right after spotting this mail in my inbox, I mysteriously
decided to run sloccount on my code for the first time in ten years, spotted
your name in the credits, and then went back to replying to this mail.
Thanks for sloccount, I always found it a fun tool but never (consciously)
knew the name of the person who wrote it :-).
>
> / Regards, David

Thanks,
--
Ramon de C Valle / Red Hat Product Security Team
Reply | Threaded
Open this post in threaded view
|

REMOVE

DAVID ANTONELLI
Please remove me from this email list - Thank you.
Reply | Threaded
Open this post in threaded view
|

Re: REMOVE

Jiri Slaby
On 12/21/2012 01:41 PM, DAVID ANTONELLI wrote:
> Please remove me from this email list - Thank you.

This is a standard mailing list, so people, stop spamming us and remove
yourselves the usual way. The instructions are in the e-mail headers or
at lists.mitre.org...

List-Help: <http://lists.mitre.org/cgi-bin/wa.exe?LIST=CWE-RESEARCH-LIST>,
           <mailto:[hidden email]?body=INFO%20CWE-RESEARCH-LIST>
List-Unsubscribe:
<mailto:[hidden email]>
List-Subscribe: <mailto:[hidden email]>
List-Owner: <mailto:[hidden email]>
List-Archive: <http://lists.mitre.org/cgi-bin/wa.exe?LIST=CWE-RESEARCH-LIST>


--
js
Reply | Threaded
Open this post in threaded view
|

RE: Use after free

Wheeler, David A
In reply to this post by David Remahl
David Remahl [mailto:[hidden email]]:
> I don't believe that there is an inherent conflict between being very granular and specific ("leak of mach port receive right"), highlighting the most important/prevalent ("heap memory leak"), and cataloging higher orders of organization ("unreleased resource").

Agree.

> I do feel CWEs potential is as a laundry list of all possible defects, ways that they have led to exposures in the past, and other defects like them. All-too-often, in examining real-world flaws, I have to drop to something generalized, e.g. "Exposure of resource to wrong sphere", when something much more specific would have been better.

Here, I don't agree that CWE should try to do that, at least with the current CWE structure.  The effort of maintaining the details of a tree go up exponentially; having a few higher-level items is no problem,  but once you drill down, it requires exponentially more work.

> Limiting CWE to only covering "the most important" reminds me of deletionists on Wikipedia trying to determine where to set the bar for notablility. Wikipedia already has millions of pages; I don't see how it could be worse with billions, provided I can still find the most important articles through some higher level of organization (e.g. article links, categories, etc).

I'm an inclusionist myself, but there's a fundamental difference: Wikipedia is, per its byline, "the free encyclopedia that anyone can edit."  No coordination is needed to add or edit something in Wikipedia, and there are a lot of volunteers.  CWE doesn't have that kind of approach, and it's not at all clear to me that it should.  And CWE doesn't have thousands of co-editors.

But I say this only as a concession to the difficulty of actually doing it.  I certainly agree that improving software quality in general can help security specifically, and that any defect can in some circumstance lead to a vulnerability.

Another way of organizing the CWE contents, and/or finding a way to have more co-editors, might really help.  If you have ideas in that area, please post; that sounds like exactly the kind of discussion that belongs in this mailing list.

> Short sidenote: Right after spotting this mail in my inbox, I mysteriously decided to run sloccount on my code for the first time in ten years, spotted your name in the credits, and then went back to replying to this mail. Thanks for sloccount, I always found it a fun tool but never (consciously) knew the name of the person who wrote it :-).

You're very welcome!!! Glad I could help.

--- David A. Wheeler
Reply | Threaded
Open this post in threaded view
|

RE: Use after free

Christey, Steven M.
We generally try to avoid adding new entries that are purely for "quality," unless they commonly lead to vulnerabilities.

I agree mostly with David Remahl's notion of the "Common" word in CWE meaning "Shared" and usable by anybody - but, we also don't want to generate too much content that is only useful to a small number of CWE consumers.  (And the maintenance costs do increase as the size of CWE increases, so there are practical considerations.)

In general, we have not created entries for theoretical issues in CWE, but in CVE, we see new weakness types on a regular basis.  Certificate validation variants, EL injection, and hash-collision DoS are some of the more recent mini-trends that immediately come to mind.  More obscure issues like session puzzling probably need greater attention, even though there are not many/any publicly-reported vulnerabilities yet.  The more active use of CWE by software developers will also help to highlight these gaps so that they can be addressed, as we are seeing in the current discussions.

When there is a concrete relationship between a weakness and a real-world vulnerability, I believe it is worthy of inclusion.  As memory-safety issues become harder to detect  and exploit, researchers will naturally gravitate to other kinds of weaknesses, and where possible, CWE should reflect that.  One of the main benefits that I see from CWE is that it can take vulnerability knowledge from specialists, which is typically buried deep in a single vulnerability report or conference talk, and make it more accessible to the general public.

- Steve


-----Original Message-----
From: Wheeler, David A [mailto:[hidden email]]
Sent: Friday, December 21, 2012 11:08 AM
To: 'David Remahl'
Cc: [hidden email]; Steve Grubb; cwe-research-list CWE Research Discussion; Christey, Steven M.
Subject: RE: Use after free

David Remahl [mailto:[hidden email]]:
> I don't believe that there is an inherent conflict between being very granular and specific ("leak of mach port receive right"), highlighting the most important/prevalent ("heap memory leak"), and cataloging higher orders of organization ("unreleased resource").

Agree.

> I do feel CWEs potential is as a laundry list of all possible defects, ways that they have led to exposures in the past, and other defects like them. All-too-often, in examining real-world flaws, I have to drop to something generalized, e.g. "Exposure of resource to wrong sphere", when something much more specific would have been better.

Here, I don't agree that CWE should try to do that, at least with the current CWE structure.  The effort of maintaining the details of a tree go up exponentially; having a few higher-level items is no problem,  but once you drill down, it requires exponentially more work.

> Limiting CWE to only covering "the most important" reminds me of deletionists on Wikipedia trying to determine where to set the bar for notablility. Wikipedia already has millions of pages; I don't see how it could be worse with billions, provided I can still find the most important articles through some higher level of organization (e.g. article links, categories, etc).

I'm an inclusionist myself, but there's a fundamental difference: Wikipedia is, per its byline, "the free encyclopedia that anyone can edit."  No coordination is needed to add or edit something in Wikipedia, and there are a lot of volunteers.  CWE doesn't have that kind of approach, and it's not at all clear to me that it should.  And CWE doesn't have thousands of co-editors.

But I say this only as a concession to the difficulty of actually doing it.  I certainly agree that improving software quality in general can help security specifically, and that any defect can in some circumstance lead to a vulnerability.

Another way of organizing the CWE contents, and/or finding a way to have more co-editors, might really help.  If you have ideas in that area, please post; that sounds like exactly the kind of discussion that belongs in this mailing list.

> Short sidenote: Right after spotting this mail in my inbox, I mysteriously decided to run sloccount on my code for the first time in ten years, spotted your name in the credits, and then went back to replying to this mail. Thanks for sloccount, I always found it a fun tool but never (consciously) knew the name of the person who wrote it :-).

You're very welcome!!! Glad I could help.

--- David A. Wheeler
Reply | Threaded
Open this post in threaded view
|

Re: Use after free

Steve Grubb
Hello,

First, thanks for all the replies.

On Friday, December 21, 2012 11:38:14 AM Christey, Steven M. wrote:
> We generally try to avoid adding new entries that are purely for "quality,"
> unless they commonly lead to vulnerabilities.

Well, I'd like to question this a little. For example, if we look in the
resource area, we find CWE-769 File Descriptor Exhaustion...which most cases
leads to a DoS. Not exactly what I would call a vulnerability, but something
that must be fixed none-the-less.

Having worked on Xinetd code 10 years ago, I know its descriptor handling had
about every problem in the book at one time or another. For example, here's a
case where the descriptor was getting closed but used again later:

http://www.xinetd.org/cgi-
bin/cvsweb.cgi/xinetd/xinetd/retry.c.diff?r1=1.2&r2=1.3

I believe it may have caused the wrong data to go out another descriptor later
depending on it it got reused quickly. But from the point of view of the
current user it was supposed to be handling, it would be a DoS.

Reusing a closed file/socket descriptor can disclose secrets depending on
what's now connected to the descriptor.


> I agree mostly with David Remahl's notion of the "Common" word in CWE
> meaning "Shared" and usable by anybody - but, we also don't want to
> generate too much content that is only useful to a small number of CWE
> consumers.  (And the maintenance costs do increase as the size of CWE
> increases, so there are practical considerations.)

Right, but I'd like to see a few more mappings that hit the exact problem
instead of relying on a parent node that groups it together with similar but
clearly different problems. The reason I want the clarity is I want to be able
to correlate the output from multiple tools.


> In general, we have not created entries for theoretical issues in CWE, but
> in CVE, we see new weakness types on a regular basis.  Certificate
> validation variants, EL injection, and hash-collision DoS are some of the
> more recent mini-trends that immediately come to mind.  More obscure issues
> like session puzzling probably need greater attention, even though there
> are not many/any publicly-reported vulnerabilities yet.  The more active
> use of CWE by software developers will also help to highlight these gaps so
> that they can be addressed, as we are seeing in the current discussions.
>
> When there is a concrete relationship between a weakness and a real-world
> vulnerability, I believe it is worthy of inclusion.

Does it _have_ to be a leading to a vulnerability?

Thanks,
-Steve

> As memory-safety issues become harder to detect  and exploit, researchers
> will naturally gravitate to other kinds of weaknesses, and where possible,
> CWE should reflect that.One of the main benefits that I see from CWE is that
> it can take vulnerability knowledge from specialists, which is typically
> buried deep in a single vulnerability report or conference talk, and make it
> more accessible to the general public.
>
> - Steve
>
>
> -----Original Message-----
> From: Wheeler, David A [mailto:[hidden email]]
> Sent: Friday, December 21, 2012 11:08 AM
> To: 'David Remahl'
> Cc: [hidden email]; Steve Grubb; cwe-research-list CWE Research
> Discussion; Christey, Steven M. Subject: RE: Use after free
>
> David Remahl [mailto:[hidden email]]:
> > I don't believe that there is an inherent conflict between being very
> > granular and specific ("leak of mach port receive right"), highlighting
> > the most important/prevalent ("heap memory leak"), and cataloging higher
> > orders of organization ("unreleased resource").
> Agree.
>
> > I do feel CWEs potential is as a laundry list of all possible defects,
> > ways that they have led to exposures in the past, and other defects like
> > them. All-too-often, in examining real-world flaws, I have to drop to
> > something generalized, e.g. "Exposure of resource to wrong sphere", when
> > something much more specific would have been better.
> Here, I don't agree that CWE should try to do that, at least with the
> current CWE structure.  The effort of maintaining the details of a tree go
> up exponentially; having a few higher-level items is no problem,  but once
> you drill down, it requires exponentially more work.
> > Limiting CWE to only covering "the most important" reminds me of
> > deletionists on Wikipedia trying to determine where to set the bar for
> > notablility. Wikipedia already has millions of pages; I don't see how it
> > could be worse with billions, provided I can still find the most
> > important articles through some higher level of organization (e.g.
> > article links, categories, etc).
> I'm an inclusionist myself, but there's a fundamental difference: Wikipedia
> is, per its byline, "the free encyclopedia that anyone can edit."  No
> coordination is needed to add or edit something in Wikipedia, and there are
> a lot of volunteers.  CWE doesn't have that kind of approach, and it's not
> at all clear to me that it should.  And CWE doesn't have thousands of
> co-editors.
>
> But I say this only as a concession to the difficulty of actually doing it.
> I certainly agree that improving software quality in general can help
> security specifically, and that any defect can in some circumstance lead to
> a vulnerability.
>
> Another way of organizing the CWE contents, and/or finding a way to have
> more co-editors, might really help.  If you have ideas in that area, please
> post; that sounds like exactly the kind of discussion that belongs in this
> mailing list.
> > Short sidenote: Right after spotting this mail in my inbox, I mysteriously
> > decided to run sloccount on my code for the first time in ten years,
> > spotted your name in the credits, and then went back to replying to this
> > mail. Thanks for sloccount, I always found it a fun tool but never
> > (consciously) knew the name of the person who wrote it :-).
> You're very welcome!!! Glad I could help.
>
> --- David A. Wheeler
Reply | Threaded
Open this post in threaded view
|

RE: Use after free

Christey, Steven M.
Steve Grubb said:

>> We generally try to avoid adding new entries that are purely for "quality,"
>> unless they commonly lead to vulnerabilities.
>
>Well, I'd like to question this a little. For example, if we look in the
>resource area, we find CWE-769 File Descriptor Exhaustion...which most cases
>leads to a DoS. Not exactly what I would call a vulnerability, but something
>that must be fixed none-the-less.

Denial of service is a common consequence that qualifies for inclusion in CWE.  There may be debates between people about whether certain kinds of DoS constitute a vulnerability or not, but there are many scenarios in which an attacker can cause the software to consumer more resources than expected, so this is worthwhile.

Now, in this situation - as with many other CWEs - it is not ALWAYS the case that the presence of a particular weakness can be exploited by an attacker.  A good example is CWE-481 (Assigning instead of Comparing) or its parent CWE-480 (Use of Incorrect Operator), which are almost always just plain bugs - unless they happen to be in code that is used to make a security decision, allocate resources, affect control flow, etc.  (If I recall correctly, a malicious attacker tried to  compromise the Linux kernel a few years ago by introducing CWE-481 into source code that was made to look like a privilege check, but in fact was assigning a privilege.)

I get your point about improving CWE's coverage for reuse of file descriptors, especially because of the risk of disclosure to unexpected files or processes.  We will investigate this more closely for upcoming CWE versions.

- Steve


-----Original Message-----
From: Steve Grubb [mailto:[hidden email]]
Sent: Friday, December 21, 2012 1:04 PM
To: Christey, Steven M.
Cc: Wheeler, David A; 'David Remahl'; cwe-research-list CWE Research Discussion
Subject: Re: Use after free

Hello,

First, thanks for all the replies.

On Friday, December 21, 2012 11:38:14 AM Christey, Steven M. wrote:
> We generally try to avoid adding new entries that are purely for "quality,"
> unless they commonly lead to vulnerabilities.

Well, I'd like to question this a little. For example, if we look in the
resource area, we find CWE-769 File Descriptor Exhaustion...which most cases
leads to a DoS. Not exactly what I would call a vulnerability, but something
that must be fixed none-the-less.

Having worked on Xinetd code 10 years ago, I know its descriptor handling had
about every problem in the book at one time or another. For example, here's a
case where the descriptor was getting closed but used again later:

http://www.xinetd.org/cgi-
bin/cvsweb.cgi/xinetd/xinetd/retry.c.diff?r1=1.2&r2=1.3

I believe it may have caused the wrong data to go out another descriptor later
depending on it it got reused quickly. But from the point of view of the
current user it was supposed to be handling, it would be a DoS.

Reusing a closed file/socket descriptor can disclose secrets depending on
what's now connected to the descriptor.


> I agree mostly with David Remahl's notion of the "Common" word in CWE
> meaning "Shared" and usable by anybody - but, we also don't want to
> generate too much content that is only useful to a small number of CWE
> consumers.  (And the maintenance costs do increase as the size of CWE
> increases, so there are practical considerations.)

Right, but I'd like to see a few more mappings that hit the exact problem
instead of relying on a parent node that groups it together with similar but
clearly different problems. The reason I want the clarity is I want to be able
to correlate the output from multiple tools.


> In general, we have not created entries for theoretical issues in CWE, but
> in CVE, we see new weakness types on a regular basis.  Certificate
> validation variants, EL injection, and hash-collision DoS are some of the
> more recent mini-trends that immediately come to mind.  More obscure issues
> like session puzzling probably need greater attention, even though there
> are not many/any publicly-reported vulnerabilities yet.  The more active
> use of CWE by software developers will also help to highlight these gaps so
> that they can be addressed, as we are seeing in the current discussions.
>
> When there is a concrete relationship between a weakness and a real-world
> vulnerability, I believe it is worthy of inclusion.

Does it _have_ to be a leading to a vulnerability?

Thanks,
-Steve

> As memory-safety issues become harder to detect  and exploit, researchers
> will naturally gravitate to other kinds of weaknesses, and where possible,
> CWE should reflect that.One of the main benefits that I see from CWE is that
> it can take vulnerability knowledge from specialists, which is typically
> buried deep in a single vulnerability report or conference talk, and make it
> more accessible to the general public.
>
> - Steve
>
>
> -----Original Message-----
> From: Wheeler, David A [mailto:[hidden email]]
> Sent: Friday, December 21, 2012 11:08 AM
> To: 'David Remahl'
> Cc: [hidden email]; Steve Grubb; cwe-research-list CWE Research
> Discussion; Christey, Steven M. Subject: RE: Use after free
>
> David Remahl [mailto:[hidden email]]:
> > I don't believe that there is an inherent conflict between being very
> > granular and specific ("leak of mach port receive right"), highlighting
> > the most important/prevalent ("heap memory leak"), and cataloging higher
> > orders of organization ("unreleased resource").
> Agree.
>
> > I do feel CWEs potential is as a laundry list of all possible defects,
> > ways that they have led to exposures in the past, and other defects like
> > them. All-too-often, in examining real-world flaws, I have to drop to
> > something generalized, e.g. "Exposure of resource to wrong sphere", when
> > something much more specific would have been better.
> Here, I don't agree that CWE should try to do that, at least with the
> current CWE structure.  The effort of maintaining the details of a tree go
> up exponentially; having a few higher-level items is no problem,  but once
> you drill down, it requires exponentially more work.
> > Limiting CWE to only covering "the most important" reminds me of
> > deletionists on Wikipedia trying to determine where to set the bar for
> > notablility. Wikipedia already has millions of pages; I don't see how it
> > could be worse with billions, provided I can still find the most
> > important articles through some higher level of organization (e.g.
> > article links, categories, etc).
> I'm an inclusionist myself, but there's a fundamental difference: Wikipedia
> is, per its byline, "the free encyclopedia that anyone can edit."  No
> coordination is needed to add or edit something in Wikipedia, and there are
> a lot of volunteers.  CWE doesn't have that kind of approach, and it's not
> at all clear to me that it should.  And CWE doesn't have thousands of
> co-editors.
>
> But I say this only as a concession to the difficulty of actually doing it.
> I certainly agree that improving software quality in general can help
> security specifically, and that any defect can in some circumstance lead to
> a vulnerability.
>
> Another way of organizing the CWE contents, and/or finding a way to have
> more co-editors, might really help.  If you have ideas in that area, please
> post; that sounds like exactly the kind of discussion that belongs in this
> mailing list.
> > Short sidenote: Right after spotting this mail in my inbox, I mysteriously
> > decided to run sloccount on my code for the first time in ten years,
> > spotted your name in the credits, and then went back to replying to this
> > mail. Thanks for sloccount, I always found it a fun tool but never
> > (consciously) knew the name of the person who wrote it :-).
> You're very welcome!!! Glad I could help.
>
> --- David A. Wheeler
Reply | Threaded
Open this post in threaded view
|

Re: Use after free

Christina
I don't know how I was added to this discussion list, Can I please be removed!
Thank You

On Fri, Dec 21, 2012 at 10:42 AM, Christey, Steven M. <[hidden email]> wrote:
Steve Grubb said:

>> We generally try to avoid adding new entries that are purely for "quality,"
>> unless they commonly lead to vulnerabilities.
>
>Well, I'd like to question this a little. For example, if we look in the
>resource area, we find CWE-769 File Descriptor Exhaustion...which most cases
>leads to a DoS. Not exactly what I would call a vulnerability, but something
>that must be fixed none-the-less.

Denial of service is a common consequence that qualifies for inclusion in CWE.  There may be debates between people about whether certain kinds of DoS constitute a vulnerability or not, but there are many scenarios in which an attacker can cause the software to consumer more resources than expected, so this is worthwhile.

Now, in this situation - as with many other CWEs - it is not ALWAYS the case that the presence of a particular weakness can be exploited by an attacker.  A good example is CWE-481 (Assigning instead of Comparing) or its parent CWE-480 (Use of Incorrect Operator), which are almost always just plain bugs - unless they happen to be in code that is used to make a security decision, allocate resources, affect control flow, etc.  (If I recall correctly, a malicious attacker tried to  compromise the Linux kernel a few years ago by introducing CWE-481 into source code that was made to look like a privilege check, but in fact was assigning a privilege.)

I get your point about improving CWE's coverage for reuse of file descriptors, especially because of the risk of disclosure to unexpected files or processes.  We will investigate this more closely for upcoming CWE versions.

- Steve


-----Original Message-----
From: Steve Grubb [mailto:[hidden email]]
Sent: Friday, December 21, 2012 1:04 PM
To: Christey, Steven M.
Cc: Wheeler, David A; 'David Remahl'; cwe-research-list CWE Research Discussion
Subject: Re: Use after free

Hello,

First, thanks for all the replies.

On Friday, December 21, 2012 11:38:14 AM Christey, Steven M. wrote:
> We generally try to avoid adding new entries that are purely for "quality,"
> unless they commonly lead to vulnerabilities.

Well, I'd like to question this a little. For example, if we look in the
resource area, we find CWE-769 File Descriptor Exhaustion...which most cases
leads to a DoS. Not exactly what I would call a vulnerability, but something
that must be fixed none-the-less.

Having worked on Xinetd code 10 years ago, I know its descriptor handling had
about every problem in the book at one time or another. For example, here's a
case where the descriptor was getting closed but used again later:

http://www.xinetd.org/cgi-
bin/cvsweb.cgi/xinetd/xinetd/retry.c.diff?r1=1.2&r2=1.3

I believe it may have caused the wrong data to go out another descriptor later
depending on it it got reused quickly. But from the point of view of the
current user it was supposed to be handling, it would be a DoS.

Reusing a closed file/socket descriptor can disclose secrets depending on
what's now connected to the descriptor.


> I agree mostly with David Remahl's notion of the "Common" word in CWE
> meaning "Shared" and usable by anybody - but, we also don't want to
> generate too much content that is only useful to a small number of CWE
> consumers.  (And the maintenance costs do increase as the size of CWE
> increases, so there are practical considerations.)

Right, but I'd like to see a few more mappings that hit the exact problem
instead of relying on a parent node that groups it together with similar but
clearly different problems. The reason I want the clarity is I want to be able
to correlate the output from multiple tools.


> In general, we have not created entries for theoretical issues in CWE, but
> in CVE, we see new weakness types on a regular basis.  Certificate
> validation variants, EL injection, and hash-collision DoS are some of the
> more recent mini-trends that immediately come to mind.  More obscure issues
> like session puzzling probably need greater attention, even though there
> are not many/any publicly-reported vulnerabilities yet.  The more active
> use of CWE by software developers will also help to highlight these gaps so
> that they can be addressed, as we are seeing in the current discussions.
>
> When there is a concrete relationship between a weakness and a real-world
> vulnerability, I believe it is worthy of inclusion.

Does it _have_ to be a leading to a vulnerability?

Thanks,
-Steve

> As memory-safety issues become harder to detect  and exploit, researchers
> will naturally gravitate to other kinds of weaknesses, and where possible,
> CWE should reflect that.One of the main benefits that I see from CWE is that
> it can take vulnerability knowledge from specialists, which is typically
> buried deep in a single vulnerability report or conference talk, and make it
> more accessible to the general public.
>
> - Steve
>
>
> -----Original Message-----
> From: Wheeler, David A [mailto:[hidden email]]
> Sent: Friday, December 21, 2012 11:08 AM
> To: 'David Remahl'
> Cc: [hidden email]; Steve Grubb; cwe-research-list CWE Research
> Discussion; Christey, Steven M. Subject: RE: Use after free
>
> David Remahl [mailto:[hidden email]]:
> > I don't believe that there is an inherent conflict between being very
> > granular and specific ("leak of mach port receive right"), highlighting
> > the most important/prevalent ("heap memory leak"), and cataloging higher
> > orders of organization ("unreleased resource").
> Agree.
>
> > I do feel CWEs potential is as a laundry list of all possible defects,
> > ways that they have led to exposures in the past, and other defects like
> > them. All-too-often, in examining real-world flaws, I have to drop to
> > something generalized, e.g. "Exposure of resource to wrong sphere", when
> > something much more specific would have been better.
> Here, I don't agree that CWE should try to do that, at least with the
> current CWE structure.  The effort of maintaining the details of a tree go
> up exponentially; having a few higher-level items is no problem,  but once
> you drill down, it requires exponentially more work.
> > Limiting CWE to only covering "the most important" reminds me of
> > deletionists on Wikipedia trying to determine where to set the bar for
> > notablility. Wikipedia already has millions of pages; I don't see how it
> > could be worse with billions, provided I can still find the most
> > important articles through some higher level of organization (e.g.
> > article links, categories, etc).
> I'm an inclusionist myself, but there's a fundamental difference: Wikipedia
> is, per its byline, "the free encyclopedia that anyone can edit."  No
> coordination is needed to add or edit something in Wikipedia, and there are
> a lot of volunteers.  CWE doesn't have that kind of approach, and it's not
> at all clear to me that it should.  And CWE doesn't have thousands of
> co-editors.
>
> But I say this only as a concession to the difficulty of actually doing it.
> I certainly agree that improving software quality in general can help
> security specifically, and that any defect can in some circumstance lead to
> a vulnerability.
>
> Another way of organizing the CWE contents, and/or finding a way to have
> more co-editors, might really help.  If you have ideas in that area, please
> post; that sounds like exactly the kind of discussion that belongs in this
> mailing list.
> > Short sidenote: Right after spotting this mail in my inbox, I mysteriously
> > decided to run sloccount on my code for the first time in ten years,
> > spotted your name in the credits, and then went back to replying to this
> > mail. Thanks for sloccount, I always found it a fun tool but never
> > (consciously) knew the name of the person who wrote it :-).
> You're very welcome!!! Glad I could help.
>
> --- David A. Wheeler