Holes discovered in SSL certificate validation

Posted Nov 1, 2012 12:42 UTC (Thu) by zmower (subscriber, #3005)
Parent article: Holes discovered in SSL certificate validation

Amazon's Flexible Payments Service PHP library attempts to enable hostname verification by setting cURL's CURLOPT_SSL_VERIFYHOST parameter to true. Unfortunately, the correct, default value of this parameter is 2; setting it to true silently changes it to 1 and disables certificate validation. PayPal Payments Standard PHP library introduced the same bug when updating a previous, broken implementation.

As an Ada programmer, I laughed hard at this. Static typing FTW!

Holes discovered in SSL certificate validation

Posted Nov 1, 2012 15:00 UTC (Thu) by intgr (subscriber, #39733) [Link] (14 responses)

> Static typing FTW!

This vulnerability doesn't come from the lack of static typing, it comes from implicit type conversions (sometimes called "weak typing"). There are statically typed languages that allow implicit conversions from boolean to integer, such as C++, which could very well have the same vulnerability.

People frequently try to discredit dynamic typing with claims like "PHP uses dynamic typing. PHP makes it hard to write secure code. Therefore dynamic typing is insecure."

But the most problematic behaviors in PHP -- implicit conversion from strings to numbers, arrays to strings etc -- are not present in other dynamic languages like Python, Ruby and cause an exception to be thrown. And the conversion semantics are far less problematic even in JavaScript.

Holes discovered in SSL certificate validation

Posted Nov 1, 2012 17:15 UTC (Thu) by zmower (subscriber, #3005) [Link] (12 responses)

As an Ada programmer my static typing is implictly strong. ;) Don't get me started on C++...

Dynamic languages are OK if you want to get somewhere fast. I'll gladly use python to read the GPIO pins on my rpi. But I'd refuse to get on a plane where the control systems relied on it! (Not that all Ada software is well designed, written and tested but I can dream.)

Holes discovered in SSL certificate validation

Posted Nov 1, 2012 21:18 UTC (Thu) by zlynx (guest, #2285) [Link] (5 responses)

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.

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.

Holes discovered in SSL certificate validation

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

I thought Ada programmers were all hunted to extinction in the Reagan administration. How did you survive?

Holes discovered in SSL certificate validation

Posted Nov 2, 2012 12:25 UTC (Fri) by pflugstad (subscriber, #224) [Link] (4 responses)

Having seen some of the Ada code that makes up a flight management system (not controls, but still responsible for important stuff like flight speed indicators and other displays), I can easily say that it was as bad as any other language. Ada may be strongly typed, but that doesn't make bad programmers any better. And bad programmers create bad code in ANY language.

Holes discovered in SSL certificate validation

Posted Nov 3, 2012 10:26 UTC (Sat) by brouhaha (subscriber, #1698) [Link]

Certainly it's possible to write bad code in any language, and that's what usually happens. (Consequence of Sturgeon's Law?) However, that doesn't mean that choosing a language with better semantics (such as strong typing) won't dramatically reduce the occurrence of certain kinds of bugs.

IMHO, C doesn't even qualify as a high-level language. C++ perhaps does, but being nearly a superset of C, has basically all of the problems of C, plus some new ones. Javascript... don't even get me started on that one.

I was an Ada enthusiast many years ago, but haven't kept up with it because there's so little paying Ada work available. If I could find the time, I'd like to learn Scala. However, the work I can find is almost entirely C, C++, and Java.

Holes discovered in SSL certificate validation

Posted Nov 3, 2012 21:36 UTC (Sat) by dvdeug (subscriber, #10998) [Link] (2 responses)

I get the feeling that some drivers drive around cars that don't have mirrors; I mean, a bad driver can crash any car, so why do you need these things that make it easier not to crash the car?

Holes discovered in SSL certificate validation

Posted Nov 4, 2012 0:48 UTC (Sun) by pflugstad (subscriber, #224) [Link] (1 responses)

Just to be clear, I like strong typing as much as the next guy. I think it's one of the primary ways to show how you expect various types of variables to be used, which is one of the primary ways you reduce bugs.

But I've seen BAD Ada code - in safety serious situations. I've also seen really bad C & C++ code, where *attempting* to make the code strongly typed actually made the code worse. For example:

if ( classInstance == MANIFEST_CONSTANT )

the classInstance had an int operator(), so the compiler implicitly called that, and everything was fine. But because lint complained about different types, we ended up with:

if ( classInstance == (ClassType)MANIFEST_CONSTANT )

This instantiated a new instance of ClassType on the stack and then invoked operator==. This happened in 100's of places. And it even worked - until it ran out of stack. This was actually fairly painful to track down.

So - a fool with a (bad) tool is the main lesson here, but the tool is attempting to enforce strong typing, and the programmer blindly followed it.

I've seen similar stupidities in Ada code, so it doesn't save you any.

My point (I think) is that bad programmers easily trump strongly typed languages. It *might* lesson the problem - marginally. But in my experience, you OFTEN get the kind of stupidity I describe above, especially when development processes BLINDLY mandate running lint on your code and fixing all the warnings.

So I don't look to strongly typed languages as any kind of panacea. You can type silly things like converting a boolean to a 1 even there. You want good code: hire good, experienced programmers, and make them test their code.

On topic: I've tried to program against SSL's APIs. I totally agree with the article - they are HORRIFIC and I was just trying to do something trivial, nothing difficult like certificate verification.

Holes discovered in SSL certificate validation

Posted Nov 4, 2012 17:20 UTC (Sun) by mathstuf (subscriber, #69389) [Link]

> But I've seen BAD Ada code - in safety serious situations. I've also seen really bad C & C++ code, where *attempting* to make the code strongly typed actually made the code worse. For example:

This is just an instance of fast-and-loose type casting (which is one of the major problems with languages like PHP and JS) in C++, so I don't think your example is saying anything spectacular about C or C++. Same sheep, different wool.

> So I don't look to strongly typed languages as any kind of panacea. You can type silly things like converting a boolean to a 1 even there.

They're not a panacea, but they certain do help. At least in Haskell, such things either involve "unsafe" in the function name or start putting the IO monad all through your code. Those are both things I stand out as "something fishy" to me. That casting in the example would be a red flag for me as well. Casting constants, especially if it's an enum (and you're not in some dark corner of the project dealing with marshalling between languages or the network) is a pretty bad code smell.

> You want good code: hire good, experienced programmers, and make them test their code.

Agreed.

Holes discovered in SSL certificate validation

Posted Nov 5, 2012 2:31 UTC (Mon) by wblew (subscriber, #39088) [Link]

Strongly static types languages refuse to perform implicit conversion.

To be blunt, C, and thus C++'s, implicit type conversion is at the root of plenty of exploitable security defects.