Note: This blog post is from 2020. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

The TLDR is this: If you create (or are given) a CF "CAR" (ColdFusion ARchive) file, you should treat that as a file that contains passwords, as technically it will, if what was exported into it was in fact any CF Admin setting which holds a password (there are several). No, the passwords are not in plain text within the CAR (which is just a zip). But the info needed to decrypt the passwords is in that file, and the CF Admin INTO WHICH such a CAR is imported will now have those passwords enabled within that CF Admin. Perhaps more dismaying, a savvy coder could easily use that info to convert the "encrypted" passwords into plain text in a single line of code. So one SHOULD indeed take care to secure such CAR files (if not delete them after use).

Do I have your attention now? Just a bit more tldr to preface the post...

Is the concern really unique to CAR files alone? And is deleting the CAR files the only way to "secure" them? No, but a difference is that CAR files may be passed around in a way that other "sensitive" CF files would not be. Indeed, what about the process of simply transporting them from one server to another? Should you be as concerned about that? And what if you don't WANT to delete them because they hold the CF Admin settings of record for an old CF instance you are removing? Should you even be concerned that a colleague also accessing your CF Admin might now use the info identified here to try to obtain a CAR file and use it in ways they should not? And what can you do to limit that? Finally, what about other tools that can save/transfer admin settings, like CFConfig in commandbox?

If you're interested in what's up (and if you or anyone on your server uses the CF Archive mechanism at all, you should be), then do read on. Same if you are not aware of what CAR files are used for, as I will explain.

I. A new admonition in the July 14, 2020 updates to CF 2018 and 2016

First, some background: there was an update released today, July 14, to both CF 2018 and 2016. And as often is the case it offers various things--including a fix to a priority 2 security vuln ("DLL search-order hijacking"), which is unrelated to the topic in this post I'm writing.

But those who read the update technotes for either release, such as the update technote for CF2018, may be a bit surprised to see the indication:

CAR deployment

For security reasons, we strongly recommend that you delete the file after the car file deployment. On the Archive wizard UI, we've added a text accordingly.

And then they show a screenshot of the step for building a CAR file, that now adds (an easily missed) new line:
"For security reasons, it is strongly recommended that the CAR file is deleted soon after it is deployed."

This admonition (and text change) wasn't highlighted in the Adobe blog post today about the update, so some folks may miss it.

And of course, while the technotes are linked to from within the CF Admin "updates" page, many folks never bother to read them, so this problem may go on unnoticed by most for some time. I'm doing what I can, here.

But for those who do see this in the technote, they may wonder what that's all about. I can share more from my own research into the matter. (And I'm not sure that the admonition is the best recommendation for all cases. And I could definitely argue that the warning will be easily missed by many.)

Indeed, I started to write this as a comment on that Adobe blog post above, but as I thought of more and more points, I realized that a blog post would be better, not only because more background will help most, but because again the concern and admonition really are NOT limited to those on these updated CF versions, nor should it only be regarded as being about CAR files, as I will explain.

II. What's the CAR mechanism about anyway?

First, some may or may not know that CF has long had a feature in the CF Admin allowing one to export settings from one CF instance to another. It's accessed via the "Packaging&Deployment">"ColdFusion Archives" page of the CF admin (screenshot in a post of mine I'll mention in the next section, or find more about the feature in resources from others like this and this). And with that CAR mechanism, one would create a "car" file (Coldfusion ARchive) holding the CF admin settings to be exported. Much more could be said about the feature, but that's been covered in the docs and other blog posts.

A key point for this discussion is to know that that the CAR file created by that feature is actually just a zip/compressed file. You can open it with any archive tool (or rename it from .car to .zip, to easily open it withing Windows file explorer) to see its plain text contents... and it's those contents that are at the root of the new concern being expressed in this update.

Anyone can use the CAR feature, since CF11

Before I address that concern, let me quickly address a common misconception. Some people think they "can't use the ColdFusion ARchive feature" because it's "only available to CF Enterprise (or Developer/Trial) users, not Standard". That was indeed true prior to CF11.

But since CF11 it's now available in CF Standard as well, as I blogged about back then.) The fact that it can be used more widely is great--but then that increases the need to beware of the concern.

III. Why worry? What's in the CAR file

So back to the new admonition to delete any CAR files once used, you may wonder why Adobe is focusing on it. What's in the CAR file after all?

Again, the CAR mechanism can export the settings of nearly any feature in the CF Admin. And as such, the CAR file created will hold that info, so that the features/settings can be imported into the destination CF Admin.

But many folks may NOT realize that if among the features exported are any that involve a password, then the CAR file will hold those credentials also.

The credentials held in the CAR mechanism

Am I saying that the passwords are in plain text in the CAR file? No. That is NOT what I am saying.

But what IS in the CAR file is the credentials (both the encrypted password AND the seed, which is the encryption KEY AND algorithm), if in fact one has exported a CF Admin setting that holds a password (more in a moment). And of course, the password info NEEDS to be there, for the destination server to be able to decrypt and use the password (and it would encrypt it using that destination server's seed and algorithm).

I'll get back to why that info being in that file is a problem in a moment. (I'm sure many readers already see the concern.)

What kinds of CF Admin settings hold passwords?

First, I want to be clear about what kind of Admin settings I'm talking about (that you may choose to export). Some people may readily think of some (like datasources), but there are several, including:

• any CF Admin settings which let you specify a password, including not just datasources but also scheduled tasks, mail settings, websockets, web services, and Solr server config (again, of course only if you may choose to export them in the CAR mechanism)
• as well as the CF Admin password, RDS password, and additional admin users you may have created (which can be exported using the CAR export window's "Server Settings>Basic Security")

What other files hold such Admin credential info?

And as some will know, all such CF Admin settings are stored in files in the lib folder within your CF instance folder (so /cfusion/lib, if you have only one instance, or /[instancename]/lib for others). CF will store the password for such settings in an XML element within the respective neo*.xml file holding that feature's settings.

And there is a seed.properties file in that same folder, which holds the password encryption/decryption key for that instance (which is changed automatically in each instance since CF11, or which can be changed in the CF Admin itself also) as well as the encryption algorithm.

But the key for this post is that the CAR file when created will ALSO hold such passwords (of features exported) and the seed and algorithm which are used to DECRYPT the passwords when they are later imported into a destination server.

The makeup of the CAR file

Before I go on, some people are the "show me" type, and they may want to look into the CAR files themselves. I mentioned above that it's just a zip/compressed file.

To be more specific the CAR file will usually have within it a folder (called \{WorkingDir}\), and within that at minimum an archive_properties.xml and a server_settings.xml. And it's the server_settings.xml which will hold the details of the settings that have been exported, including any passwords, which would appear in a form like this (buried within other XML about the setting in question):

And then the info for decrypting the passwords info (the seed and algorithm) would be in the archive_properties.xml, again buried within other XML:

BTW, the seed and algo values are there in the file even if no setting has been exported that holds a password. That seems unfortunate. (I tested it by exporting only a single CF admin mapping.)

IV. The vulnerability, if someone can get that CAR file

So now, with all that as a preface, you can see why it's a concern if one is careless about controlling that CAR file.

If someone could somehow find/access/steal/intercept such a CAR file, they could then IMPORT that into a server THEY control, and while they can't readily "see" the passwords, they COULD now USE the CF Admin and of course CFML code that relies on its settings, to potentially access resources that they otherwise would not have been able to access. (Yes, there are things you could and may already do to perhaps mitigate some of these concerns. More on that in a moment.)

For example:

• they could gain access to a database pointed to by a CF Admin datasource definition (once they import that CAR into their own CF Admin), even though they don't "know" the password
• they could run a scheduled task on a URL that was password protected (even though they don't "know" that password)
• they could send mail to a mail server (for which they don't "know" the password)
• and so on (see the discussion above about what things in the CF Admin have password fields)

But won't firewall/IP protections protect against such abuse?

Sure. If the folks responsible for the server (database or otherwise) that CF is talking to has implemented additional security on the resource such that only limited IPs can gain access to the DB, then of course someone who is NOT on that list of "allowed IPs" to be able to talk to that thing, even if they DID import the CAR file into their own server's CF Admin.

But there are 3 things I would warn about dismissing this concern (the admonition to delete or better secure the CAR file):

• Do beware that in some environments, that "allowed IP address list" might be left open to allow access not just from your own CF server but perhaps also allowing access from ANY server within some trusted subset/segment of IP addresses...and if someone could run CF on a machine within that trusted segment, then THAT CF instance could now "have access" to that resource
• Even so, it's definitely NOT a given that everyone who manages such servers (which your CF code/CF admin talks to) will have been careful to implement ANY such an IP address limitation--though of course, any reasonable security-conscious admin should be. They may be relying solely on this password protection, which would now be compromised
• Finally, remember that this not JUST about databases or mail servers. Sure, the admins of such servers would tend to have implemented IP security protections. But what about just a URL that is set in the CF Admin as a scheduled task, and perhaps only a "basic security" password may have been implemented to "control access" to the URL in that task?

You may be tempted to say, "well, these are not my problems. If a server admin isn't careful to lockdown IP addresses which can access their server, they'll get what they deserve".

But that won't hold up if someday someone connected the dots that you had been careless yourself with this CAR file. This is why the onus is really on you--if you create or use a CAR file--to protect it, like any other "secret".

And this is why there is the new warning in the Admin, per this new update--as well as the warning in the technote, and also now this blog of mine, suggesting that you should delete car files once you have used them (or at least better secure them), so as to reduce the surface area for such an exposure. And you'll want to avoid those CAR files existing for long, for other reasons I am about to explain. But first...

V. Don't we need to be just as worried about the neo*.xml and seed.properties file?

Yes. Yes, we do. But in fact, I will make the case that we should probably be MORE concerned about the CAR files. Let me explain.

First, as I said above, what is stored in this CAR file is merely what is ALREADY stored in files created/updated by the CF Admin itself, first from the passwords (stored in encrypted fashion) in the various neo*.xml files in the instance's lib (like cfusion/lib), as well as that seed.properties file in the same folder, which the CF Admin uses to encrypt/decrypt the passwords as stored in those neo*.xml files.

And this is in fact why the CF Lockdown Guide (for CF2018, 2016, and so on) have long indicated this warning about protecting those files also. Quoting from the CF2018 version:

4.13 Additional File Security Considerations
Pay careful attention to the file permissions of sensitive configuration files located in {cf.instance.root}/lib/ such as password.properties, seed.properties and all neo-*.xml files.

That's all it says, sadly. Is it security by obscurity? I won't make that accusation. There is always a risk of sharing too much information about vulnerabilities. And I was indeed torn about what I am sharing here, but once that update came out with this change and the admonition, I just felt more needed to be said. (And I'm not sharing info that can't be discerned from other resources already on the web.)

(In fact, I'll note how there was a discussion in the Adobe CF community forums, where someone was trying to copy the neo-datasource.xml file from one server to another and found the passwords were "not working", and an Adobe support person pointed out how that problem could be "solved" by just bringing along the seed.properties as well from the old to the new server. (They didn't go on to elaborate various reasons why that's a bad idea--though they did suggest the CAR export/import would have been "easier"). But it demonstrates the point that the seed.properties is the key to CF being able to decrypt passwords in the neo*.xml files.

What mechanisms might be used to protect those other "sensitive" files?

I'm hesitant to presume to go beyond the Lockdown Guide, but we might presume that the discussion of "file permissions" was an implication that one might set things so that only the user running CF itself had permission to see those files.

And indeed, the same recommendation could certainly apply to CAR files, if they are going to sit on the server where they are created.

But I will make the case that the CAR files are different and perhaps deserve even more care/concern.

VI. How are CAR files different, and why might we want to be perhaps even more concerned about them?

There are at least two ways they are different, and that will lead to why one could argue they are even MORE important to secure and be concerned about.

First, the lockdown guide can be written to say "lockdown those neo*.xml and seed.properities files", since they exist in one place (per instance). But a challenge with the CAR files is that they can be created at any time by any CF Admin user. As such, we could argue that the lockdown guide COULD (and perhaps should) at least be modified to warn people to take as much care with the CAR files (and hopefully in the future, it will) when they are created.

Again, for now, the admonition is simply to delete then as soon as possible, once used.

But a second problem with (and indeed a difference about) CAR files is that they are often moved OFF of the server where they are created and onto some OTHER server to be imported into the CF Admin on that server (it's the reason the CAR mechanism exists: to export settings out of one CF Admin and into another). And you may or may not be able to maintain the exact same security on the files if you need to pass them to another server (that perhaps doesn't share the same security architecture...heck, the other server may be a different OS).

And once placed on that OTHER server, the CAR file surely needs to be secured appropriately THERE.

Let me elaborate on why, and how it leads to a 3rd concern for how CAR files are different than these other files...but it starts with explaining a real concern with all of these CF admin files which hold credentials. I alluded to it in the opening.

How someone could determine the actual password, with this seed/algorithm info

I've explained how if you export a CF Admin setting that has a password, the CAR file will have that encrypted passwords, just like the neo*.xml files underlying the CF Admin. And it will also have the encryption key (seed) and algorithm to be used to decrypt that password, just like the seed.properties file underlying the CF Admin.

Well, do the math: if one has either such a CAR file or those other files, they have what they need for CF to decrypt the password into plain text.

I'm not going to show how here, but there is information on the internet showing how to take such an "encrypted" password from one of the neo*.xml files, and using the seed and encryption algorithm in the seed.properties, convert that to a plain text password in a single line of CFML.

And that's of course why the Lockdown guide admonishes securing those other files.

But this is again why it's important to treat CAR files with the same care since they contain the very same info! Indeed, you should treat them as if they were themselves "password files"--because technically, if you export anything that uses a password, all that's needed to decrypt it is in that file, in plain text.

At a minimum, you don't want to let these CAR files sit around, unsecured! Secure them as the Lockdown Guide recommends doing for the neo*.xml and seed.properties file.

But I'll argue that's not enough, really, because...

Consider even securing the copying of the file from one server to another

For all the reasons above, care should be taken also about simply transmitting the CAR file between servers.

Again, think of them as you would a file of plain text passwords. Wouldn't you use greater care in transmitting such a file of plain text passwords? (Granted, they're not "just plain text" in the CAR files, but again all it takes is anyone running even the free CF Developer edition to be able to either import and use the Admin settings with their passwords or go the next step to try to decrypt them to plain text.)

So:

• Don't email CAR files as unprotected attachments, via insecure email
• Don't send them to the other server using simple FTP (use SFTP or FTPS--I'll leave that debate to others)
• Don't carelessly leave them on a USB "thumb drive"
• Don't put them on an openly shared network or cloud drive (be sensitive to "trusted colleagues" who may grab the files for the nefarious uses above)
• and so on (if you think of other common things folks might do, let me know in the comments)

Finally, beyond worrying about them "in transit" even if you "secure" the file one way on the source server, there's no guarantee that such security will be honored on the destination server (they may not be the same OS), so you may feel forced to leave it "unprotected". Again do be sure to secure CAR files on the source, at the destination, and in transit between them.

Or as Adobe is noting, just delete them as soon as you use them...but there's a problem with that admonition. And a few other various questions remain.

VII. A few related questions

You may have a few other questions that arise out of the above.

What if I HAVE to keep the CAR file around?

Someone might balk at being told to delete the CAR files once used. And a quick retort from someone may be, "why not? you can just recreate it again when you want to".

But what if you are creating the CAR to hold all CF Admin settings before uninstalling an old CF version, or removing the server entirely, etc? In that case, you may NOT want to "just delete" the file. You may want to keep it around as a record of all the settings.

This is why I am stressing above that we need to really be prepared to simply give CAR files the same attention to security (wherever they will be sitting) as the neo*.xml and seed.properties files--or indeed any other "sensitive" file we may have.

Should I perhaps add my own password/encryption to the file?

This section is an update since the original post. It was prompted by a helpful comment from Bill Rickman who asked (in part), "Would it be prudent to also zip/rar them again with encryption and password protection before propagating them to the other server(s)?"

Sure, and that's a more specific example of the kind of giving CAR files "the same attention to security...[as we would] any other "sensitive" file we may have" I had mentioned at the end of the last section. I am realizing now I didn't really propose such alternatives (leaving it to folks' experience and imagination), but it's not a bad idea to toss out a couple of specifics. Thanks, Bill.

There are still other ways: some folks use encrypted file systems (whether provided by their OS or an app), such that files placed in that drive or folder are automatically encrypted. I could go on (and feel free to share any other specific ideas in the comments.)

But sure, going to another step (like zipping, or other means) to specifically also add a password to a file would be a way to make it so that even if you did pass the file out to another server (and over some network), anyone who intercepted the file would need to both decrypt it and know its password.

Now, as Casey Kasem used to say, "on with the countdown". :-)

Should a CF Admin users be concerned if others with access to the Admin might abuse this mechanism?

Sadly, this is something that should be considered. Many people still share a single CF admin account (even though CF has for decades been able to let you create different Admin users, as I've written about in the past).

Either way, most CF admin users may presume that "since someone else using the CF admin can't 'see' the passwords, they can't 'use' them in any way". But now you can see that if one HAS the ability to create a CAR file, they can create that file (anywhere they have permission to write to on the CF machine), and now they will have the CAR, to use in the nefarious ways above.

You may think, "well, if they could get on the server to access the Admin, they could just as well have gotten to the neo*.xml and seed.properties files", but that's NOT true if someone following the CF Lockdown guide and DID secure those files so that only the user running CF itself could access them. Again, this ability to create a CAR "circumvents" that. Forewarned is forearmed.

I will note that the mechanism to create different Admin users does indeed have the ability to limit what FEATURES in the CF Admin a given new Admin user is allowed to access, and there IS in the option you can "prohibit" or "allow" (see my article above) the option for "Packaging and Deployment". So at least you COULD (and perhaps should) limit who else using your CF Admin might be able to create such CAR files.

(Someone might go so far as to consider disabling the CF Admin car export feature, either removing or renaming or changing perms on the file or folders that provide that page in the CF Admin. That's an option, but just using the admin user feature to limit WHO can access it seems a better solution for most.)

Couldn't Adobe do more to protect us?

With all that background, one could reasonably ask, why is there no feature built-into the CAR file creation mechanism to address these concerns, to make them more secure "out of the box".

In fact, it was a client of mine who raised this concern some weeks ago, and I passed it to the Adobe PSIRT (security team), along with some suggestions that came to my mind of how they might add "more control" to this CAR file creation process, such as:

• a way to tie the CAR (and indeed, the seed.properties file) to the machine on which it exists, so that it can't be used off of it (for those who had no plans to use it on another server)
• a way to require some additional authentication (when a CAR was created holding passwords), so that it was not enough just be able to import and use it on another machine

I did acknowledge that there are challenges with any of these, and also that they (Adobe) may not regard the problem as urgent enough to warrant putting work into them. Still, I asked.

And their determination (with the CF team) that this was indeed "a usage issue"--the implication being that it was not something THEY needed to protect for us, but rather simply something that WE should protect ourselves. I asked if they could at least consider adding some stronger wording about this matter, either in the Admin or the Lockdown Guide, or both.

And now a couple of weeks later, we see this new admonition in the technote and CAR import process. Is it enough?

Couldn't Adobe still do just a BIT more, especially about the new warning?

I will say that I was pretty disappointed in the current "warning" that was added. Again, all that's been added is this one sentence, and only on the page when you are DEPLOYING a car file:

For security reasons, it is strongly recommended that the CAR file is deleted soon after it is deployed.

(They show a screenshot of it in the technote for the update.)

I see multiple concerns with this as the "solution" to the concern I raised:

• That sentence is not bolded, and just appears as a new line after others. It will be easily missed
• It's only shown on the popup for the CAR import, not during CAR export. I'd argue it's important in both
• Further, I'd argue that the warning should be instead on the main page for creating/exporting OR deploying/importing CAR files (and should be visible whether any cars exist yet or not)

I have not yet raised a bug report/feature request for that. I've spent too many hours already today pulling this together. When I do add one, I will add a link to it here, for any interested.

What about other mechanisms that save settings, like CFConfig in Commandbox, or CF2020's cfsetup?

While for years, the CF CAR mechanism was the only way to formally export settings out of one CF instance and into another, in the years since other options have risen. How do they compare on this count?

CFConfig in Commandbox

Indeed, some folks won't even read this post because "they don't use the CF CAR file mechanism. They use the CFConfig tool in Commandbox". It's indeed a great tool. (And if you didn't know, it's not JUST a tool for managing CF Admin settings for Commandbox server instances, but can be used to manage ANY CF or Lucee instance's settings, as long as you point it to the instance's path.)

And among its many powers, you can use it to create a json file holding some or all the Admin settings from an instance, much like the CAR file.

So should we have the same concerns about that CFConfig.json file, or indeed perhaps "no concerns"? Well....not exactly. There are DIFFERENT concerns to be aware of.

I don't think I'll be held to be spilling state secrets if I point out that regarding things like DSN or scheduled task passwords, it simply decrypts those for you and stores the passwords in plain text in the json file.

If you have CommandBox and the cfconfig module installed, you can see this for yourself. Indeed, you can easily create an export of all CF Admin settings in a typically installed CF instance (in this case, on a Windows machine) with this:

Assuming you have a DSN defined, and with a password, you will see it within elements like this:

One of the challenges for CFConfig is that it's designed to allow you to export/import settings even between CF and Lucee (or different versions of each), so perhaps the decision was made that simplicity ruled. And like the Adobe PSIRT, the thinking may be that securing this is a "usage issue", as in "it's your files, you can protect them".

That said, I was surprised on looking into the docs that there's not a stronger warning to protect the files. (Well, there's a mention of how you might want to use its available "secrets" feature so that such passwords don't get pushed up into a source code repo. That's not so much a warning as a feature mentioned in passing, I'd say.)

Again, perhaps the thinking is, "well, if you look at the file, you can see that it has passwords in clear text", but I do wonder how many people might use the tool and never even think to look at the file. Or indeed the docs. Perhaps it would be helpful if the tool popped out a warning when writing out any plain text passwords into the config (which could be silenced with an arg for those who acknowledge the responsibility as a given).

(And yep, I know I could do a PR for either point above. Again, I've spent much of today on this post, so I will have to leave that for later. Finally, I did drop a note to Brad to let him know I'd be offering this concluding point in my post, and to ask if he had any addition. He confirmed what I say above, and added that there's a JIRA ticket on an idea being considered, but for now, securing the file json and indeed noticing that the passwords are in clear text is left to each user. )

What about the new CF2020 CFSetup feature?

Finally, and to the delight of some, CF2020 is due to add a similar tool, called cfsetup--which may be to the chagrin of others who see it as reductive...and as Madonna said, "look it up". :-)

I can't share any on it, while it's in prerelease, but I will say that CF Product Mgr Rakshith Naresh did at least indicate publicly the name of the tool (in his webinar earlier this year on CF2020.)

But it's reasonable to presume that there are no more protections in that since the problem has not been identified any more significantly by Adobe today in this update.

Hope all the above is helpful...and if you read all the way to the bottom, thank you! (I'd love to hear what you think, whether you found it worth the time/bother or not.)

For more content like this from Charlie Arehart:

• Signup to get his blog posts by email:
• Follow his blog RSS feed
• View the rest of his blog posts
• View his blog posts on the Adobe CF portal

Need more help with problems?

• If you may prefer direct help, rather than digging around here/elsewhere or via comments, he can help via his online consulting services
• See that page for more on how he can help a) over the web, safely and securely, b) usually very quickly, c) teaching you along the way, and d) with satisfaction guaranteed