|
Posted by terminlman on January 29, 2007, 12:57 pm
Please log in for more thread options
In File::Remote, the actual call (in my case to scp) is made by this
routine.
sub _system {
my($self, @cmd) = _self_or_default(@_);
# return "Broken pipe" if cmd invalid
chomp(my $return = `@cmd 2>&1 1>/dev/null || echo 32`);
_debug("_system(@cmd) = $return");
if ($return) {
# if echo'ed an int (internal tests), use it, else use
"Permission denied" (13)
$return =~ m/^(\d+)$/;
$! = $1 || 13;
return undef;
}
return 1;
}
When the call succeeds, all is well. However, if it fails, is there
any obvious reason why it would always use Permission Denied (13)
instead of returning the actual error returned by the call? If I
follow this correctly, then if the actual call to the command in @cmd
fails, $result will contain whatever @cmd put out to stderr, plus a
line with 32, but the return code ($?) will still be 0. The only way
I see for $1 to get something (ignoring any previous matches) was if
@cmd writes an integet to stderr, but exits with 0.
Am I missing something?
|
|
Posted by Andy on January 30, 2007, 3:18 pm
Please log in for more thread options
A hacker can use File::Remote to create programs on somebody else's
server, such as a webserver. If the errors generated by improper use
of File::Remote (ie such as writing into directories that aren't
there) are passed back to the hacker, they can use this information to
infer the directory structure on the remote computer, what type of
server it is, and even gain access to account directories.
To protect against this, it is common practice to replace any returned
errors with a general "permission denied" or "an error occurred,
contact the administrator" error. This way, even if the hacker
accidently did gain access into the remote computer at a level that
they could write to it, they are less likely to know of their success.
|
|
Posted by Jack on January 30, 2007, 3:37 pm
Please log in for more thread options
If File::Remote is used within the CGI structure of a web site, then
restricting the error messages that get passed back makes sense - but
should that really be the job of File::Remote, or should it be the
job of whatever uses it and then formats the results to surface on the
web page being generated. It's nice to help protect people from
themselves, but I wan't to use this locally - no web involved at all -
so restricting information that would help me figure out what's going
wrong still doesn't make sense to me.
Oh well. I'm just writing a scipt for a very specific purpose (not
web related) so it turns out to be easier just to roll my own
(bacticks and explicitly checking both return value and $?) and not
use the module.
|
|
Posted by Andy on January 31, 2007, 2:26 pm
Please log in for more thread options
You can always customize the code in that module and keep a copy for
yourself. Just comment out the part that moves the "access denied"
code:
ie
$! = $1 || 13; becomes $! = $1 # || 13;
save the code and then do the following commands on the root directory
for the module:
perl Makefile.PL
nmake
nmake test
nmake install
The module should now return the actual error code.
|
| Similar Threads | Posted | | Remote.pm (File::Remote) problem | February 28, 2006, 9:50 pm |
| remote file copy using Net::Telnet | February 3, 2006, 2:02 am |
| SOAP::WSDL error accessing remote site. | July 19, 2007, 3:14 am |
| remote keyboard and mouse IO | February 21, 2005, 3:22 am |
| how to execute command on remote machine | September 21, 2005, 12:40 am |
| Remote install of Perl Module | April 12, 2005, 10:47 am |
| Read user log from a remote host | July 26, 2006, 5:14 am |
| Net::SSH::Perl to connect to a remote server via a web page | August 30, 2004, 10:02 am |
| SOAP::Lite creating remote objects | March 29, 2006, 9:51 am |
| Is there a module that grabs a remote page and prints thumbnail image? | May 26, 2006, 12:09 am |
|
XML Sitemap