vulnerabilities

[wijhierbeneden]

Hello

I want to make a list of all the vulnerabilities in C/C++.
I am aware of bufferoverflow/heapoverflow/race conditions/format string bugs/
Off-by-one/ numeric under- and overflow/ unsigned-signed mismatch

Are there other vulnerabilities in c/c++??

thx

 

[Dave Vandervies]

Hello

I want to make a list of all the vulnerabilities in C/C++.
I am aware of bufferoverflow/heapoverflow/race conditions/format string bugs/
Off-by-one/ numeric under- and overflow/ unsigned-signed mismatch

Are there other vulnerabilities in c/c++??

Incompetent programmers, especially the ones who think they're competent.

(Unless you're interested in ones that only apply to C or C++, though
that eliminates all the ones in your list too.)


dave

 

[Malcolm]

I want to make a list of all the vulnerabilities in C/C++.
I am aware of bufferoverflow/heapoverflow/race conditions/format string
bugs/
Off-by-one/ numeric under- and overflow/ unsigned-signed mismatch

Are there other vulnerabilities in c/c++??

Stack overflow for recursive functions springs to mind.

One of the main problems with C is that there is no error-handling
mechanism, so exceptions must be coded as part of the normal flow of the
program. This can make testing very difficult.

 

[Martin Ambuhl]

Hello

I want to make a list of all the vulnerabilities in C/C++.

The good news is that there are none. Since "C/C++" is a fictional
language with no features at all, it escapes any vulnerabilities the two
languages C and C++ might have.

There is, of course, no reason to assume that any vulnerabilities the
two different languages C and C++ might have are shared.

 

[Eric Sosman]

Hello

I want to make a list of all the vulnerabilities in C/C++.
I am aware of bufferoverflow/heapoverflow/race conditions/format string bugs/
Off-by-one/ numeric under- and overflow/ unsigned-signed mismatch

Are there other vulnerabilities in c/c++??

A colleague of mine once encountered

#define HASHSIZE 51 /* a small prime */

.... and since it's well beyond the capabilities of
current (or even of imagined) compilers to detect
bugs of this sort, I think we can classify this as
a built-in vulnerability of the language.

You're going to wind up with a l-o-n-g list,
you know ...

 

[jacob navia]

Hello

I want to make a list of all the vulnerabilities in C/C++.
I am aware of bufferoverflow/heapoverflow/race conditions/format string bugs/
Off-by-one/ numeric under- and overflow/ unsigned-signed mismatch

Are there other vulnerabilities in c/c++??

thx

Your list makes no sense. Let's go into this list in
more detail:

1: Buffer overflows. This can be seen as a vulnerability of C.
There were discussions here about length delimited strings,
and it is a vulnerability that can be fixed.

2: Heap overflow. Strange, difficult to see what you mean here:
2A: The heap gets bigger than the stack and overflows the stack.
This one has nothing to do with C.
2B: You ask for more memory than the system can give
you and the program crashes.
This one has nothing to do with C either.

3: Race conditions: They can happen to you in any language.
This is a general problem of multi-thread, multi-tasking
programming. Since this type of programming is done often
in C, they happen in C but they could happen in lisp too.

4: Format string bugs: Yes, "%s" implies filling a buffer
with an underminate number of bytes and this is a bad
spec in C (in my opinion).
No use of denying this. It induces to error. See
the discussion about strings.

5: Off by one can happen in *any* language, and even in
hardware. Remember the infamous bug Intel had in
the division? It was an off by one copy of the constants
needed by the algorithm: one row was missing. This is
a logic bug, not a C specific one.

6: Same for overflow/undeflow. You can have it in any
language where numbers are accepted !

7: Unsigned/signed mismatch is an error specific to
languages that allow you to use unsigned integers.
There aren't many, and C is one of them. This is
a problem not with C but with people making errors.
As any error, this can lead to bugs but I think the
advantages outweight the problems with unsigned
numbers.

I would admit that buffer overflows and string handling in
C lead to catastrophes in hostile environments. I am just
of the opinion that this can be fixed without throwing away
all the language with it.

What makes C interesting is precisely this absence of an
established paradigm of the language. C is not object
oriented, nor list oriented or array oriented like APL.

It doesn't impose you any preconceived view of your
application.

 

[Merrill & Michele]

I am aware of bufferoverflow/heapoverflow/race conditions/format string bugs/
Off-by-one/ numeric under- and overflow/ unsigned-signed mismatch

Are there other vulnerabilities in c/c++??

thx

Why do you ask? MPJ

 

[jacob navia]

The good news is that there are none. Since "C/C++" is a fictional
language with no features at all, it escapes any vulnerabilities the two
languages C and C++ might have.

There is, of course, no reason to assume that any vulnerabilities the
two different languages C and C++ might have are shared.

Since you can write programs in strict C in C++ (the whole C89
standard is quite accepted), and even if not used by C++
programmers, C is still in the specs of C++, so any C
vulnerabilities are in C++ also.

 

[jacob navia]

"wijhierbeneden" <[email protected]> [snip]

Are there other vulnerabilities in c/c++??

Stack overflow for recursive functions springs to mind.

Stack overflow is inherent to all languages that use a
stack. It can happen to you from Pascal to Lisp, passing
through Java and Delphi.

There is nothing surprising that C also shares the problem
of any software that uses a stack.

 

[James Stevenson]

Hello

I want to make a list of all the vulnerabilities in C/C++.
I am aware of bufferoverflow/heapoverflow/race conditions/format string bugs/
Off-by-one/ numeric under- and overflow/ unsigned-signed mismatch

Are there other vulnerabilities in c/c++??

just plane bad design. This alone can cause a headache of problems since
normally the bug of that size cannot be fixed easaliy.

 

[Erik Trulsson]

Hello

I want to make a list of all the vulnerabilities in C/C++.
I am aware of bufferoverflow/heapoverflow/race conditions/format string bugs/
Off-by-one/ numeric under- and overflow/ unsigned-signed mismatch

Are there other vulnerabilities in c/c++??

Those are not vulnerabilities in C (or C++ for that matter.)
They are problems/bugs that can occur in programs, which might be
written in C, but might also be written in some other language.

 

[Keith Thompson]

2: Heap overflow. Strange, difficult to see what you mean here:
2A: The heap gets bigger than the stack and overflows the stack.
This one has nothing to do with C.
2B: You ask for more memory than the system can give
you and the program crashes.
This one has nothing to do with C either.

The C standard doesn't use the term "heap", but presumably heap
overflow is what causes malloc() to return a null pointer.

 

[Richard Bos]

The C standard doesn't use the term "heap", but presumably heap
overflow is what causes malloc() to return a null pointer.

Which is actually _less_ of a problem in C than in languages where you
just have to pray that your dynamically-sized object doesn't crash,
wheelcaps flying, into the stack. At least you can check for a null
return from malloc().

Richard

 

[CBFalconer]

.... snip ...

Since you can write programs in strict C in C++ (the whole C89
standard is quite accepted), and even if not used by C++
programmers, C is still in the specs of C++, so any C
vulnerabilities are in C++ also.

Surely you know better than that?

 

[Randy Howard]

Surely you know better than that?

Apparently not.

 

[Randy Howard]

3: Race conditions: They can happen to you in any language.
This is a general problem of multi-thread, multi-tasking
programming. Since this type of programming is done often
in C, they happen in C but they could happen in lisp too.

There is no threading in C. Many people, (myself included)
write multi-threaded code using non-standard (or even standards
outside the scope of ISO/ANSI C) extensions to C compilers of
course, but that's OT here.

 

[jacob navia]

Apparently not.

int main(void)
{
char p[2];

memset(p,0,123546);
}

That is not possible in C++?

You can't write

printf("%s\n",str);

???

 

[Kelsey Bjarnason]

[snips]

Since you can write programs in strict C in C++ (the whole C89
standard is quite accepted),

Really. Try this in your C++ compiler:

#include <stdlib.h>

int main()
{
double *d = malloc(100);
if ( d ) free( d );
return 0;
}

Works fine in C. Doesn't even compile in C++. Nor do endless other
examples of perfectly valid C code.

 

[Merrill & Michele]

Kelsey Bjarnason"
Really. Try this in your C++ compiler:

#include <stdlib.h>

int main()
{
double *d = malloc(100);
if ( d ) free( d );
return 0;
}

Works fine in C. Doesn't even compile in C++. Nor do endless other
examples of perfectly valid C code.

I tried this code in mvc as a .c file, and it compiled. As a .cpp file, it
did not. Ms. Bjarnason would seem to be correct. (Kelsey is a female name
around here.) MPJ

 

[Merrill & Michele]

says...

There is no threading in C. Many people, (myself included)
write multi-threaded code using non-standard (or even standards
outside the scope of ISO/ANSI C) extensions to C compilers of
course, but that's OT here.

Mr. Howard,
I'm trying to improve the way I communicate in this forum and am testing to
see whether I contacted you correctly. If you work for verizon, then I help
pay your salary RSVP if successful. Merrill Jensen