Asp Forum - Research to Create Automated Buffer Overflow Protection

Heidi Brayer

8/26/2014 4:12:00 PM

According to a 2013 report examining 25 years of vulnerabilities (from 1998 to 2012), buffer overflow causes 14 percent of software security vulnerabilities and 35 percent of critical vulnerabilities, making it the leading cause of software security vulnerabilities overall. As of July 2014, the TIOBE index indicates that the C programming language, which is the language most commonly associated with buffer overflows, is the most popular language with 17.1 percent of the market. Embedded systems, network stacks, networked applications, and high-performance computing rely heavily upon C. Embedded systems can be especially vulnerable to buffer overflows because many of them lack hardware memory management units. This blog post describes my research on the Secure Coding Initiative in the CERT Division of the Carnegie Mellon University Software Engineering Institute to create automated buffer overflow prevention.

To read more, please follow this link
http://blog.sei.cmu.edu/post.cfm/performance-compiler-assisted-memory-safety-ch....

28 Answers

Dmitry A. Kazakov

8/26/2014 4:55:00 PM

On Tue, 26 Aug 2014 09:11:35 -0700 (PDT), Heidi Brayer wrote:

> According to a 2013 report examining 25 years of vulnerabilities (from
> 1998 to 2012), buffer overflow causes 14 percent of software security
> vulnerabilities and 35 percent of critical vulnerabilities, making it the
> leading cause of software security vulnerabilities overall. As of July
> 2014, the TIOBE index indicates that the C programming language, which is
> the language most commonly associated with buffer overflows, is the most
> popular language with 17.1 percent of the market. Embedded systems,
> network stacks, networked applications, and high-performance computing
> rely heavily upon C. Embedded systems can be especially vulnerable to
> buffer overflows because many of them lack hardware memory management
> units. This blog post describes my research on the Secure Coding
> Initiative in the CERT Division of the Carnegie Mellon University Software
> Engineering Institute to create automated buffer overflow prevention.
>
> To read more, please follow this link
> http://blog.sei.cmu.edu/post.cfm/performance-compiler-assisted-memory-safety-ch....

Would be much more helpful if they researched how to get rid of C, or at
least, stopped teach students crappy languages and idiotic SW design
techniques.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-...

Richard Heathfield

8/26/2014 5:17:00 PM

Dmitry A. Kazakov wrote:

> On Tue, 26 Aug 2014 09:11:35 -0700 (PDT), Heidi Brayer wrote:
>

<snip>

>> This blog post describes my research on the Secure Coding
>> Initiative in the CERT Division of the Carnegie Mellon University
>> Software Engineering Institute to create automated buffer overflow
>> prevention.
>>
>> To read more, please follow this link
>> http://blog.sei.cmu.edu/post.cfm/performance-compiler-assist...
safety-checking-237.
>
> Would be much more helpful if they researched how to get rid of C, or at
> least, stopped teach students crappy languages and idiotic SW design
> techniques.

The problem is that C is popular even now because it is such a powerful
language. You can't eliminate stupidity, but by reducing the scope for doing
stupid things you also reduce the scope for doing clever things. Few people
like to think of themselves as stupid (whatever the true facts of the
matter), so they get this idea that they can avoid C's pitfalls whilst
taking advantage of its power. And some of them, at least, are right.

The only ways to get rid of C, in decreasing order of severity are:

(a) catastrophic global war, pestilence, or famine;
(b) legislation of an alarmingly authoritarian nature;
(c) the provision of an even more powerful language that is even more prone
to being abused.

If you add bounds-checking to C (which is what we're talking about, really),
(a) you discover eventually that people have already done it, and (b)
bounds-checking imposes a performance penalty that at least some people are
not prepared to tolerate.

Note, too, that even if you consider C to be a "crappy language", that
doesn't mean that the rest of the world agrees with you. Some consider C to
be a powerful tool for writing fast programs. Powerful tools often have
sharp edges. If you cut yourself, that doesn't mean the tool is crappy. It
may just mean you don't know how to use the tool properly. And filing down
the edges may leave you without any appropriate tool to use in a particular
situation.

If you want Ada, you know where to find it.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

Dmitry A. Kazakov

8/26/2014 5:35:00 PM

On Tue, 26 Aug 2014 18:16:47 +0100, Richard Heathfield wrote:

> The only ways to get rid of C, in decreasing order of severity are:
>
> (a) catastrophic global war, pestilence, or famine;
> (b) legislation of an alarmingly authoritarian nature;
> (c) the provision of an even more powerful language that is even more prone
> to being abused.

(d) liability to the damages caused by software faults.

> (b)
> bounds-checking imposes a performance penalty that at least some people are
> not prepared to tolerate.

The necessity of bounds-checking is greatly overestimated. There is no need
to check for the bounds if the language constructs prevent indices or
iterators going out of the bounds. C lacks such constructs, e.g. safe
looping over the elements of a container or array. In many if not most of
the cases this does not involve any explicit index at all and if it does,
the index is guaranteed within the bounds. Such primitives would offer a
better performance over crude C's pointer arithmetic as well.

> If you want Ada, you know where to find it.

I do.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-...

Richard Heathfield

8/26/2014 6:00:00 PM

Dmitry A. Kazakov wrote:

> On Tue, 26 Aug 2014 18:16:47 +0100, Richard Heathfield wrote:
>
>> The only ways to get rid of C, in decreasing order of severity are:
>>
>> (a) catastrophic global war, pestilence, or famine;
>> (b) legislation of an alarmingly authoritarian nature;
>> (c) the provision of an even more powerful language that is even more
>> prone to being abused.
>
> (d) liability to the damages caused by software faults.

Like (a) above, that would take out ALL programming languages, not just C.

>> (b)
>> bounds-checking imposes a performance penalty that at least some people
>> are not prepared to tolerate.
>
> The necessity of bounds-checking is greatly overestimated.

Precisely my point.

<snip>

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

Melzzzzz

8/26/2014 6:17:00 PM

On Tue, 26 Aug 2014 18:16:47 +0100
Richard Heathfield <invalid@see.sig.invalid> wrote:

>
> If you add bounds-checking to C (which is what we're talking about,
> really), (a) you discover eventually that people have already done
> it, and (b) bounds-checking imposes a performance penalty that at
> least some people are not prepared to tolerate.

For example take scimark2 in "go" language:
with bounds checking
bmaxa@maxa:~/examples/go/src/github.com/bmaxa/sci$ go build -o scimark2
bmaxa@maxa:~/examples/go/src/github.com/bmaxa/sci$ time ./scimark2
** **
** SciMark2 Numeric Benchmark, see http://math.nist.g... **
** for details. (Results can be submitted to pozo@nist.gov) **
** **
Using 2.00 seconds min time per kernel.
Composite Score: 1060.91
FFT Mflops: 933.39 (N=1024)
SOR Mflops: 1235.80 (100 x 100)
MonteCarlo: Mflops: 179.01
Sparse matmult Mflops: 1485.93 (N=1000, nz=5000)
LU Mflops: 1470.43 (M=100, N=100)

real 0m34.279s
user 0m34.232s
sys 0m0.055s
without:
bmaxa@maxa:~/examples/go/src/github.com/bmaxa/sci$ go build -o scimark2 -gcflags -B
bmaxa@maxa:~/examples/go/src/github.com/bmaxa/sci$ time ./scimark2
** **
** SciMark2 Numeric Benchmark, see http://math.nist.g... **
** for details. (Results can be submitted to pozo@nist.gov) **
** **
Using 2.00 seconds min time per kernel.
Composite Score: 1231.16
FFT Mflops: 1177.07 (N=1024)
SOR Mflops: 1258.24 (100 x 100)
MonteCarlo: Mflops: 168.89
Sparse matmult Mflops: 1702.12 (N=1000, nz=5000)
LU Mflops: 1849.46 (M=100, N=100)

real 0m30.569s
user 0m30.531s
sys 0m0.046s

It is 20% faster without bounds checking !

--
Click OK to continue...

Melzzzzz

8/26/2014 6:40:00 PM

On Tue, 26 Aug 2014 19:35:26 +0200
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:

> On Tue, 26 Aug 2014 18:16:47 +0100, Richard Heathfield wrote:
>
> > The only ways to get rid of C, in decreasing order of severity are:
> >
> > (a) catastrophic global war, pestilence, or famine;
> > (b) legislation of an alarmingly authoritarian nature;
> > (c) the provision of an even more powerful language that is even
> > more prone to being abused.
>
> (d) liability to the damages caused by software faults.

Bad programmers write bad programs in any language. There is no
such language that protects from software faults...

>
> > (b)
> > bounds-checking imposes a performance penalty that at least some
> > people are not prepared to tolerate.
>
> The necessity of bounds-checking is greatly overestimated. There is
> no need to check for the bounds if the language constructs prevent
> indices or iterators going out of the bounds. C lacks such
> constructs, e.g. safe looping over the elements of a container or
> array. In many if not most of the cases this does not involve any
> explicit index at all and if it does, the index is guaranteed within
> the bounds. Such primitives would offer a better performance over
> crude C's pointer arithmetic as well.

How so? Performance should be the same...
Problem with C arrays is that they are converted to raw pointers
and length information is lost. Errors come out because
wrong array length is passed around or not at all...

--
Click OK to continue...

Chris Uppal

8/26/2014 7:14:00 PM

Melzzzzz wrote:

> > The necessity of bounds-checking is greatly overestimated. There is
> > no need to check for the bounds if the language constructs prevent
> > indices or iterators going out of the bounds. C lacks such
> > constructs, e.g. safe looping over the elements of a container or
> > array. In many if not most of the cases this does not involve any
> > explicit index at all and if it does, the index is guaranteed within
> > the bounds. Such primitives would offer a better performance over
> > crude C's pointer arithmetic as well.
>
> How so? Performance should be the same...

I believe the idea is that the C compiler cannot make assumptions about whether
pointer operations overlap. If the compiler knows more then it can optimise
better.

I'm not sure how much difference this makes in practise (compared, say, to the
difference between two different compilers, or the output from one compiler
executed on two different CPUs).

-- chris

Dmitry A. Kazakov

8/26/2014 7:26:00 PM

On Tue, 26 Aug 2014 18:59:49 +0100, Richard Heathfield wrote:

> Dmitry A. Kazakov wrote:
>
>> On Tue, 26 Aug 2014 18:16:47 +0100, Richard Heathfield wrote:
>>
>>> The only ways to get rid of C, in decreasing order of severity are:
>>>
>>> (a) catastrophic global war, pestilence, or famine;
>>> (b) legislation of an alarmingly authoritarian nature;
>>> (c) the provision of an even more powerful language that is even more
>>> prone to being abused.
>>
>> (d) liability to the damages caused by software faults.
>
> Like (a) above, that would take out ALL programming languages, not just C.

I don't see anything catastrophic in that. Just making the software market
working. Yes it could take out languages promoting software quality as an
expense.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-...

Richard Heathfield

8/26/2014 7:33:00 PM

Dmitry A. Kazakov wrote:

> On Tue, 26 Aug 2014 18:59:49 +0100, Richard Heathfield wrote:
>
>> Dmitry A. Kazakov wrote:
>>
>>> On Tue, 26 Aug 2014 18:16:47 +0100, Richard Heathfield wrote:
>>>
>>>> The only ways to get rid of C, in decreasing order of severity are:
>>>>
>>>> (a) catastrophic global war, pestilence, or famine;
>>>> (b) legislation of an alarmingly authoritarian nature;
>>>> (c) the provision of an even more powerful language that is even more
>>>> prone to being abused.
>>>
>>> (d) liability to the damages caused by software faults.
>>
>> Like (a) above, that would take out ALL programming languages, not just
>> C.
>
> I don't see anything catastrophic in that.

If I take you at your word, you don't see anything catastrophic about the
collapse of the software world as we know it.

> Just making the software market
> working. Yes it could take out languages promoting software quality as an
> expense.

If people were made liable for damages inflicted by their broken software,
the hike in their insurance premiums would make it uneconomic to produce any
software at all. This would destroy not only C, but also Ada, C#, SmallTalk,
Lithp, Ruby, Haskell... the lot. Nobody would write programs any more. This
would of course have the advantage that no new buffer overrun problems would
be created.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

Dmitry A. Kazakov

8/26/2014 7:38:00 PM

On Tue, 26 Aug 2014 20:39:41 +0200, Melzzzzz wrote:

> On Tue, 26 Aug 2014 19:35:26 +0200
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
>
>> On Tue, 26 Aug 2014 18:16:47 +0100, Richard Heathfield wrote:
>>
>>> The only ways to get rid of C, in decreasing order of severity are:
>>>
>>> (a) catastrophic global war, pestilence, or famine;
>>> (b) legislation of an alarmingly authoritarian nature;
>>> (c) the provision of an even more powerful language that is even
>>> more prone to being abused.
>>
>> (d) liability to the damages caused by software faults.
>
> Bad programmers write bad programs in any language.

Bad drivers drive any cars poorly. Which does not mean that cars should
have wheels falling out.

Languages should be chosen according to their technical merits and software
quality must be the most important one.

> There is no such language that protects from software faults...

Someone, *not* the customer, must pay for the faults. That would change
everything, languages and programmers included. C is only a symptom. The
real problem is socialization of software development risks and expenses.
Without that languages like C could not survive.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-...

comp.programming

Research to Create Automated Buffer Overflow Protection

Heidi Brayer

Dmitry A. Kazakov

Richard Heathfield

Dmitry A. Kazakov

Richard Heathfield

Melzzzzz

Melzzzzz

Chris Uppal

Dmitry A. Kazakov

Richard Heathfield

Dmitry A. Kazakov

x Login to ForumsZone