Generally, are setuid programs more secure in C than in Perl?
Generally, with a whole lot of caveats and provisos in mind, Perl scripts are more secure than C scripts. The basic reasoning is as follows:
The main source of compromises comes about through buffer overflows. You might have the following line of code in C:
char password[32];
... because no-one has passwords longer than 32 characters, right? Crackers will force arbitrarily long strings into this variable to see what happens. With a bit of luck they'll clobber the return frame on the stack, and if the string is crafted just so, they'll succeed in getting the program to jump to a completely unrelated area of memory that just so happens to contain a bunch of machine instructions that they placed there beforehand. Bingo! you are 0wn3d.
This is much harder to do in Perl, because scalar variables don't have a built-in notion of maximum length. A scalar will just keep growing as required. You can't overflow them, bar exhausting virtual machine memory.
Yes, this is avoidable in C, but it is hard to do right.
More sorts of trickery can be performed by diddling with pointers. In Perl you can't just write something like:
my $x = 'SCALAR(0x8101730)';
... and magically expect to start peering at some odd corner of memory. Since you're one level of abstraction away from the machine, it's harder to break into it.
And plus, as you appear to be doing in your example, taint mode helps look after details that you might forget about. The truly paranoid would also audit every single line of each module used, whether it be part of the core distribution or stuff you installed from CPAN.
_____________________________________________
Come to YAPC::Europe 2003 in Paris, 23-25 July 2003.
In reply to Re: setuid: Perl v C
by grinder
in thread setuid: Perl v C
by eyepopslikeamosquito
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |