|
Vulnerability IMP Affected Any supported by IMP, MSWordView Description Jose Nazario found following. IMP is a PHP3 driven webmail solution providing full featured access to email. MSWordView is an application that translates MicroSoft Word documents into HTML. Used in conjunction users can view their Word document attachments online without having to download them. Two problems have been found in this setup, though, that warrant attention. The first problem is the permissions left on the temporary file used by MSWordView to format the document in HTML. They are left world readable, possibly exposing private information to the world: /tmp: -rw-r--r-- 1 nobody nogroup 13722 Mar 8 17:28 imp.word.2000-Mar-Wed_17:27:47__a986f65efecd5fd49e75b3d7f8312721.html The second is a failure if the IMP process to clean up properly if the MSWordView process does not exit correctly. It leaves files on the server which will fill up the /tmp filesystem. Should enough accumulate, a denial of service is possible due to a lack of disk space. This improper exit can occur should the user stop the attachment viewing before completion or if there is a problem in the setup. Exploiting this is simply a matter of sending one's self several large Word documents as attachments, starting to load them in IMP to view them online and stopping the loading. Disk space will deplete and the server will cease operations soon enough. Note that shell access is required to exploit this information leak. Still, quite a number of servers exist in the world which mix shell and webmail access, for which this would be a problem. Solution The first problem has been fixed in the 2.2 beta versions of IMP. As of version -pre11, released on 10 April, 2000, the umask is set correctly as 077 and the files are no longer accessible by the rest of the community. IMP administrators who are leary of using beta software may wish to simply work around this problem in IMP 2.0.11. In the file imp/lib/mimetypes.lib there is the function that is used by MSWordView which creates the temporary file. Simple create a directory that is 700 for nobody.nogroup (or whoever runs the web daemon process) and use that directory, rather than /tmp, for temporary storage. The second problem at this time has no fix, though a simple cron job that removes temporary IMP files that are more than 30 minutes should work or monitors IMP's temporary storage space and reacts similarily. This time should be adjusted depending on the number of users on the server and the size of the temporary space. An account is required to abuse this problem.