Holes discovered in SSL certificate validation

Posted Nov 1, 2012 21:18 UTC (Thu) by zlynx (guest, #2285)
In reply to: Holes discovered in SSL certificate validation by zmower
Parent article: Holes discovered in SSL certificate validation

c++ introduced strongly typed enums. These are great. In the cURL SSL example it could be implemented with an enum named something like SSL_HOST_VERIFY_ON = 2. That value could then never be implicitly set by an integer, a boolean or anything except an enum of the right type.

Unfortunately we cannot go back in time to add features to old versions of C.

to post comments

Holes discovered in SSL certificate validation

Posted Nov 2, 2012 7:21 UTC (Fri) by cmccabe (guest, #60281) [Link] (4 responses)

I'm glad that C++ finally introduced a version of enums that doesn't decay to ints. I probably will use that in the future if I'm writing C++0x code.

Still, I feel that it is unfair for you to criticize C for containing the bug referenced by the poster. C doesn't have a bool type, so there is no way that anyone could pass 'true' in a place where an enum was expected.

In my experience, C++'s addition of bool was not a good idea. The fact that any type of pointer implicitly converts to bool is the source of much hilarity when novices try to write C++ code. That problem does not exist in C because the numeric types there never implicitly convert to pointers.

Holes discovered in SSL certificate validation

Posted Nov 2, 2012 18:07 UTC (Fri) by zlynx (guest, #2285) [Link] (3 responses)

No, C does not have a boolean type. That doesn't change much though because pointers do get treated as boolean values.

It is very common to write if(pointer) { use(pointer); } in C code. That is a pointer being used as a boolean.

I think that you must have gotten confused about the pointer conversions somewhere. There aren't any cases in any version of C or C++ where a numeric type converts into a pointer silently.

Holes discovered in SSL certificate validation

Posted Nov 2, 2012 22:00 UTC (Fri) by nix (subscriber, #2304) [Link] (1 responses)

There aren't any cases in any version of C or C++ where a numeric type converts into a pointer silently.

Um, 0 in pointer context is the null pointer constant. (Sure, it doesn't apply to any other values of integral type, but still.)

Holes discovered in SSL certificate validation

Posted Nov 3, 2012 1:14 UTC (Sat) by nybble41 (subscriber, #55106) [Link]

>> There aren't any cases in any version of C or C++ where a numeric type converts into a pointer silently.
> Um, 0 in pointer context is the null pointer constant.

It's not just the value; in C99, at least, only an _integer constant expression_ with the value zero, or the same cast to (void*), can be implicitly converted to a null pointer. Any other expression with numeric type will not be implicitly treated as a null pointer, even if the value happens to be zero. GCC treats this as an integer-to-pointer conversion without a cast and generates a warning by default.

Granted, "false" from <stdbool.h> is a macro defined as the integer constant 0, so it can be converted to a null pointer. However, the null pointer is treated as false in a boolean context, so that isn't so very surprising.

Holes discovered in SSL certificate validation

Posted Nov 11, 2012 18:41 UTC (Sun) by cmccabe (guest, #60281) [Link]

Here is an example.

> #include <stdio.h>
> void dostuff(bool foo) {
> printf("foo = %d\n", foo);
> }
> int main(int argc, char **argv) {
> dostuff(argv);
> }

Compiles with no errors on -Wall, produces "foo = 1"

Change the bool to int and you get:

example.c: In function ‘main’:
example.c:6:3: warning: passing argument 1 of ‘dostuff’ makes integer from pointer without a cast [enabled by default]
example.c:2:6: note: expected ‘int’ but argument is of type ‘char **’

Conclusion: the C method is safer than the C++ method.

Start combining this with things like function overloading and default parameters, and what little type safety you had tends to evaporate. Take it from a C++ programmer for many years.