neat summary Joey :)
The reason that I made it world writeable, is that twiki cgi's can be
run from the command line by anyone, and in doing so, create a session
file.
This is used by cronjobs, and so that users can script additions to
topics etc.
Basically, like much of the rest of TWiki, its security is a crock :(
Do you have any suggestions (other than re-writing TWiki?) or should I
just disable that funcionality and run away?
Sven
On Tue, 2007-10-23 at 16:45 -0400, Joey Hess wrote:
> Sven Dowideit wrote:
> > the working/tmp dir is used for rcs tmp files, and twiki session files,
> > both of which use randomised unique filenames.
>
> rcs opens its temp files with O_EXCL, so I don't think it will be vulnerable
> to symlink attacks.
>
> In twiki 4.1.2, I quickly found some temp file problems.
>
> ./lib/TWiki/Client.pm: open( IPMAP, '>',
> $TWiki::cfg{TempfileDir}.'/ip2sid') ||
>
> Trivial to exploit if you can write to $TWiki::cfg{TempfileDir}.
>
> ./lib/TWiki.pm: my $passthruFilename = $TWiki::cfg{TempfileDir} .
> '/passthru_' . $uid;
> ./lib/TWiki.pm: open(F, ">$passthruFilename") || die "{TempfileDir} cache
> not writable $!";
>
> This $uid md5sum would be hard to guess. I still don't consider this
> code fully secure from temp file attacks since it does not use O_EXCL.
>
>
> I have not done a complete audit. Writing temp files to a 777 directory
> scares me. What if another user deletes the temp file (since the directory
> is not +t, anyone can)? What if a user deletes a temp file and replaces
> the data in it with other data, which is then read back in? (For example,
> the passthru_ file above is later read back in by another instance of twiki.)
> Could a buffer overflow, malicious data, or incorrect data be substituted in
> this way and used to attack twiki or rcs? Rather than trying to answer these
> questions, I'd recommend tightening the temp directory permissions.
>
--
Professional Wiki Innovation and Support
Sven Dowideit - http://DistributedINFORMATION.com
A WikiRing Partner http://wikiring.com
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
