Title:
latest update (June 2019) blocks upload of files with no extension, without offering a way to control that
| View in TrackerStatus/Resolution/Reason: To Fix//BugVerified
Reporter/Name(from Bugbase): Charlie A. / ()
Created: 07/14/2019
Components: General Server
Versions: 2016,2018
Failure Type: Incorrectly functioning
Found In Build/Fixed In Build: 2018,0,04,314546 /
Priority/Frequency: Normal / Few users will encounter
Locale/System: / Windows 10 64 bit
Vote Count: 5
Problem Summary:
The June 2019 updates of CF 2018, 2016, and 11 is now blocking upload of files with no extension. The problem is that a) this is not documented (in the tech notes or release notes for each update), and more important b) there is no way to ALLOW for such null file extensions, if desired.
Background:
As some readers will know, the April 2019 updates to CF2018, 2016, and 11 added a new security protection mechanism whereby CF would now block upload (processing, via cffile action=upload) of files with a set list of known server-executable file extensions (like cfm, jsp, aspx, php, etc.)
This was enabled to prevent situations where unsuspecting developers (who didn't list what extensions SHOULD be allowed) were allowing server-executable files to be uploaded, and if placed into web-accessible folders, they were then executable by outsiders and allowed to run with the full permissions of the running CF instance.
The protection (to block the known risky file extensions) was enabled at the Admin, application, and tag level (cffile action="upload")--each overriding the one before it--whereby one could modify the list to allow some extension (such as if one knew they wanted to allow it but would upload the file to a non-web-accessible folder).
Then this June 2019 update (update 4 of CF2018, with corresponding updates for 2016 and 11) has changed things so that files with NO extensions are automatically blocked.
The current workaround:
The problem with with the June 2019 update is that there is no means to ALLOW such files with no extensions. If someone uploads a file with no extension, it is blocked.
The only way to allow it is to change the list of extensions (at either of the 3 levels) to be AN EMPTY STRING, which means do not block ANY file file uploads, regardless of extensions. (If it's made to be an * instead, that means block ALL file uploads, regardless of file extensions.)
The suggestions solution:
The new ability to block files with no extensions should have offered some means to indicate (in that list of "blocked extensions") when one DID or DID NOT want to block upload of files with no extensions.
It could be an empty string (as one of the values in the list of extensions) or a NULL keyword. Then if it was there (by default, in the admin, like the other extensions blocked by default), it could be removed. As it stands (per the June update), there is NO indication that empty file extensions are blocked, so there is nothing right now we can "remove", so as to PERMIT uploads of files with empty extensions, again other than removing ALL the listed blocked extensions, which then allows ANY. That's not desirable.
So first, the current technotes and release notes for the June update should be updated to reflect this change in behavior--and how the only way to allow uploads without extensions is to allow ALL extensions.
Then second, a new update should ALLOW for indication (or not) in the list of blocked extensions for whether files with no extensions should be blocked.
PS:
Yes ,someone may well decry that this is one of the problems with having a blacklist (what to block) rather than a whitelist (what to allow). Again, see the opening discussion here. CF has indeed long had a whitelist feature. The problem was that if folks did not use it, then files with ANY extensions could be uploaded. This new feature (per the March update) was introduced to add protection where developers where not protecting themselves. This empty file extension is just a particularly challenging kind of thing to indicate in a blacklist, but it CAN be done.
Attachments:
Comments: