Adriaan van Os wrote:
Mirsad Todorovac wrote:
I have recently studied several forms of viruses and security holes in software. Many if not 90% of recent exploits depend on holes introduced through buffer overruns, such as this C example:
printbuffer() { char buffer[100];
gets (buffer); /* oops!*/ fp = fopen("LPT1:", "w"); fputs (buffer, fp);}
Is Pascal and namely GNU Pascal safer re: buffer overruns? How much does runtime range checking help
Yes. In particular, some holes are intentional, either for compatibility with other dialects (pointer-arithmetic etc.), or for performance reasons (possibility to turn off checks).
There are other holes, such as dangling pointers and using unintialized variables, which GPC cannot detect at all yet. It might do in the future, but implementing them will be very hard, so don't hold your breath.
and to what extent can we depend on it?
The only thing you can depend on in programming is clear thinking. Don't trust anything that promises you automatic wonders.
Yes. Though it might help thinking clearly when you don't have to worry about every little detail (such as basically every C-string operation, which can be dangerous if not careful; note, I said C-string, so using C-strings in Pascal is just as dangerous as in C, of course).
Is it acceptable to write setuid root programs in GPC and what are the cautions?
From http://en.wikipedia.org/wiki/Setuid
"While the setuid feature is very useful in many cases, it can however pose a security risk if the setuid attribute is assigned to executable programs that are not carefully designed. Users can exploit vulnerabilities in flawed programs to gain permanent elevated privileges, or unintentionally execute a trojan horse program."
I think "carefully designed" is the keyword (and ask yourself if that applies to the C and C++ programming languages (...)).
Indeed. But apart from the programming language, the same applies to your program as well. Even a perfectly secure programming language and environment don't help if your program, e.g., executes another program carelessly. No amount of string and buffer checking helps if the program allows the name of the program to be executed to be supplied by an attacker, say /bin/sh ...
As for the original question about buffer overruns (only), Pascal in general and GPC in particular should be quite a bit safer than C, *if* you turn on all checks and use only high-level features (this excludes, e.g., the address operator, type-casts, abuse of variant records, low-level routines such as GetMem, Move and FillChar, calls to unsafe external routines (assembler, C, or whatever), and probably much more).
Frank