vulnerabilities

[CBFalconer]

(e-mail address removed) says...

Apparently not.

int main(void)
{
char p[2];
memset(p,0,123546);
}

That is not possible in C++?

That has undefined behavior already. Try:

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

new[0] = sizeof '1';
return 0;
}

which won't compile under C++, and if you change the name of new
won't give the right answer. These things are elementary.

 

[Christopher Benson-Manica]

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

memset(p,0,123546);
}

That is not possible in C++?

No, because the C header that contains the prototype for memset() does
not have the same name as the C++ header containing the same
prototype. Unless, of course, you want to argue that <cstring> is
part of the C standard library.

 

[Christopher Benson-Manica]

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

I would venture to guess that Kelsey is male - very few women seem
interested in the endless pageantry of pedantry that is comp.lang.c

 

[Merrill & Michele]

Christopher Benson-Manica"
I would venture to guess that Kelsey is male - very few women seem
interested in the endless pageantry of pedantry that is comp.lang.c

I thought Joona from Helsinki might not have a kickstand. Is this really a
sausage party? MPJ

 

[Dave Vandervies]

[Topic drifting from C to C++; crossposted to comp.lang.c++ and followups set]

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

memset(p,0,123546);
}

That is not possible in C++?

No, because the C header that contains the prototype for memset() does
not have the same name as the C++ header containing the same
prototype. Unless, of course, you want to argue that <cstring> is
part of the C standard library.

I thought that <cstring> had the prototype for std::memset and the
prototype for (unadorned) memset was still in <string.h>?


dave

 

[Merrill & Michele]

Please ignore this post and the previous. I was attempting to contact
outside the forum and failed. This qualifies as a mispost and not a test.
MPJ

 

[jacob navia]

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

memset(p,0,123546);
}

That is not possible in C++?

No, because the C header that contains the prototype for memset() does
not have the same name as the C++ header containing the same
prototype. Unless, of course, you want to argue that <cstring> is
part of the C standard library.

I have just compiled this in C++, and the program crashes as
it should:

#include <stdio.h>
void memset(char * p,int s,int b)
{
while (b--)
*p++ = s;
}

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

memset(p,0,123546);
printf("not reached \n");
}

I repeat: most of C89 is accepted in C++ what opens the same
vulnerabilities...

Compiler:
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86
Using c++ mode

 

[Dan Pop]

What makes you think Kelsey Bjarnason is a native of your locale?

I thought Joona from Helsinki might not have a kickstand. Is this really a
sausage party? MPJ

Joona from Helsinki is Jonas from London or New York. There are plenty of
Finnish male names ending in "a". But the craziest of all is English,
of course, where names like Robin or Dana are genderless.

Dan

 

[Martin Ambuhl]

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

Note the non sequitur: working from the premise that exists some program
in strict C that is also C++, he derives the absurd claim "any C
vulnerabilities are in C++ also." Ah yes, the "it is true for one
instance therefore for all instances" argument. 2x-3=0 is true for
x=1.5, therefore it is true for all x.

Hoping to cover his silly ass, he snips his earlier claim but appears to
be defending it with the incomplete and completely wrong example:

int main(void)
{
char p[2];
memset(p,0,123546);
}

Having been caught on that, he still pretends that he was right all
along by pretending that he made the following claim:

I repeat: most of C89 is accepted in C++ what opens the same
vulnerabilities...

Not only is that not grammatical, he provides no evidence for it.

This is not the first time that Navia has posted bullshit and then tried
to cover his tracks by pretending to have written something other than
that which is plainly visible to all.

 

[Dan Pop]

I thought that <cstring> had the prototype for std::memset and the
prototype for (unadorned) memset was still in <string.h>?

Yes, for backward compatibility with C, but the usage of C header names
is deprecated in C++:

For compatibility with the Standard C library, the C++ Standard
library provides the 18 C headers (D.5), but their use is
deprecated in C++.

Dan

 

[jacob navia]

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.

Note the non sequitur: working from the premise that exists some program
in strict C that is also C++, he derives the absurd claim "any C
vulnerabilities are in C++ also." Ah yes, the "it is true for one
instance therefore for all instances" argument. 2x-3=0 is true for
x=1.5, therefore it is true for all x.

Hoping to cover his silly ass, he snips his earlier claim but appears to
be defending it with the incomplete and completely wrong example:

int main(void)
{
char p[2];
memset(p,0,123546);
}

Having been caught on that, he still pretends that he was right all
along by pretending that he made the following claim:

I repeat: most of C89 is accepted in C++ what opens the same
vulnerabilities...

Not only is that not grammatical, he provides no evidence for it.

This is not the first time that Navia has posted bullshit and then tried
to cover his tracks by pretending to have written something other than
that which is plainly visible to all.

Mr Ambuhl:

I presented an example that is semantically equivalent to my first
example, and it compiles. What my point is, is that buffer overflows
are not restricted to C but appear in C++ also.

I do not pretend that my first example compiles. The second does
however: here it is again:


#include <stdio.h>
void memset(char * p,int s,int b)
{
while (b--)
*p++ = s;
}

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

memset(p,0,123546);
printf("not reached \n");
}

Will you pretend that this is not legal C++?
It compiles perfectly and crashes as it should.

Other vulnerabilities like
sprintf(buf,"%s\n",somestring);
will compile too.

C++ accepts most of the C89 syntax. Yes, there are
several problems with some C constructs, but *most*
of C is still legal C++ I am sorry, this is an evidence.

Your language (hopes to cover his silly ass, etc) just shows
your anal fixation... Go to a doctor man.

 

[Martin Ambuhl]

The completely clueless jacob navia wrote:

I do not pretend that my first example compiles. The second does
however: here it is again:


#include <stdio.h>
void memset(char * p,int s,int b)
{
while (b--)
*p++ = s;
}

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

memset(p,0,123546);
printf("not reached \n");
}

Will you pretend that this is not legal C++?
It compiles perfectly and crashes as it should.

It is not legal C or C++ in a hosted implementation. Please throw your
Schildt book away.

 

[Christopher Benson-Manica]

void main(void)

^^^^
Now why in the world would *you* post something so ridiculous?

{
char p[2];

memset(p,0,123546);
printf("not reached \n");
}

Will you pretend that this is not legal C++?
It compiles perfectly and crashes as it should.

There's no "should" involved with undefined behavior.

 

[Dave Vandervies]

void memset(char * p,int s,int b)

Undefined behavior in C (N869 7.1.3#2, see also #1 and 7.21.6.1).
Not sure about C++, but at best highly antisocial there.

void main(void)

Undefined behavior in C (N869 5.1.2.2.1#1).
I believe this is a constraint violation in C++, though I'm not
sufficiently familiar with C++ standardese to be sure; in any case it
violates 3.6.1#2 of the draft C++ standard I'm looking at.

Will you pretend that this is not legal C++?

No pretending needed; it's neither legal C++ nor legal C.


dave

 

[Keith Thompson]

Surely you know better than that?

I presume everyone here knows that C++ is not a strict superset of C
(there are valid C programs that either aren't valid C++ programs, or
are valid C++ programs with different behavior), but that it's
*nearly* a superset, and that most or all valid C programs can be
converted fairly easily to valid C++ if they aren't already. The
relationship is close enough that any vulnerabilities in C are almost
certain to be vulnerabilities in C++ as well.

Jacob's comment above, "the whole C89 standard is quite accepted" can
reasonably be read as an incorrect assertion that C++ is a strict
superset of C, thus this whole tedious subthread. I presume this is a
result of Jacob expressing himself imperfectly (which all of us do
from time to time) rather than an actual misunderstanding on his part.

As far as I know, the C90 standard library is included by reference in
C++, but the actual language is not; instead, the C++ language is
defined independently of C.

 

[Mike Wahler]

Since you can write programs in strict C in C++

(the whole C89
standard is quite accepted),

Not true.

and even if not used by C++
programmers, C is still in the specs of C++,

Parts of it, not all.

so any C
vulnerabilities are in C++ also.

Some are, others are not.

-Mike

 

[Mike Wahler]

C++ accepts most of the C89 syntax.

But that equivalent syntax does not always have the same semantics.

-Mike

 

[Dan Pop]

I do not pretend that my first example compiles. The second does
however: here it is again:

Even if it compiles, this doesn't make it legal.

#include <stdio.h>
void memset(char * p,int s,int b)
{
while (b--)
*p++ = s;
}

Being in a different namespace, I guess C++ allows using the memset
function name like this, but I could be wrong.

void main(void)

From the C++ standard:

2 An implementation shall not predefine the main function. This func-
tion shall not be overloaded. It shall have a return type of type
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
int, but otherwise its type is implementation-defined.
^^^

{
char p[2];

memset(p,0,123546);
printf("not reached \n");
}

Will you pretend that this is not legal C++?

g++ certainly does:

fangorn:~/tmp 88> cat test.c
void main(void) { }
fangorn:~/tmp 89> g++ test.c
test.c:1: error: `main' must return `int'

It compiles perfectly and crashes as it should.

If your C++ compiler doesn't even warn about it, ask for a refund.
Note that a "shall" requires a diagnostic when violated, in the C++
standard (unless the standard explicitly says otherwise).

Dan

 

[jacob navia]

Jacob's comment above, "the whole C89 standard is quite accepted" can
reasonably be read as an incorrect assertion that C++ is a strict
superset of C, thus this whole tedious subthread. I presume this is a
result of Jacob expressing himself imperfectly (which all of us do
from time to time) rather than an actual misunderstanding on his part.

In the literature, the distinction is not done at all.
For instance, one of the most complete papers about this subject
"Code injection in C and C++: A survey of vulenrabilities and
Countermeasures" by Younan, Joosen and Piessens makes no
distinction at all between C or C++ (July 2004)
Url:
http://www.cs.kuleuven.ac.be/publicaties/rapporten/cw/CW386.pdf

Books in secure programming do the same thing: "Writing secure code"
by Michael Howard and Daniel LeBlanc, lists "C and C++" in the
index, and all vulnerabilities listed are under the topic
"C and C++".

Yes, if you write:

int new = 7;

it will not compile in C++. But I said "*most*" of C89 is accepted
not *all*. This examples are trivial.

It would be nice if we would discuss more centered in the subject
matter, (in this case vulnerabilities) and stop the polemic.

It is a very interesting subject. The article above is a very
detailed description of the problems and possible solutions.

Recommended.

jacob

 

[jacob navia]

void main(void)

^^^^
Now why in the world would *you* post something so ridiculous?

{
char p[2];

memset(p,0,123546);
printf("not reached \n");
}

Will you pretend that this is not legal C++?
It compiles perfectly and crashes as it should.

There's no "should" involved with undefined behavior.

Well, this is C++, not C. I got used to main returning
automatically zero and forgot to assign the result.
The compiler complained and say I should use void
instead, what I did.