On Tue, 1 Dec 1998, Gurjeet Clair wrote:
> Today I saw <Michael Gerdts> say:
>
> > On November 11 I reported the folloing problmes to ewsbugsat_private I
> > have only recieved an automated reply.
Hmmmmm.....
>
> sub make_files_readwriteable {
> local($files) = @_;
> return 1 if ($ews_port eq 'NT');
> return system("/bin/chmod a+rw $files"); <---- EVIL!
> }
>
> Ahh, theres the litte culprit right there! The "chmod a+rw $files". Well
> one fix is to use "chmod 0600 $file" (i think u+rw) OR not use the system call
The problem (I think) is that user data ($files) is allowed to be parsed
by the shell before /bin/chmod touches it. This is dangerous, since they
can make $files be something like "filename; some command here" or even
"`some command here`". Under sh or bash, "some command here" _would_ get
run as the user the webserver is running as..... I could be mistaken,
though, as I haven't looked at the rest of the source. This kind of thing
would be OK if all non-alphanumeric, non-period, and non-dash characters
were filtered out using tr or some such.
> itself and use the built in perl functions to set permissions. Of course this
> only creates the permissions as the user that the webserver runs as.
I question why the author didn't just use the Perl builtin function
chmod().... Or, system with the fields separated by commas:
system "/bin/chmod", "a+rw", $files; # This would be OK since it
# doesn't use sh.
At any rate, why was the file being made world writable anyway?
Andrew
--
"The wonderful thing about standards is that there are so
many to choose from."
(Andrew S. Tanenbaum)
-------------------------------------------------------------
Andrew Pitman MIS
Unix System Administrator Rowan University
-------------------------------------------------------------
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:24:28 PDT