Looks like CF2021 update 12 broke wddx2cfml to some extent...

<cfset form.test = 'value'>
<cfwddx action='cfml2wddx' input="#form#" output="w">
<cfoutput><pre>#EncodeForHTML(w)#</pre></cfoutput>
<cfwddx action='wddx2cfml' input="#w#" output="test"> <!--- Throws: WDDX packet parse error at line 1, column 85. Invalid WDDX packet: root element in not wddxPacket. --->
<cfdump var="#w#">

Is this an expected change with the security update or accidental? If expected, is there a recommended workaround? (I tried doing a

StructCopy

around the

form

, which changed the "type" attr in the output xml, but still caused the error)

Is that it's the form scope relevant here? It seems like an odd test case if not. And this code works fine on CF2021U11?

Yes. And Yes.

And what if the element in the form scope doesn't have the same name as the variable you deserialize the WDDX into. IE:

form.test

and

test

.

No change in error when making all the various keys/variables unique.

(That one was a long shot)

When I change the

cfml2wddx

input to

StructCopy(form)

the generated XML has

<struct type='coldfusion.runtime.LocalScope'>

, which seems a little odd. When I generate XML of a normal struct, there is no type attribute and no error.

I wonder if this is the same as @gsr’s WDDX issue which they were unable to replicate/articulate.

The (icky) workaround would be to strip the type attribute from the generated XML. Which would allow it to

wddx2cfml

, and I could still set the form scope to that struct (AFAIK) without issues. Though your test made me curious what Duplicate does. And apparently doing

Duplicate(form)

in the

input

for the

cfml2wddx

generates XML without a

type

attr, so that would work as well. Though seems like it shouldn't be necessary.

I'd raise a bug and poss try

duplicate

instead of

structCopy

. The utility of

structCopy

is minimal as - as far as I recollect - all it does is make a new ref to the struct, it doesn't really copy anything,

Still somehow changes the class 😬

Though seems like it shouldn't be necessary.

Well of course. But... like... it's a bug. You need to work around it.

If it is a bug, it might be intentional 🤷🏼‍♂️

Does it matter that the input to the WDDX serialisation was a form scope object?

The code that brought this up handles when a user submits a form when their session has timed out and they utilize an SSO. We stash the form and set a cookie with a UUID to load it back later. So the source of data is the form scope, but I don't think it needs to be, so utilizing

duplicate

should get around the issue.

Yes it’s the same I got @rodel30 thanks very much

Cool! Did Sandip give you a ticket? It's hard to track these things if one lets it disappear into the Adobe ether...

No

OK, do me a favour in future? If you solicit help from ppl & they sink time into doing so... come back with the resolution. Even if it's just "I raised a ticket [ticket number]". And if you talk direct to the CF Team and they raise a ticket... make sure to get it from them and make sure it's publicly visible. These things have a habit of... vanishing.. Plus if you have an issue that you get more info on and you share it back, it'll make life easier here when another person has the same issue. It'd've been way quicker to go "oh yeah @gsr had that and raised a ticket... it's xyz-1234"

I appended coldfusion.filter.FormScope; to the allowed list in cfserialfilter.txt and it worked. (The semicolon is required even if you add it at the end of the list) *also need to restart ColdFusion

ColdFusion has by default disabled wddx deserialization of ColdFusion internal classes. If you need to whitelist any class, you can add the same in cfserialfilter.txt file present in cfusion/lib For more information you can refer https://helpx.adobe.com/in/coldfusion/kb/coldfusion-serialfilter-file.html

@kuro5 That is not going to fix it and i tried it on our dev server

@Rochelle Hannah if this was the issue here, I'd expect a very clear WddxDeserializationException with a message "Cannot deserialize internal CF objects", and detail "`coldfusion.filter.FormScope` is an internal CF class, and instances of it cannot be deserialized from WDDX". And that's not what's happening. Also... the form scope ought not be implemented in such a way that it counts as a "ColdFusion internal classes". It's a fundamental part of CFML, not "CF internals", and - really - irrespective of what's going on under the hood should be treated as a

coldfusion.runtime.Struct

. I also note that

coldfusion.runtime.Struct

is missing from the list on that URL you cited above.

Hey folks. I think if you see the new log file wddx.log it very clearly mentions if any class/package gets blocked.:

Due to security reasons, coldfusion.filter.FormScope is blocked for deserialization. Add the class/package in the file cfusion/lib/cfserialfilter.txt to override the behavior and allow deserialization

The error is different from deserialization And I already tried it so it’s not connected to it

The intention for not showing same in UI is very clear.

This is a perennial problem with the CF Team. They don't get web development. Indeed they don't "get" CFML development. The public don't see the error. Hiding runtime code errors from the end user is a completely different thing, and irrelevant to throwing a good exception for the developer. The devs need to see the runtime error... same as any other exception message when robust exception handling is on. The devs need this info. Not presenting an error properly in the UI where ppl are expecting it is a) not helpful; b) really ignorant of how CFML development works. Also: where is the mention of wddx.log in the docs? https://helpx.adobe.com/coldfusion/cfml-reference/coldfusion-tags/tags-u-z/cfwddx.html

we have mentioned wddx.log in notes section off https://helpx.adobe.com/coldfusion/kb/coldfusion-2023-update-4.html

Lovely, but where is it in the docs for the tag it affects? People are not gonna go "now I wonder if there's a new wddx.log I should be looking out for?", and they're not gonna read every doc you lot publish. They will go to the docs for

<cfwddx>

in the hope that it'll explain why their code is suddenly crapping out with no clear explanation as to why.

The mention needs to be in the notes for 2023 update 6 and 2021 update 12 as well, as a change in that update is what actually caused me to need to account for things and the update page didn't have any info on it.

Feedback taken.I will try to get this done. Thanks

But it is still an issue The docs you mentioned is not going to fix the problem it created Pinging @Mark Takata (Adobe) and @sandip_halder here

@gsr I'm not in a position to try this myself right now, so I could be off base, but did you look in the wddx.log to see the exact name of the class is being rejected? If so, did you try adding it to the list in serialfilter.txt, as described in the tech note? Docs themselves won't change how code behaves of course, but changing code in response to the docs might change the result. That said, even if that does work, IMO both the release note docs and docs for the tag/function need to be clearer about the fact that there was a potentially breaking change, which needs to be worked around, and how exactly to do that.

yes, i have tried adding that the serialize thing and it has not fixed anything so that is the reason i messages back again here

Did you see a corresponding entry in wddx.log?

heh, yes it needs these attributes to be enabled: coldfusion.filter.FormScope;coldfusion.util.CaseInsensitiveHashtable;coldfusion.filter.UrlScope;

what a wastage by adobe patch

Great, glad you got it working. I * think * the overall idea of the original change was to prevent malicious or dangerous classes from being create by deserialization. I'm not clear on what about the form scope is risky to deserialize. Do you actually test whether ALL the items you added to serialfilter.txt are needed for your code to work?

yes the above listed ones are needed to make it work, because not sure why it has to be this way

I can’t really comment on the intended/functional uses of WDDX deserialization and serialfilter.txt, but details were released today on one of the new WDDX deserialization vulnerabilities from APSB23-52 - CVE-2023-44353 - https://research.nccgroup.com/2023/11/21/technical-advisory-adobe-coldfusion-wddx-deserialization-gadgets/ This one looks similar to CVE-2023-29300, CVE-2023-38203 and CVE-2023-38204 from back in July — it just uses different ColdFusion classes in the attack payloads. Successful attacks can allow probing for the existence of files/directories in all supported VFS schemes (filesystem, FTP, JAR, HTTP etc.) and blind Server Side Request Forgery, Continuing to lock down / adjust serialfilter.txt may limit the available classes to be used in attack — but blocking remote access to .cfc files entirely should prevent attacks as well, since you won’t be able to reach vulnerable code / pass in an argumentCollect parameter.

@Brian Reilly Thank you, that's interesting and helpful. However, blocking access to remote cfc methods won't affect wddx deserialization elsewhere in an app, so I'd think the issue @gsr is seeing would still happen. Am I missing something?

Hi folks.. Deserialization attacks are very common in most of the languages. As there is no full proof solution to it, every language provide infrastructure, that can be used by application developers to prevent such attack. Cf has decided to implement such infrastructure to prevent same.We have introduced cfserialfilter.txt file. The goal is to block all classes and packages for deserialisation by default.If your application needs any class to deserialize, you need to add same in cfserialfilter.txt and restart Cf. Also for convenience we have added wddx.log file, which tells you which packages are getting blocked in your application and you may need to unblock it. We recently saw couple of wddx deserialization attacks in Cf. And as security measure this approach is taken.

@Dave Merrill - I believe that's correct, since (I think) there's a single WDDX deserialization class and the controls in serialfilter.txt would apply to wherever it happens -- whether it's gsr's example or in a remote CFC

@Satyam Mishra given this is related to a pen vector, makes it even more critical to have this info front-and-centre on the docs for

cfwddx

.

@Adam Cameron I have already raised request for same. You will see this change soon.

and how safe is cfserilize,txt, its just a text file

It's in the server directory subtree, well away from anything that should be exposed publicly. So unless one goes out of ones way to expose it... pretty safe. File type doesn't play much of a part in app security. That said... a .txt file with a comma-delimited list of values is not exactly screaming "professionalism" in regards to the implementation, or UX.

What would you prefer? JSON? XML? YAML? 🙂 (actual question, not being snarky)

Even LF-separated would be clearer Probably a JSON array. Good for both humans and machine. And the whitespace (or lack thereof) works either way

OK, for what its worth I agree. Maybe we can write a little UI to add/remove & write the JSON.

One of the worst things about CFML. Just to hyperbolize

BRUH IT IS ON

@Adam Cameron Ah, now you're just picking on stuff. Personally, I think cfquery is wonderful, assuming you're going to have actual SQL in your app, which again personally, I vastly prefer to ORM and its bastard relatives.

image.png

Possibly the funniest thing I have ever seen in my life. /me oh god my life has sucked so far