Getting "Uploads with empty file extensions are not allowed" after ColdFusion 2018 Update 4

[noble6]

Greetings All,

After upgrading to update on ColdFusion 2018 I have been getting an error from cffile stating "Uploads with empty file extensions are not allowed". This has been isolated down in my code to an implementation of plupload which will do large file uploads via chunking.

When inspecting the headers plupload is changing the filename to "blob" which is stripping the file extension.

------WebKitFormBoundaryvA9v8ChjbTSXEt9w

Content-Disposition: form-data; name="file"; filename="blob"

Content-Type: application/octet-stream

Has anyone found a way to disable this check in ColdFusion or at least modify it to allow for the upload of files without extension? I have confirmed it was not present in CF 2018 update 3.

Regards,

[bradwood.com]

Did you find an answer to this?

[Charlie Arehart]

Are you sure you did not experience it in u3? I ask because that update SPECIFICALLY introduced changes regarding file uploads based on file extensions (due to a vulnerability I found and reported to Adobe in the weeks before it).

And that update's technote (and my blog posts at the time, pointing to it) talked about the new means to control file uploads (primarily disabling uploads of server-executable extensions by default):

https://www.carehart.org/blog/client/index.cfm/2019/3/1/urgent_CF_security_update_Part_1

I don't recall any discussion of files with NO extension at all. That may be undefined behavior, or Adobe may have disabled them also in u3 or u4. I am not aware of any option to control "no extension", bur you should read the technotes to find out, starting with my post above.

Let us know what you find out.

[bradwood.com]

Hi Charlie, I can't speak to the OP's update level but in my case, I have a client on CF11 who presumably started getting this after update 18 which included the fix for file extensions.  I too noticed that the release notes have no mention of this behavior specifically, however it does seem to be on purpose if you examine the stack trace:

coldfusion.tagext.io.FileUtils$EmptyFileNameException: Uploads with empty file extensions are not allowed

at coldfusion.tagext.io.FileUtils.checkisBlocked(FileUtils.java:999)

at coldfusion.tagext.io.FileUtils.matchExtensions(FileUtils.java:962)

at coldfusion.tagext.io.FileUtils.uploadFile(FileUtils.java:697)

at coldfusion.tagext.io.FileTag.upload(FileTag.java:784)

at coldfusion.tagext.io.FileTag.doStartTag(FileTag.java:357)

at coldfusion.runtime.CfJspPage._emptyTcfTag(CfJspPage.java:3011)

The error is raised from inside a function called checkisBlocked() which seems to be part of the new security checks and the actual name of the exception subclass is "EmptyFileNameException" not to mention the error message itself specifically calls out the lack of extension.  So it does appear this was a conscience decision by Adobe.  However, I am a little puzzled by it since the lack of an extension would actually make it difficult (if not impossible) for hacker to use an extensionless file since it wouldn't be mapped to any web server handlers like .cfm or .php, etc.

checkisBlocked(

[bradwood.com]

A little update to this-- I just did some poking at CF11 and the specific check for a missing extension was actually added in update 19, NOT update 18.  This explains why my client just no noticed it.  This is very interesting since there is no mention at all of a change to the file extensions in the release notes for CF11's update 19.  It seems Adobe "snuck in" this breaking change.  So perhaps 2018's

Update 4 is also where this behavior came in as well.  It appears the only way to get around this may be to set an allowed mimeType of * on the upload which is undesirable as it bypasses the security mechanism entirely!

[Charlie Arehart]

Thanks for the extra digging, Brad. The stack trace does surely confirm its about the feature added in March (to 2018, 2016, and 11), and yep your second note would explain why the OP felt it happened per the June update only (u4 for cf2018).

As for why they would have added a block for files without extensions, I'd think it more for Linux, where files without an extension are indeed executable (with the right permissions). But I agree that they should have documented it.

More important, indeed tragic, is that because of the way the new upload extension mechanism works, as a blacklist naming what is to be blocked, there is as you say no current way to solve this but to use the empty string, which means block none. That's not desirable. (You refer to the mime type, but that's a different aspect of the upload protection. Have you tested if changing that really works?)

I'd have thought they'd have added provision for the empty string as one of the listed extensions in the blacklist, such that one could include it or not, to control upload of files with no extensions--or use a new null keyword. This would be for the cf admin, or app.cfc/cfm, or the cffile itself, each of which can control the upload, and each overriding the one listed before it.

I have confirmed that as of cf2018 u4, there is no such provision of an indicator for blocking of null extensions, which we could remove. So they DO need to add that, and they DO need to document this change in behavior in the June update.

I have just filed a bug report on this:

CF-4204857

I hope you and the OP (and others reading along) will vote and/or comment on this.

[bradwood.com]

As for why they would have added a block for files without extensions, I'd think it more for Linux, where files without an extension are indeed executable (with the right permissions).

Actually, that doesn't quite wash. The attack vector they are protecting against, is not a local execution in bash, it's a web accessible path that you trick the web server into running (or passing to a script handler).  Think about it, bash will execute a shell script regardless of file name so extension would have no effect on a vector like that.  The reason extensions matter on web-accessible file uploads is because your web server has mappings that passes certain files to script handlers like CF, ASP, or PHP based on the extension and this is the case on a LInux server just as much as a Windows server.

You refer to the mime type, but that's a different aspect of the upload protection

Sorry, I should have been more clear. I was meaning the ability to pass a list of file extensions to the accept attribute, though I'm a little confused how that differs from the new allowedExtensions attribute other than the fact that strict modifies the accept stuff.  It seems that setting an accept or allowedExtensions list of * effectively short-circuits the blocked extension feature and this is a (lame) workaround. 

I agree with everything you said though and I have voted on your ticket.  I have also pinged Priyank in the #adobe channel of the CFML Slack team if you want to keep an eye there for his reply. 

[Stewart]

Brad, I also had this issue with plupload and chunking.  Your solution solves the problem!  There shouldn't be any security concerns as regardless of the file being uploaded the filename for each chunk coming up is "file" and I store the chunks in a non-web accessible folder.

--Stewart McGuire

[noble6]

This is the exact same situation I ran into. Did you happen to find any way to modify plupload to add a dummy file extension when performing chunking?

[Stewart]

noble6​ I did look through the plupload code and couldn't figure out where the filename was being set for the chunks.  Brad's solution solves the problem though.  Just add the allowedExtensions="*" to your <cffile action="upload"> tag in your page that services the plupload chunk requests.

--Stewart McGuire

[noble6]

Nuts. I was hoping that I could solve this from the plupload side. I will have to make some changes to code to handle that security being disabled.

[pete_freitag]

To Charlie's point, there could be a case where a file can be executable on a web server without an extension, in Apache you can setup a ScriptAlias which points to an entire director for stuff like cgi-bin. It is a bit of a stretch, and you could argue that if your upload code allows uploads into a cgi-bin then it probably doesn't matter what the file extension is.

I think it would be good to retain some way of blocking extensionless uploads either with another setting, or by an empty string in the extension list, eg: cfm,,cfml,etc or maybe a special keyword, eg: no-extension in the extension list.

[Charlie Arehart]

Thanks, Pete. (To be clear, he was responding to Brad's point, wondering why Adobe may have added protection against files with no extension.)

And yep, I had proposed the kind of solution you indicate, Pete, in my suggested solution in the bug report. Here it is again, for interested readers:

CF-4204857

[noble6]

I had done a test between our beta and production areas. Production was running update 3 and beta was running update 4. The javascript code for uploading chunked files was identical and the problem presented itself.

[vamsee_k]

Hi,

The check for empty extensions was added in the June update for 2018, 2016 and 11. It was done for security reasons, so unfortunately

we cannot divulge any further details.

Using empty file extensions when uploading files seemed rather uncommon, hence it was not mentioned in the release notes. Given that there is some usage (the plupload use-case), we can update the notes to include this change.

The workaround is the same as the one already suggested in this forum thread i.e using allowedExtension="*". Ensure the files are uploaded to a non web-accessible directory.

We will explore the suggestions given for a possible fix but cannot commit anything at this point.

Thanks,

Vamsee

(Adobe CF Team)

[Stewart]

Vamsee, thanks for the confirmation.  It would be good to document this new behavior and the workaround (with appropriate warnings) in the release notes. 

--Stewart McGuire