WTF, Adobe? Hotfix 20

[WolfShade]

Adobe never fails to disappoint.

This latest hotfix for CF Server triggers an email notifying us that such-n-such variable is "not expected" by a cffunction with access="remote" attribute.  Doesn't matter if it's a form that is posting to the cfc, or using URL parameters (query string), if something is passed to it that doesn't get processed, we get an email telling us about it.  Even for things like

returnformat=plain

WHY?  How, exactly, is this being "more secure"?

How do I get these emails to stop?  This is ludicrous.

[BKBK]

Hi @WolfShade ,

What you describe does indeed sound bothersome. Could you share a bit more about the context?

Apparently, the server is Update 20 of  ColdFusion 2021.  The application has CFCs whose functions can be accessed remotely by means of form submission or URL parameters. Whenever an error occurs during such a request, ColdFusion sends you an e-mail. I hope I am with you so far.

But then, I am scratching my head, wondering why your post gives the impression of e-mails being sent beyond your control. Where is the sending of e-mails configured? In the Administrator? In Application.cfc? In application code?

Who did the mail configuration or wrote the mail-sending code?

[WolfShade]

Hi, BKBK.

The url parameter returnformat=plain will throw an exception if it is not utilized or paramed as an argument.  The error template generates the email.  This doesn't break the functionality of the cffunction, no errors appear on screen.  But on a public facing site that sees thousands of users a day, our inbox is being filled to the brim with these "error" emails that aren't actual errors.

So I have to question why Adobe, in all their (lack of) genius, decided that an element that isn't actually used for inserting data into an email, or Excel sheet, or database, but is provided to tell CF how to return the requested data, qualifies as an "error", or poses some kind of security threat.

I have been very vocal in my disappointment towards Adobe.  They don't know what they are doing.  Seems like they are arbitrarily creating issues for them to solve, then solving them in less-than-ideal ways.  This latest hotfix, and the two prior ones, have all created a ton of unnecessary break-fixes, and I'm the only CF dev on the contract, so I'm scrambling like mad to keep things running.

Yes.  I'm pissed.

V/r,

WolfShade

PS:  They created yet another issue.  I'm getting emails that say a value included in a cfinvoke has to be a "constant".  It's from a user filled form.  That kind of negates the whole concept of "dynamic programming".

PPS:  I created a bug for it:  https://tracker.adobe.com/#/view/CF-4226845  Please vote for it.  Thank you.

[WolfShade]

Now things are even more confusing.

I changed the code so that the CFC takes the author_cn straight from the user's CAC, and removed the offending non-"constant" from the CFINVOKE.  Additionally, my SA/DBA told me of a flag in CFAdmin (Dcoldfusion.runtime.remotemethod.matchArguments) that was currently set to "true".  We changed it to "false" in our staging area, and the same error email is still being triggered.

Which makes me think that either A) CF Server is not giving me an accurate error message, or B) the template is somehow being cached, and the change is not being applied.

Is there a way for me to programmatically clear template cache?  If I can clear it, and the error message is still triggered, I can at least eliminate that as an issue, and focus on CF Server not giving me an accurate error message.

V/r,

WolfShade

PS: SA cleared the cache.  It didn't fix anything, but it did help point me in the right direction.  So the error message about the constant is no longer happening.  But the first issue I reported is still an issue.

[BKBK]

Odd thing: Tracker cannot find the issue.

I suppose Tracker has issues of its own.

Code to programmatically clear template cache:

<cfscript>
<!--- Login into Coldfusion Administrator. --->
adminObj = createObject("component", "cfide.adminapi.administrator");
adminObj.login("your_CF_Admin_password"); 
runtimeService = createObject("component", "cfide.adminapi.runtime");
runtimeService.clearTrustedCache();
</cfscript>

[BKBK]

Hi @WolfShade ,

I reported a bug for Tracker via cfsup[at]adobe.com, and Tracker has been fixed. I have duly voted for the ticket.

Could you share the solution of the second issue?

[WolfShade]

I am currently logged on to my account (obviously), and when I click on the Tracker link I can see it.  I'll have to try it, again, after I log off and close the browser.

Thank you for the code suggestion.  Unfortunately, only the SAs have access to the CF Admin, and we cannot use the CF Admin API.

V/r,

Wolfshade

[BKBK]

Hi @WolfShade , I think you are quite right about one thing. If when making a request to the server the client passes an arbitrary parameter unknown to or unexpected by the server, the default reaction of the server should be to ignore the parameter. To me, that makes sense security-wise.

In this situation a taciturn server, responding minimally or not at all, would reveal less about itself. Hence, it would be more secure. Whereas a server that reacted to every unknown or unexpected parameter would be paranoid, continually barking up all trees and revealing lots of information about itself.

From what I can see, the default implementation of the new JVM flag, -Dcoldfusion.runtime.remotemethod.matchArguments=True, returns an HTTP 500 (Internal Server Error) when an unkonwn argument is passed. I think such an error should be a CLIENT error (hence HTTP 4xx) instead. After all, it is the client who has made an error.

This is crucial because the server is obliged to return the reason for failure to the client, together with the error message. The reponse would then enable the client to learn and adapt the request. Otherwise, the client may keep repeating the erroneous request.

Examples of relevant HTTP 4xx responses, of which the server has to use the most relevant:

HTTP/1.1 400 Bad Request

HTTP/1.1 404 Not Found

HTTP/1.1 406 Not Acceptable

HTTP/1.1 415 Unsupported Media Type

I wish to assist in looking into the first issue, if you don't mind.  

Could you let me know:

• the "returnformat" and "returntype" of the remote function being accessed by the client;
• the type of HTTP error returned to the client (I am guessing '500');
• the exception class of the error that is filling up your mail folders (for example, coldfusion.filter.FilterUtils$InvalidPlainReturnFormatTypeException, coldfusion.runtime.UDFMethod$IllegalArgumentException, that sort of thing)

What I have in mind: possibly to "catch" the exception in onError, thereby preventing the sending of an e-mail.  

[WolfShade]

Hi, @BKBK .

I believe you have accurately and succinctly described the current state of the situation, and provided what I consider to be a viable (and more common-sense) approach to how this should actually be implemented.

If the extra argument is the only "error", thus reported by the server via email, the functionality is not actually breaking.  No server error messages in the browser.  It still processes as expected, and the user is not aware; the function finishes seamlessly.  It's just "nagging" the dev team about an error that isn't actually an error.

I had to provide a cfargument for "returnformat" in the cffunction to get it to stop.  I have to do this for every cffunction in every active project we have, for all arguments passed, even if not part of the data process and used as instruction for the CF Server for formatting, or whatever else CF Server needs to know to return the data.

If I use returnformat, ever, it's always =plain.  Used for AJaX requests where I'm just displaying a message from the server to the user, and always paired with returntype=string.  Typically either for form validation, or to confirm to the user that the data was successfully processed, as expected.  I prefer this method over the old-school proper form submit, as it keeps the field values as the user entered (in the case of form validation reporting a needed correction) and the fields can be programmatically cleared upon success.

V/r,

WolfShade

PS:  I logged off, closed the browser, opened the browser (Brave) and went to the Tracker link.  It appeared with no issues.  So, unless Adobe is fingerprinting my browser, I suspect that Tracker was having an issue at the moment you clicked the link.

[BKBK]

Hi @WolfShade , thanks for the update and for sharing your solution.