Karthik, it's understandable that anyone seeing this would be tempted to panic. It's complicated whether you need to be concerned about this or not. Let me explain.
1) First, as for that folder and those files, many are unaware that if ANY CFM page is called as a form post that pushes ANY file to it (like with a form with an input type="file", but this can be simulated with http headers directly), then CF will first STORE that uploaded file in that directory. And note how the file name ends with .tmp. Nothing can RUN that file, and even if it has a virus in it, nothing can LEVERAGE or trip over it, at least as it exists in that file. I'll talk in a moment about how that file may (or may not) be caused to be moved OUT of that folder, in which case it MAY be something to be concerned about.
But note note that such a tmp file (created by such an upload to a cfm page) will be REMOVED when the request ends. Again, that means the file may be there momentarily (milliseconds or seconds), but it would then be removed. In fact, if you look now at such folders, you may find the file you refer to is not there....but someone may argue "it was our security protection mechanism that removed it", and that may be so. I'm just saying that ANYONE even WITHOUT such a tool should find that the tmp files don't remain long.
2) So someone would reasonabley ask "so how do they get OUT of that folder to be used legitimately by CF?" That's where the cffile action="upload" comes into play; if a CF page is EXPECTING to have files uploaded to it (like via a form with an input type="file"), then THAT cf page would use that cffile action="upload" with a DESTINATION attribute naming a folder used by the app, which tells CF to MOVE that .tmp file (just uploaded) into that named folder. That process ALSO renames the file to whatever name and extension it was when uploaded (from this neotmp*.tmp name). Again, in the end, the .tmp file itself would no longer be there in that tmp folder.
And to be clear, if a cfm page gets a file uploaded to it but does NOT do that cffile action="upload", then the uploaded file is NOT processed by CF (at all) and again it's simply deleted at the end of the request.
3) But someone may argue, "ok, but what if the CF code DOES do a cffile action="upload". Won't that put the file with a virus somewhere?" Yes, it could.
We should note first that cffile action="upload" tag does itself offer attributes to control what CAN be uploaded. More than that, the CF Admin ALSO has various protection mechanisms built into processing of such uploads (but it doesn't "check for viruses"). These features can limit what file extensions are allowed--and also whether the kind of file uploaded matches the extension (and "mime type" indicated) for the file that was uploaded. See the docs for more on that.
4) Now, if your code WOULD have just processed that uploaded file (with cffile action="upload") and WOULD have put it in some folder, then yes it's possible somehow a file with a virus could end up in your server (and perhaps even in a web accessible directory.) To that point, some people have such uploaded files get moved (by their cf code) into a directory where then they perform some external a/v check, before putting it wherever it was ultimately intended to be placed.
5) But your tool is doing that checking BEFORE your CF code even might try to move the file out of that tmp folder. And I'm saying it may be that such uploaded files are not put there as part of an intentional process where a CF page WOULD have moved it out of there. Instead, those could just be uploads to a CF page which NEVER would have done anything with the file. And your mechanism is basically a dog howling at the moon (nothing to be worried about).
But bottom line: there's virtually nothing you can do to PREVENT file uploads to CF (even if your code has no intention to ever DO anything with such uploads). But again if you do NOT do anything with them, they just are removed at the end of the request that received the upload. You should find that you don't have many of that neotmp*.tmp name in that directory , cfusion\runtime\work\Catalina\localhost\tmp.
And even if somehow you do find them, and they go back hours days or weeks, it would be because the CF file to which the upload was pushed had died unexpectedly, so that CF did not do the end of request removal of the tmp file. Even so, again those tmp files there DO NOTHING. They CANNOT be "executed" in any way by CF, even if they "have a virus" in them. They are .tmp files. Nothing will execute them. You can just delete them and get on with life.
6) I realize that some will wish for a better answer to "prevent the uploads being possible in the first place, if we would NEVER have any need to handle such uploads to ANY cf files".
While CF has no feature to do that, I will say that your web server (IIS or Apache) may offer features to block such file uploads. It may even be possible to tweak Tomcat (which underlies CF) to prevent such file uploads. That just shows you that this ability of a file to receive a file upload (posting a file) to a server is not somehow unique to CF. Other languages and app servers support it as well.
What CF offers is whether and how to process that file once uploaded (see above), and it deletes the file if not used (see above). But your a/v or security tool is possibly seeing the file in the moments that it's uploaded. That's why you either need to let it do its job (if its removing them) OR you need to explore how to tell your web server to NOT allow file uploads to CF at all. If you seek that, speak up and I or others may chime in.
7) I warned that this was not a simple problem with a simple answer. I hope the clarifications above are useful for you or others who may find this thread in the future.
... View more
AdChoices