Daniel Bernstein: ten years of qmail security

Hrm. My experience is severely limited:

"Dynamicly typed" always ment to me that the type is determined when the variable is created,
based on various rules. That is variable types do not have to be declared before you can use
them. (although they can be if you prefer it)

The opposite is "staticly typed" were you have to declare variables types before using them.


And "Strongly Typed" has always ment, to me, that once the variable is created then it can't
be changed. That is if you create a variable as a int you can only use it as a int. If you
want to use the int's value as a string you have to create a second string variable. The type
is enforced by the language.

The opposite of that is "weakly typed" were a int can be a string can be a float based on the
context in which it's used. That is if you make a 'int' you can use as a string if you feel
like it. The type is not enforced by the language.


So...

C == staticly, weakly typed
Perl == dynamicly, weakly typed
Java == staticly, strongly typed
Python == dynamicly, strongly typed


For example this is not legal in python:

a = "1" + 1

The "" is your way of declaring that value as a string, otherwise numbers by themselves are
always interpreted as int, hex, float, and other numeric types.

But, of course, none of this is hard and fast. Between numeric operators it'll do type
coercion.

a = 0x45 + 1.0 + 12
(so that is a hex + a float + a int)
And the result would 'a' be a float.

Or this could be a bit of a illusion as all these things support the 'add' function. I don't
know.


Maybe this is because my knowledge of all this stuff is purely from a python perspective and
the language that is used is to try to help programmers understand the differences between
other common languages.


But otherwise thanks for the clarification on the "But isn't that example of 'dynamicly
typed'?" That makes a lot of sense.

Yes, it certainly has. But more or less all of those can be summarized by "altering the return
address", often in combination with injecting malicious instructions. Compiling programs with
-fstack-protection helps against that, as does random address layout and non-executable
stacks/heaps. So the problem looks worse than it is, because e.g. every buffer overflow is
flagged as a security breach, while in practice it might be near impossible to actually
exploit it.

You might also be interested in the -fmudflap option, but I don't know anything about it. Same
for -ftrapv which causes the program to abort when a signed integer overflows. I tried it, and
it works, but not when optimization is enabled. :-/

And those lowlevel errors distract from the higher level security problems in  applications,
which are more often than not language independent. It's incredible how many unsafe temp file
handling bugs are still found, to name one thing. It's true that many libc functions aren't
very security friendly (e.g. strncat), but by now people should know that and use the safer
alternatives.

The compiler could do much more compiletime checking too, and there are some options to enable
checking a few things, but more could be done. For runtime checking Valgrind is great. The
weak typing of C isn't as big a problem as it could be thanks to compiler warnings.

Only thing I use a debugger for is to get backtraces. And the reason you need a debugger for
that in C and not in some others is because in interpreted languages the backtrace is
generated by the virtual machine.

I really hate PHP, let's not go near there. Any language where mistyping a variable name
causes weird buggy behaviour instead of a (compiletime) error is not worth existing. Weak
typing combined with automatic variable declaration/memory handling is just a nightmare.

No, the OpenBSD people are so close to absolutely correct that it's not worth calling the
difference. Bugs cause something unexpected to happen. If unexpected things happening was
acceptable then you wouldn't bother with security, just say "That was unexpected" when
anything bad happens.

Here's a nice simple example. You have a program which examines NTFS formatted hard disks to
check that everything on the disk is authorised by the company. The program is pretty simple,
but it has a small bug.

The bug is that it assumes all NTFS filenames are Unicode strings. This seems like a
reasonable assumption, because most likely every NTFS filename you've ever seen was a Unicode
string, and all the files you tested with have such names, there isn't any way to "type in"
anything except Unicode strings as the name for a new file in Explorer or Word or similar
software, so why would you assume anything else?

But now you've created an incentive to construct files with non-Unicode names. Perhaps the
code sequence 0xFFFF 0xFFFE 0xFEFF 0xFFFF would be a good name for a file. Your buggy software
cannot convert this into a Unicode string, so it ends up in an exception handler that you
never realised could be called under such circumstances. The exception handler normally fires
when a file has been deleted before it can be examined, so it just tidies up and moves on to
the next file. So now the magic file is invisible to your software and you have a security
breach.

There are billions of assumptions like this, regardless of whether you're programming in LISP
or Fortran, and if any of them are wrong in a security sensitive application the security
probably doesn't work. Worse, the only people likely to find out have an incentive not to tell
you. That's why security is actually hard, although you wouldn't think it from all the Mickey
Mouse security consultants and 3rd rate security software.

Oh and yes, it turns out that although the Win32 APIs don't believe in files with non-Unicode
names, the underlying NT kernel, like the Linux kernel, considers them all to just be opaque
identifiers. Don't laugh too loud at the programmer who wrote one byte too many into an array,
you'll have your own foot in your mouth soon enough.

> Ehm, my C is a little rusty, but no :D I rather meant null pointer dereference, double
dereference or whatever other strange things are allowed in C that lead to security problems.

If a program attempts to dereference a NULL pointer, the program will be terminated
immediately with a SIGSEGV signal. This does not allow arbitrary code to be executed. A double
dereference is a perfectly normal and desirable condition in many programs, and the compiler
will catch double-vs-single pointer mismatches at compile time.

> Of course not, but I much rather prefer a NullPointerException than an undesired intrusion. 

Again, there is no way for a NULL pointer dereference to facilitate an intrusion since the
program will segfault instead of executing arbitrary code. 

If you read my previous post, I'm not baffled by that. My original point was that moving those
people to something else like Java only produces buggy Java code instead and doesn't solve the
problem of buggy code. You could even say that C has an advantage here because their code
won't work in the first place and would crash all over the place. ;-)

All right, that's perhaps a step too far, but it is indeed easier to make a big mess in C.
With Java you get "works for me, bug must be in your part"-code.