vulnerabilities

Discussion in 'C Programming' started by wijhierbeneden, Oct 21, 2004.

  1. 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
    wijhierbeneden, Oct 21, 2004
    #1
    1. Advertising

  2. In article <>,
    wijhierbeneden <> wrote:
    >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

    --
    Dave Vandervies
    In the reality I am currently experiencing, I have no dog. I agree it is
    possible that I might have had a dog before some student C programmer or
    other overflowed a signed int. --Richard Heathfield in comp.lang.c
    Dave Vandervies, Oct 21, 2004
    #2
    1. Advertising

  3. wijhierbeneden

    Malcolm Guest

    "wijhierbeneden" <>
    >
    > 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.
    Malcolm, Oct 21, 2004
    #3
  4. wijhierbeneden wrote:

    > 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.
    Martin Ambuhl, Oct 21, 2004
    #4
  5. wijhierbeneden

    Eric Sosman Guest

    wijhierbeneden wrote:
    > 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 ...

    --
    Eric Sosman, Oct 21, 2004
    #5
  6. wijhierbeneden

    jacob navia Guest

    wijhierbeneden wrote:
    > 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.
    jacob navia, Oct 21, 2004
    #6
  7. "wijhierbeneden" <> wrote > 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


    Why do you ask? MPJ
    Merrill & Michele, Oct 21, 2004
    #7
  8. wijhierbeneden

    jacob navia Guest

    Martin Ambuhl wrote:

    > wijhierbeneden wrote:
    >
    >> 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.


    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, Oct 21, 2004
    #8
  9. wijhierbeneden

    jacob navia Guest

    Malcolm wrote:

    > "wijhierbeneden" <>

    [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.
    jacob navia, Oct 21, 2004
    #9
  10. On 21 Oct 2004, wijhierbeneden wrote:

    > 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.


    --
    --------------------------
    Mobile: +44 07779080838
    http://www.stev.org
    12:50am up 1 day, 11:16, 4 users, load average: 0.00, 0.02, 0.00
    James Stevenson, Oct 22, 2004
    #10
  11. wijhierbeneden <> wrote:
    > 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.





    --
    <Insert your favourite quote here.>
    Erik Trulsson
    Erik Trulsson, Oct 22, 2004
    #11
  12. jacob navia <> writes:
    [...]
    > 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.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
    Keith Thompson, Oct 22, 2004
    #12
  13. wijhierbeneden

    Richard Bos Guest

    Keith Thompson <> wrote:

    > jacob navia <> writes:
    > [...]
    > > 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.


    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
    Richard Bos, Oct 22, 2004
    #13
  14. wijhierbeneden

    CBFalconer Guest

    jacob navia wrote:
    >

    .... 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?

    --
    "I support the Red Sox and any team that beats the Yankees"
    "Any baby snookums can be a Yankee fan, it takes real moral
    fiber to be a Red Sox fan" - "I listened to Toronto come back
    from 3:0 in '42, I watched Boston come back from 3:0 in '04"
    CBFalconer, Oct 22, 2004
    #14
  15. wijhierbeneden

    Randy Howard Guest

    In article <>, says...
    > jacob navia wrote:
    > >

    > ... 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?


    Apparently not.

    --
    Randy Howard (2reply remove FOOBAR)
    Randy Howard, Oct 22, 2004
    #15
  16. wijhierbeneden

    Randy Howard Guest

    In article <4178333f$0$15136$>,
    says...
    > 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.

    --
    Randy Howard (2reply remove FOOBAR)
    Randy Howard, Oct 22, 2004
    #16
  17. wijhierbeneden

    jacob navia Guest

    Randy Howard wrote:
    > In article <>, says...
    >
    >>jacob navia wrote:
    >>
    >>... 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?

    >
    >
    > 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);

    ???
    jacob navia, Oct 22, 2004
    #17
  18. [snips]

    On Fri, 22 Oct 2004 00:25:27 +0200, jacob navia wrote:

    > 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.
    Kelsey Bjarnason, Oct 22, 2004
    #18

  19. > jacob navia wrote:
    > > Since you can write programs in strict C in C++ (the whole C89
    > > standard is quite accepted),


    > 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, Oct 22, 2004
    #19
  20. "Randy Howard" <> wrote in message
    news:...
    > In article <4178333f$0$15136$>,


    > says...
    > > 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.
    >
    > --
    > Randy Howard (2reply remove FOOBAR)


    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
    Merrill & Michele, Oct 22, 2004
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. wijhierbeneden

    vulnerabilities

    wijhierbeneden, Oct 21, 2004, in forum: C++
    Replies:
    5
    Views:
    1,408
    Christopher Benson-Manica
    Oct 22, 2004
  2. Dave Vandervies

    Re: vulnerabilities

    Dave Vandervies, Oct 22, 2004, in forum: C++
    Replies:
    3
    Views:
    357
    Dan Pop
    Oct 22, 2004
  3. jacob navia

    A good article about vulnerabilities

    jacob navia, Oct 23, 2004, in forum: C Programming
    Replies:
    1
    Views:
    300
    Chris Torek
    Oct 23, 2004
  4. Nanda

    IIS Vulnerabilities

    Nanda, Dec 1, 2005, in forum: ASP General
    Replies:
    3
    Views:
    137
    Bob Barrows [MVP]
    Dec 2, 2005
  5. John W. Long
    Replies:
    3
    Views:
    123
    Hugh Sasse Staff Elec Eng
    Aug 26, 2003
Loading...

Share This Page