From the looks of things, Paul is trying to pull a Dick Hardt with his talk. If you've ever seen Dick's Identity 2.0 talk you'll know that this tutorial is going to be virtually un-bloggable...
Update: First pointer is to his own
autodiemodule, which was released onto CPAN (very) late last night. It's a lexical equivalent of
Fatalfor Perl 5.10, it also upgrades the
Fatalmodule to contain better diagnostics and reporting.
Update: Paul is talking about exposing vulnerabilities in CGI code, and trying to emphasize that you must validate your input data, from users, from files and very much from the network. You need to use taint mode. He's also recommending that you don't use "baby taint" mode and call Perl with
You may not use data derived from outside your program to affect something else outside your program - at least, not by accident. - perlsec
Update: Interesting he's just shown a three line example that will allow you to get root access by running any Perl script that respects the
Update: But there are problems with taint mode
If the regular expression match formy ($url, $file) = @ARGV;
$url =~ m/ pattern match /;
my $safe_url - $1;
$file =~ / pattern match /;
my $safe_file = $1;
$safe_fileis set to
$safe_urland that could easily be set to something like
http://foo&/bin/sh, which would be bad. You always need to check for success, either use an
if( )block or by explicitly check the return value from the regular expression.
Update: One of the things that Perl is good for is making tasks easy. One of those things is opening a file. There are lots of ways to open files in Perl, which means there are lots of way to break things. If you are opening a file you should always specify a mode, and never use the two argument version of
openwhich does much deep magic. Use the three argument version instead.
However this doesn't get you out of validating your input, you still need to do that...open($fh, "<", $filename );
Update: Symbolic links (are awesome but) can be used to do evil things. Don't use temporary files with predictable names, you could even use anonymous files
use autodie qw(open);
open($fh, "+>", undef );
or you could just use the Tim's
Update: Now talking about
systemand back ticks, Paul really hates
system. You really need to use the two argument version of
systemrather than the one argument version, except of course
@args = ();
system( $cmd, @args );
@argsis empty, then it calls the one argument version of
system, which in turn calls the shell rather than executes the passed command directly. Which means that you can this happens,
system ( "finger $username; rm -rf *", ( ) );
which is rather bad.
Back ticks are worse; "this" is a string, 'this' is a string and `this` is executing arbitrary code on your system. Depending on your font, it's rather hard to tell the difference.
The alternative is
IPC::System::Simple, which works all the way back to Pelr 5.6 and (magically) doesn't have any dependencies. Which from the sounds of it goes a long way to fixing a lot of the problems with
system. It also provides
capturewhich replaces back ticks.
Update: We're breaking for afternoon coffee...
Update: ...and we're back and talking about
setgidprograms. Apparently Perl is ignorant of the saved uid, which means that it's really hard to drop privileges and make it stick. Also a dark secret, Perl's
$>variables are cached. Ouch!
Update: On to database security and injection attacks. He's advising us not to do our own quoting and use instead use place holders. As I've mentioned before, I rarely have to do heavy weight database work, and I'd view my knowledge of DBI as only fairly sparse, and even I know about place holders. Why does everyone think they're worth talking about at length. Bemusing!
Update: On to tricks and tips... and the poisoned null byte. Strings in Perl (are awesome but) can contain any character you want, including control codes and null bytes. In Perl a null byte is just another character, but in C it represents the end of a string. So if you can get a null byte down to the C layer, bad things can happen, and it's easy to pass a null byte can be easily passed in URLs.
Update: ...and we're done (with the main material) about an hour ahead of time. The course notes, although not the slides, for the tutorial are available online. On to the 'bonus' material, random numbers and cryptography...
Update: ...we're done. Now go read Brad's and Chris' posts on the Perl Security tutorial as well.