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?
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.)
But here's some good news: Amazon has recently released a new free JVM (java virtual machine) implementation based on the OpenJDK specification, called Corretto. In this post, I want to share some news about it. (Off the bat, let me tell my friends on any Linux flavor other than Amazon Linux 2, this is not yet available to you. For now it is only available for Amazon Linux 2 as well as Windows, MacOS, and as a docker image. Other Linux flavors are due in Q1 2019.)
For much more, read on.
- Regarding Java 8, did you know that Oracle will no longer offer free updates/security patches for Java 8, if used for production (NOT just "commercial") purposes beyond Jan 2019? After that, you must pay them for support/updates (including security updates). For more on why this is NOT just about "commercial" use, see below.)
- Regarding Java 11, the next major release, did you know that the Oracle Java 11 JVM cannot be USED at ALL for PRODUCTION purposes, without paying for it?
- Finally, while Oracle will be offering a free openJDK implementation (which CAN be used for production, for free), did you know they will only be committing to supporting/updating their Oracle Java 11 openjdk for 6 months after release, leaving subsequent updates to the community of contributors?
For more, including why this may have significant impact on your use of Java-based applications, as well as alternatives that may exist for you going forward, read on.
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).
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.
- 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.
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.
If so, I have some very good news--and some not-so-good news. (Some may know that you can find this info also by running the CFC Explorer--more on that in a moment.) The unfortunate news is that it's not yet COMPLETELY documented, but it's still a good start.
Anyway, I have contributed several blog posts (some really article-length, and all written as standalone "articles", so I am referring to them that way here, and in my "articles" page).
I wanted to point to them out in a post here as well. I was also torn about whether to post them in their entirety here, whether before or after posting them there, but for now, I have posted the content only there.
And unlike previous Adobe cfdevweeks, which often involved non-Adobe presenters (including myself), this year's sessions were all from members of the Adobe CF team, on these topics:
The first problem was introduced in the CF2016 installer released in Dec 2016, and any after that, where Adobe has literally removed the library used for the calendaring, but you can add it back, as I discuss below. (If you install or installed CF 2016 from the original installer in Feb 2016, you won't see this problem as it wasn't removed then.)
The second problem was introduced in those two named updates, and was fixed in the very next updates (CF11 update 13 or CF2016 update 5). And of course, this could also happen if you're moving to CF11 or 2016 for the first time, and someone else had "fully updated" those to that update level before you started testing against it.
If you'd like to know more, read on.