http://coldfusion.com logo
Join SlackCommunities
Powered by
anyone know if this affects ACF? <https://nvd.nist...
# adobe
r
anyone know if this affects ACF? https://nvd.nist.gov/vuln/detail/CVE-2022-42889
have you seen this yet @foundeo?
f
yeah, I did see that, but I am not sure if it is used directly anywhere…
I don’t see commons-text-x.y.z.jar in CF2021 for example
😅 1
also seams like to me if you allow untrusted input into commons text, there are a lot of dangerous features, that may not necessarily cause code execution (like the CVE), but can read files, do xpath, etc: https://commons.apache.org/proper/commons-text/userguide.html
r
is there a way to check if that jar is loaded anywhere? like in a dependency of a dependency?
would seeing if we could initialize it through createObject prove that? or is it possible its used but not in the classpath for us to use?
f
not necessarily prove it, but it would be a good check
if you had some code that used javaloader to load the jar, that creates its own classloader, so it could still be used like that but would fail the createObject test
not sure how accurate this would be, but if you are on linux you can run 
lsof -p PID
where PID is the process id to see the open files of the process
b
@ryanguill Out of curiosity, do you have reason to believe Adobe uses the Apache Commons Text library or is this just a random CVE you came across?
I've never even heard of that lib, let alone in the context of ACF so I I'm fairly sure unless you're using that library yourself, it isn't in the mix.
r
yeah, just came across it - I know it uses other apache commons jars
👍 1
b
Running
Copy code
createOBject('java', 'org.apache.commons.text.lookup.StringLookup')
on Trycf against both CF engines can't find the class, so it's at least not in the system classloader.
👍🏼 1
Well, always worth checking! 😉
💯 1
Years ago, someone (perhaps @foundeo) had worked on creating a list of all the Java libs bundled with CF and Lucee. It would be really nice to revive that effort (especially now that they are all using OSGI) and then cross ref that with one of the many vuln libraries out there.
Maybe if I can find some free time... 🤣
s
If you do 
find . -name '*.jar'
in a CF/Lucee installation, that should give you a list of all bundled JARs. Then you can pipe that through 
tr '\n' ':'
to get a classpath string. Then you can pass that to one of the various NVD checking tools.
https://github.com/jeremylong/DependencyCheck is the "standard" one most other JVM-based tools use.
We were using a Clojure wrapper around that at work for a while (we've switched to another tool now that uses the same NVD machinery under the hood but provides a report that shows how transitive dependencies are pulled in and whether there's a updated library available without the CVEs).
That `find`/`tr` command is how I produced the lists of CVEs for ACF/Lucee back when there was all the fuss about log4j CVEs -- but I suspect those posts are lost to time/free Slack limits at this point.
b
Lucee makes things a bit of a pain the way it zips up jars inside of jars inside of jars, but so long as you have a warmed up server to run it against everything should be unpacked into the bundled directory at that point.
s
(Can I just say, once again, that adopting OSGi was a bad decision)
💯 1
z
you can see a list of all the bundles in the lucee admin
b
That's not very useful since Micha repackages common libraries under another namespace such as 
org.lucee.foo
instead of 
org.apache.foo
. You'd need to introspect the actual class names to know what's really in the bundle.
z
as we upgrade libs, I have been switching to apache libs and / or asking upstream libs like zip4j to add the required osgi metadata... we are improving
👍 1
s
So much extra pain and work for a bad decision in the first place...
z
osgi allowed us to address log4j without half a year of engineering effort
s
We addressed the log4j stuff in minutes at work. But, hey, if you think it would have taken the Lucee team six months -- after them spending years of effort migrating to OSGi in the first place and basically putting the entire project on hold while they did it! -- that's more of a comment on the Lucee team than OSGi, trust me.
a
🍿
😁 2
Open in Slack
PreviousNext
Powered by