I am very very much leveraging Betteridge's Law of headlines in my article headline above. The answer is - almost certainly - no. However it's perhaps a question that needs to be asked, if some conclusions I'm reading on Twitter today are to be taken seriously.
I'm trying to get some clarification on this security situation in which is "dealt with" by this addition of the
allowedextforinclude (note: this was changed to compileextforinclude, by the time ColdFusion 11 was actually released) setting in neo-runtime.xml (discussed in this article: "ColdFusion 11: preventing files from being included? WTF, Adobe?"). There's a ticket in the bugbase "Either remove allowedextforinclude functionality entirely, or at least implement it so it can be disabled". The agreed-to fix here is as follows:OK, so it seems it's completely OK to disable this thing.
But my question remains... what issue are they address here? All they've said is "security". Outwardly this seems very far-fetched, so - for Pete's sake - we need to know what the risk is. If there's a very good reason that most people aren't seeing, we need to know what it its. On the other hand Adobe's conclusions could simply be bullshit, or the approach here could be wrong.
Equally... how can we make an informed decision as to what do to with this setting without any information as to what the story is? Are we OK disabling it? Are we opening ourselves up for disaster? What's the story?!
Adobe have been slow to clarify, so I pinged Rakshith etc on Twitter the other day to follow-up, and I got this tangential response from Aaron Foote:
@dacCfml @coldfusion @rakshithn @anitkumar85 there have been 1 or 2 'in the wild' attacks in the past 2 years that have used this.
— Aaron Foote (@TransientAaron) March 9, 2014
Well... I looked up the exploits that have been reported in the last coupla years (listed on the ColdFusion security bulletins page). There's a bunch of irrelevant stuff there, and the only stand-out one to me is the one that did the rounds about a year ago in which one can circumvent the ColdFusion Administrator password and get into CFAdmin, then use a scheduled task to upload malicious code onto the CF server. This is a very bad exploit (and is non-theoretical: I have heard of a bunch of people being exploited by this).
But this has nothing to do with including non-CFML files, so addressing this by pissing about with how
<cfinclude> works is a pointless waste of time.The fix for this would be twofold:
- don't allow the file that saves task output to be set to be a CFM file (which Adobe has done; now one can only write them to .log or .txt files);
- don't allow them to be written to simply anywhere that the ColdFusion service has file-system access to. IE: Don't let the scheduled task write data to a web-browseable directory which then can be requested and executed by the exploiter.
Now... I guess someone at Adobe has possibly found a way that a hacker has found a way to still
<cfinclude> these files? I'm buggered if I can work out how. To <cfinclude> the exploited file, one needs to be able to write and execute one's own code on the CF server. And if they can do that... they don't need to mess about writing malicious code to .txt or .log files then including it... they can simply just write the code they want in the first place! IE: if they can write this:<!--- fileWrittenByHacker.cfm --->
<cfinclude template="/some/dodgy/file/written/by/a/malicious/task.txt">
Then they can write this instead:
<!--- fileWrittenByHacker.cfm --->
<!---- here's the dodgy code right here! --->
So we're not mitigating anything in this scenario by blocking which files we can include.
Incidentally... with the setting enabled I was still able to upload an execute malicious code on my ColdFusion 11 server, even though I could only save it as a .txt file. And all from within CFAdmin. It took me about 2min to spot the vector, and it worked first time. Now I hasten to add I started this experiment from the point that I already had access to CFAdmin... I assume Adobe have completely patched that security exploit in CF11. But when the next similar exploit security-bypass exploit presents itself, this approach to uploading code to the server via a task and then executing it (despite it having a .txt or .log file extension) is still alive and well.
But here's the thing. The fix to the ticket I quoted from above includes the capability to manage the setting from within CFAdmin. So if the basis for the exploit presupposes access to CFAdmin... the exploiter can just disable this measure anyhow! So what's the bloody point?
So if this is all to do with this exploit, as Aaron suggests it might be, I'm buggered if I see how it helps.
Now I get to the title of the article. Aaron followed up his earlier Twitter message with this one:
@dacCfml @coldfusion @rakshithn @anitkumar85 you alway complain bad things don't get fixed. They fixed this.OK, so let's pretend there is a very real-world exploit that Adobe are dealing with here.
— Aaron Foote (@TransientAaron) March 9, 2014
By addressing this in ColdFusion 11... every single production server on the planet is not patched for this. Because no-one is running CF11 yet. We're all running CF9 or CF10 (or older, but earlier versions are out of support, so can't expect patches anyhow). If it's a significant security thing, then where are the patches for ColdFusion 9 and ColdFusion 10?
So, sorry Aaron, Adobe haven't fixed anything here. Not if there's an actual issue, and not if we ought to be concerned about it. ColdFusion 11 is months away yet. And anyone with any sense wouldn't touch it until it's had the first coupla bugfix / stability patches released for it anyhow, which - following ColdFusion 10's track record - won't be for four months after it's released anyhow. So like Sept 2014 (assuming CF11 gets launched in May, which seems likely).
The headline I guess becomes relevant now: is Adobe knowingly leaving exploits in ColdFusion 9 and 10 unpatched?
If Aaron is correct: yes they are.
--
Adam
The new behavior will be
1) By default only cfm files gets compiled in cfinclude tag and all other file types gets included statically.
2) The key allowedextforinclude now can be specified at the application as well.
3) Added the setting to Server settings -> settings page
4) If wildcard(*) is specified in the value all files will be compiled. Wildcard support is added at both server and application level.