Sunmscapi.dll

2 views

Skip to first unread message

Emir Ballard

unread,

Aug 5, 2024, 4:06:36 AM8/5/24

to icetclimob

HelloColdfusion Community! It's nice to meet you all. I'm seeking out some help performing a JRE update on our CF Server. I am troubleshooting an high-priority incident with our software and hope I can some guideance toward a solution.

I know we're long overdue for a full CF Update / Server rebuild, but I'm looking for a way to get these emails sending again until we are to that point. Any help would be appreciated.

Thanks!

Phil, I may have a solution for you. Sorry that it won't be a short note, but the suggested solution should be quick for you to try. And yes, of course getting off cf11 would be best for so many reasons (including potentially devastating security vulns), to get you to either currently supported version, cf2023 or cf2021.

While updating from that java 7u55 to 7u80 might suffice to solve Phil's SMTP problem, I'll note that 7u55 was from 2014 while 7u80 is only from 2015. That may not be recent enough to overcome that smtp problem.

Until then, in your crippled state, let's see if we can get you going where you are. And you're right that updating Java should be the solution to your original mail deliver problem. Perhaps you've seen that I cover the topic in a post here.

1) But I suspect your problem is you went "too recent" in the java 8 updates, given your current OS. Let me explain: that subsequent error of "Can't find dependent libraries" for sunmscapi.dll seems to have started with 1.8.u251, especially if you are on an older Windows machine. (You didn't say what version you're on, but might it be as old as Windows 2003?) While updating your OS could be one solution, an easier solution may be just to not update the JVM "so far" as the 8u401 you went to.

As this problem started in 8u251, try 241 (one shy of that), and see if that gets you past the SMTP problem without the sunmscapi.dll problem. Granted, it's almost as bad for your JVM to be so old as that, but you're trying to get the ship back to land, not change out the engine while on a stormy sea. And no, you can't get that old 241 jvm version from Adobe, but you can from Oracle's jdk archive (the download itself will require a login, and an account is free).

And if anyone following might wonder if Java 8 is supported at all by cf11, it was, after its update 3 (and Phil said he is on update 19). For more, see my table mapping CF versions to supported Java versions.

2) As for checking if the mail delivery "now works", as you may know you can try just copying a file from cf's mail/undelivr folder to the spool. Watch for it to disappear (per your cf admin mail spool interval). To know if it worked (assuming you can't see the mail delivered), you can certainly look in the undelivr folder, but beware that if it fails again, the mail file will be put there with the same name and date it had before. Look instead to the cf mail.log to see if an error occurred, or better look to the cf mailsent log of enabled.

3) Finally, as for your updating from Java 7 to 8, don't stop at "the mail delivery works", as there may be problems that would soon arise. Again, as you may know, in updating major Java versions underlying cf, it's also important to clear out the compiled Java files that CF created from your CFML over the years from your cfml. Those are in the cfusion/wwwroot/WEB-INF as cfclasses (NOT classes). I discuss this more in a post on solving common problems when updating the JVM. See specifically my point on clearing cfclasses there. (Then again, rather than DELETE those files of that cfclasses folder, I'd recommend you just rename it--while CF is down--so that it creates a new one. You may need to use that cfclasses folder to look for evidence of a vuln as I discuss in a very long post last March.)

Related to the last point, you have one more step when making a jump in major Java versions: see the next section of my post there, on removing also the related "stubs", "rest-skeletons", and "cfc-skeletons" files, related to other aspects of compilation of things in your past use of CF with Java 7.

Again, sorry for this long missive. It's clear you'd done your own homework (and perhaps you'd already seen some of these resources), but I hope I've connected the dots for you and given you enough to resolve things on your own. If not, while you could certainly ask follow-ups here, I'll just say that I can often help folks in your situation solve the problem quickly via direct remote assistance, discussed more on my consulting page.

Charlie, thank you for your thoughtful and detailed reply. I also want to say a big thank you for the info you have shared online as I've been reviewing your site and watching a few of your webinars and this has all been extremely helpful while I was coming on board in my current role learning feeding/caring for, and eventually modernizing our CF environment. I appreciate you detailing the extra steps I should take after doing the upgrade.

This one's running on Windows Server 2008 (Which I know will need an update soon as well) I believe it's the standard edition of coldfusion as well, if that matters. I'll attempt the version you suggested shortly, after which we'll see how it goes.

It was also recommended by our mail provider to extract their server's certificate and import it into java, similarly the previous reply That's going to be the contingency plan at this point. Though I'd prefer not to risk a requirement to do that on a regular basis.

And thanks very much for the kind regards, Phil. Again, I love doing this stuff and helping folks. Such comments help keep me going (trust me, they are few and far between...in this "take, take, take" world.)

And I had started writing that paragraph above and the below, before your last reply here. I got held up submitting it because I got pulled into client calls. While some of it's moot (you didn't need to import certs), I'll go ahead and send it along here, for the sake of other readers.

First, ok being on 2008. While the one link I pointed to indicated the sunmscapi.dll happening as of 8u251 on Win2k3, that could be an incomplete discussion. I wouldn't be surprised it impacted one on 2k8 as well.

And yes, while many will suggest "import a cert" as "the solution" for this sort of issue (and it wasn't the issue for you), you will indeed find in my post (shared above) on solving problems of CF calling out via https that I make the case for that often being no longer necessary, if instead one would just update their JVM--which which beings other benefits like security updates, bug fixes, etc. But as this post shows, even that's often a balancing act. My point on importing certs is as much that sometimes people are carrying them forward into each new JVM when in fact they may find they no longer need to.

And if one DOES need to import certs, be careful not to blindly follow most steps offered online (even from Adobe), which would have you import them into the jre/lib/security/cacerts in the CF folder. That is NOT the place to put them, if you change CF to point to another JVM; instead, one should put the cert into the cacerts within THAT jvm. I discuss that more in some of those other posts I linked to.

While we're on the topic of importing certs, I'll note that there are other tools to help with that beyond java's commandline keytool. Look at the free, multiplatform tool -explorer.org/, or the certman tool (a free CF Admin extension, of which there are various versions on github--and they do work with CF11 and above, despite what some say or ask, at least for seeing what certs are there and for adding them. But there's a bug in VIEWING, DELETING, or DOWNLOADING them--and I have a fix for that that I will be pushing soon.)

This blog post is about a DLL sideloading vulnerability in the 64bit Windows version of Oracle Java. It allows any local user to inject code in Java processes of other users. At the time of writing it has been verified with the latest stable 64bit Java version 1.8.0_101 on both a fully patched Windows 7 and a fully patched Windows 2008R2 operating system. The issue is not triggered by all Java application, however Burp and the 32bit version of Angry IP Scanner have been verified to be vulnerable. I think it depends on the imported frameworks if an application triggers the problem.

Technically, the issue is that DLLs (namely sunec.dll and sunmscapi.dll) are loaded from the non-existing folder C:\Program%20Files\Java\jre[version]\lib\ext. This is most likely caused by some kind of encoding issue as %20 represents an URL-encoded space.

Following the release of final EOL java 7 (u352) today by Zulu, I've archived several Java runtime EOL (from Sun/Oracle/IBM/Zulu) from 1.3 to 1.7 here

In case someone interested in making all in one installer for windows xp... I think there is a specific post regarding XP Java 1,8 here as well here.

One of way to switch version via default system java.exe is using argument:

Thank you very much for your archival efforts!

Admittedly, I don't use or install Java all that often, but it does have its uses, so it is wonderful to have multiple EOL versions available in one convenient collection.

I'm genuinely surprised Java 7 was supported for that long...from what I recall, the last (latest?) known Java 8 release doesn't even work/function in XP properly (I believe 8u152 is the final version of Java 8 that installs properly and works as it should in XP, while others install but fail to work).

Thank you very much for your archival efforts!

Admittedly, I don't use or install Java all that often, but it does have its uses, so it is wonderful to have multiple EOL versions available in one convenient collection.