[Looking for Charlie's main web site?]

Come see my online talk, "Migrating or Comparing CF Admin Settings", at noon ET on Aug 13

Just thought I'd share a heads-up here on the blog that I'll be the speaker for the Online ColdFusion Meetup this week, Aug 13, at noon ET, presenting a new talk:

Migrating or Comparing CF Admin Settings, between instances, versions, and engines

You can learn more (including the description, the online meeting URL, where the recording will be posted, and more) at the meetup event page. FWIW, the session name had to be shortened a bit as presented on the meetup site there, and even in the title here. :-)

As a bonus for you, my blog readers, I'll note that I'll be covering the CF migration and CAR features, the Commandbox CFConfig tool (which can be used for more than just "box" instances) and the CF2020 cfsetup tool (which has been shown publicly already), and more.

I'll also have a special surprise for people who "just want to compare the Admin settings of two instances without resorting to command-line tools, or hopping back and forth between browser tabs", using a free cross-platform GUI compare tool (and a simple trick in the CF Admin) which has delighted nearly everyone I've ever shown it to. And the tool can benefit you for far more than this one task. :-)

Why should one be careful about securing ColdFusion ARchive (CAR) files?

You may hear (starting today) about a new admonition (a "strong recommendation") from Adobe that one should be careful to "delete CAR files once they are used". What's that about? And why is it a concern? (And is it ever NOT a concern?) Indeed why is it a new admonition? (To be clear: the recommendation should be heeded even by those using CF versions BEFORE this update and older versions like 11, 10, and so on.)

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 what CAR files are used for, as I will explain.

[....Continue Reading....]

How can I keep CF Admin settings in sync between multiple servers or instances?

This question was asked today on the Adobe CF forums. The person had CF instances on multiple servers and lamented having to login to each CF admin to make changes that would apply equally to all instances, in particular creating or changing datasources. They wondered if in fact there was a feature in the CF Admin to "cluster" datasource definitions, like there is (since CF2016) the feature to "cluster" scheduled tasks.

I explained that there was not such a "feature" but that there were at least two options to achieve the goal. The answer was long enough (as is my wont) that I should have probably created a blog post instead. After submitting it, I decided to do just that, here (and I have tweaked here what I said, with some more elaboration and links).

Short answer: there are two tools that can help with this task, the CF Admin API (minimalist and manual), and the CFConfig tool within CommandBox (powerful and automated), as well as some seeming "shortcut" options (copying neo xml files, using symlinks, etc., which I'd advise strong caution against). I also give the CF CAR file feature an honorable mention.

For more on all this, read on.

[....Continue Reading....]

Did you know that CF2018 imports environment vars into the Server scope?

This is a hidden gem that I never saw documented anywhere: CF2018 now imports environment variables into the CF "server" scope, specifically:

server.system.environment

and java system properties into:

server.system.properties

(Thanks to Sean C for catching a mistake in the initial post.)

I learned of it last year when Pete F tweeted about it, and I assumed someone else would do a post about it, but the topic came up in a discussion today and I was surprised to not be able to find any mention of it, other than that and his mention of it in his cfdocs.org site.

And yes, Lucee had it first (as proposed initially in 2015). :-)

The feature can be useful, whether you're setting such vars when running a (Docker) container, or via JVM args, etc., and you want to be able to access them within CFML.

Solving metaspace errors, once and for all

I have a really simple solution to offer here, for a problem that has been nagging people running ColdFusion for the past few years. (I've also just filed a bug report asking Adobe to address this.) This post may also benefit those NOT running CF, especially if they have found confusing/conflicting information about the Java metaspace error and jvm argument that relates to it.

Perhaps you're getting errors referring to "metaspace" or "OutOfMemoryError: Metaspace", whether in your web sites, error logs, or even the CF Admin, and you wonder "what to do". Or you may be getting odd occurrences of blank pages, and if you look in your coldfusion-error.log you are finding such metaspace errors.

TLDR; In all these cases, the solution is simple (and may seem contrarian to some ears): REMOVE the maxmetaspace element from your JVM arguments. Indeed, I would go so far as to say everyone should simply remove it, even BEFORE you may get errors.

In the post that follows, I will explain how to remove it, including how you need to be VERY careful when doing that. You may also wonder why I recommend removing it, versus raising it. I cover that, as well as that bug report, below.

Update: I also created an abbreviated version of this post, on the Adobe CF portal, if that may interest some readers.

[....Continue Reading....]

ColdFusion 2018 update 7 released today...do you "need" it?

Adobe released update 7 for CF2018 today, and as it includes a security fix, some might think I'd say everyone should apply it.

But note first that the security aspect applies only to those running CF on Windows (and even then not ALL users of CF on Windows, as I will explain).

Then again, the update also includes a bug fix to a CF Admin, for a UI issue (related to updates, in fact), and if you need that, then you do want the fix (regardless of your OS).

So who needs it? If you need a little more guidance, I offer some clarification, as well as links from Adobe for more.

[....Continue Reading....]

CF security update (March 1 2019), part 2: further details, prevention, and more

This is my part 2 post which follows onto the Part 1, released the night of March 1, when the new CF updates were released as an emergency update. If you've not yet read that, do that first, to get some basic info and needed context for what follows.

And if you HAVE already read part 1, if it was before Saturday morning, do go back and reread it. I had added some important info that I thought shouldn't wait to Part 2, which I knew could take me a while. See especially the sections there, "A brief introduction to the vulnerability and the fix", "Should you be worried?", and "What if you can't apply the update immediately, and can't wait for part 2?".

And my apologies for the delay in getting part 2 out. For various reasons, including related to additional research work I'm doing on this exploit beyond CF, I was unable to post this then. Better late than never, I hope. Indeed, I had listed quite a lot in Part 1 that I hoped to cover in a part 2. I don't want to delay getting this out any later, so I will get done today what I can and post that, and carry over into a part 3 (or beyond) whatever remains. There are some natural breaks, fortunately. Thanks for your patience.

Following are what I cover here in Part 2:

  • More detail about the vulnerability and what was "fixed"
  • Wouldn't an antivirus package on the server detect this sort of trojan?
  • How to add further protection from it (especially if you may be unable to implement the update for some reason)
  • Considering running a security scan of your CFML code
  • Consider implementing a web application firewall
  • How to prevent execution of the files used in the attack, if they may already be on your server
  • Another benefit of applying the latest updates
  • What about Lucee?

[....Continue Reading....]

Urgent CF security update released March 1 2019, for CF11/2016/2018, Part 1

This is an urgent announcement to ColdFusion users: Adobe has released a security update today, March 1 2019, for CF 11 update 18, CF2016 update 10, and 2018 update 3.

All CF shops are urged to install this update immediately, to implement new protections against a known attack happening in the wild. It's identified in the associated Adobe Product Security Bulletin, APSB19-14, as a priority 1 critical vulnerability.

I will add that I can vouch personally for the significance of the vulnerability, as I reported it to the Adobe Product Security Incident Response Team (PSIRT), and I proposed the fix which was implemented. (I also know what was done specifically to perpetrate the attack, and the very negative consequences of what happened once the server of a client of mine was attacked. You don't want this to happen to you.) I plan to share much more in a part 2 post (now posted, but do see below for the context it builds upon).

(In the meantime, I have tweaked this part 1 since originally posting it, to share more here.)

[....Continue Reading....]

Are you still running CF11? Beware its countdown clock is ticking

For those of you running ColdFusion 11, did you know that the countdown clock is ticking toward its end of support by Adobe?

After April 30, 2019, Adobe will no longer provide any updates for CF11, so there will be no security patches or hot fixes for CF 11 after that. Of course, updates for CF2016 will indeed continue into Feb 2021, while CF2018 updates will continue into July 2023. And we could expect CF2020 (when it comes) to by supported into 2025.

How do I know this? Where does Adobe say it? And can one buy support (yes) to "buy extra time to get such CF11 updates beyond April" (no)? And what about CF11 support for Java 11 (no)? Finally, could you use help in moving off CF11 to CF 2016 or 2018? For more on each of these, read on.

(Update: I should note that Adobe did indeed offer one more update beyond April 2019, in June, when they updated CF2018 and 2016 as well for an important security update. That was a bonus. They have said there really will be no more CF11 updates, as per the original plan.)

[....Continue Reading....]

Fixing CF: "Hey, how come ColdFusion debugging output is not showing up in my localhost testing?"

This is a problem that has troubled many CF users for some years (especially as they have moved to later operating systems): they find that ColdFusion debugging output does NOT appear to them when testing using a URL with "localhost" for the domain name but it DOES appear if they use the 127.0.0.1 ip address instead.

And sure, they could change to just using the ip address, but they wonder why it fails with "localhost" and whether they can fix things so that it does? In this post, I offer the explanation and solution.

In brief, the problem happens when the OS you're working on processes your "localhost" request via ipv6 (if it makes the request as ::1), rather than ipv4 (as 127.0.0.1).
  • One option could be to edit your hosts file to force 127.0.0.1, and that should work
  • But another would be that if you knew about your localhost calling with the ipv6 address of ::1, you should be able to add that to your CF Admin "debugging ip addresses list" (or use its "add current") button. But you will find that if you try that, it will change to "0:0:0:0:0:0:0:1", which does not solve this problem. I have a workaround for that, editing the neo-debug.xml.
Adobe could fix that last problem (and I have filed a bug report, CF-4203295), but until they do, here's a workaround and explanation of things.

And this latter point, of the inability of the Admin to accept ::1--and on the matter of editing that file--is the real focus of this post.

[....Continue Reading....]

More Entries

Copyright ©2020 Charlie Arehart
Carehart Logo
BlogCFC was created by Raymond Camden. This blog is running version 5.005.
(Want to validate the html in this page?)

Managed Hosting Services provided by
Managed Dedicated Hosting