Re^5: issues displaying cgi script source?

[antirice]

in reply to Re^4: issues displaying cgi script source?
in thread issues displaying cgi script source?

Try this from a directory that contains a subdirectory named review.

my $name = "../broken.pl";
open(FILE, ">review/$name") || die "Can't write to review/$name!\n";
print FILE "Hi";
close FILE;

Notice that it creates a broken.pl in the current directory instead of the subdirectory.

[Elijah]

I have tried that already. As soon as the possible exploit was told to me yesterday I tried to exploit it and could not. The following is the error that gets reported to my error logs.

Can't write to /home/user/webroot/site/htdocs/review/../broken.pl.txt!

As I stated before the permissions on the server will not allow for non-privilaged users to write to this or any other directory in that path. Apache is running as nobody and the parent directory of "review" is owned by me and is not writable by anyone except myself and root.

[antirice]

Alas, there's the rub. You're offering this script for download as well. While it may not work for your machine, it may work elsewhere. Thus I have to say it: fix your damn code!

How do you extract only the file? Glad you asked:

use File::Spec;

my $file = "../this/is/a/problem/file.pl";
$file = (File::Spec->splitpath($file))[2] if $file;
print $file;
__END__
file.pl

[Elijah]

I think you are a bit confused.

The script you are talking about writes to the harddisk and does not read from it so "extracting the file" as you put it in your example is irrelevant. Furthermore both scripts have been fixed for two days now. Lastly I already tried to implement File::Spec two days ago. While I did not use splitpath I did try no_upwards() and this was not feasible for my usage.

The no_upwards method and your method (if it was applied to writing and not reading) both require the script to be able to write to the cgi-bin folder. Now I know you surely cannot be suggesting that! That would be the largest security hole I have heard of to date on this topic. The very nature of the script is it has to run in cgi-bin and write to a directory outside of cgi-bin.

You're offering this script for download as well.

Again you are mistaken, if you are going to give advice make sure you have your facts straight first. I still am not positive what script you are talking about since your first post referenced a script that wrote to the filesystem and you tried to point out a security hole that did not exist in that script and now this post tries to tell me how to fix a read hole in another script that has been fixed for 2 days?

While it may not work for your machine, it may work elsewhere.

The permissions on my machine are default therefore if it were to work on anyone elses machine they would purposely have to change the permission setting to allow all users on the system to be able to write to their home directory. If they did that then they deserve to be taken advantage of.

As I say the security hole you talked about does not exist but I made it more strict anyway.