CGI.pm FUD

My admin claims that Buqtraq says there are vunerabilities in CGI.pm's handling of file uploads.

To test this theory, I searched buqtraq for such advisories. I found reports of problems with IE, PHP, and an older version of CGI-Lite.pm. Nothing for CGI.pm, which is what I would expect given the module's author and his other works.

Is there a problem or a risk, if you use taint mode and don't allow the user to choose where the uploaded file gets saved?

Update: Thanks for the replies. I need ammunition. I believe CGI.pm is trustworthy, but my admin is convinced that it's got problems, even though he can't provide details about the advisories he seen that argue against it. I think he's talking about the CGI-Lite report, personally, but...

How can I lead this horse to logic *and* make him think. And, yes, I know the old cliche. Put more nicely, please help me combat the FUD.

Also, Chris, I know enough about CGI programming to do something like this:

#! /usr/bin/perl -wT
use strict;
$|++;

use CGI;
my $query = CGI->new();
# ...and so on...
[download]

Unfortunately, my admin has an issue of misinformation and I don't know how to counter those args. Looking for reassurance from a community he appears to respect.

Comment on CGI.pm FUD Download Code

Replies are listed 'Best First'.
(jcwren) Re: CGI.pm FUD by jcwren (Prior) on Feb 15, 2001 at 10:54 UTC
There has been several discussions in the past about convincing management that CPAN modules are trustworthy, reliable, etc. Alas, unlike link master tilly, I can't rapidly give you a pointer to these nodes. As your title so aptly uses, FUD is difficult to overcome, especially engineer to management (vs engineer to engineer). Ovid had a major problem with his boss trying to write everything in house, and introducing a really trashed CGI argument processor. Possibly, your best argument may be that anything that you (that being either you personally, your team, your department, or your company) can write is going to be far worse than any conceivable perceived holes in CGI.pm. If you can't use CGI.pm, how is he proposing that you achieve the goal? --Chris e-mail jcwren	[reply]
(jcwren) Re: CGI.pm FUD by jcwren (Prior) on Feb 15, 2001 at 08:15 UTC
I don't know how much you know about CGI programming and file uploads, but in any case you might check out our own Ovid's CGI tutorial. He addresses security concerns, and things to watch out for. --Chris e-mail jcwren	[reply]
Re: CGI.pm FUD by extremely (Priest) on Feb 15, 2001 at 22:16 UTC
There are a few things you need to do for any fileupload system to protect yourself. Luckily, if you look hard enough you will find that CGI supports them fairly well. One, with any file creation done by a web script, you need to carefully deal with tempfile creation and filenames. Two, you need to limit the maximum upload size. See these posts: File Upload Security Question; Security question; File Upload + recording "metadata"; How to limit upload file size?; and of course the now epic use CGI or die;. -- $you = new YOU; honk() if $you->love(perl)	[reply]
Re: CGI.pm FUD by salvadors (Pilgrim) on Feb 15, 2001 at 23:18 UTC
Actually, Lincoln's own page for CGI.pm lists information on countering possible DoS attacks via CGI.pm, including file uploads: Another possible attack is for the remote user to force CGI.pm to accept a huge file upload. CGI.pm will accept the upload and store it in a temporary directory even if your script doesn't expect to receive an uploaded file. CGI.pm will delete the file automatically when it terminates, but in the meantime the remote user may have filled up the server's disk space, causing problems for other programs. Tony	[reply]
Re: CGI.pm FUD by dws (Chancellor) on Feb 15, 2001 at 05:19 UTC
Other than needing to untaint target filenames, I'm not aware of any vulnerabilities, nor did I come across any when I did a search a while back. Don't take that as proof, but then again, you're trying to prove a negative.	[reply]