http://coldfusion.com logo
Join Slack
Powered by
It's me again :wave: What is the story behind all ...
# box-products
j
It's me again šŸ‘‹ What is the story behind all the `bundle.jar'`s in the 
felix-cache
folder? More specifically I'm getting some lit up with some vulnerabilities that I was hoping to (and almost did) avoid with box-light in this folder: 
/root/.CommandBox/engine/cfml/cli/lucee-server/felix-cache/bundle56/version0.0/bundle.jar
b
@Jason Ryan Those are copies of the jars in the bundles folder. Felix copies them there as a cache. But it renames them just to screw with you
You can open them and look in the manifest to see what jars they are
But deleing them won't do any good, Felix will re-copy them from the bundles folder again
And by "open" them, I mean unzip them. 7Zip IS super useful as you can just right-click on a jar and use the context menu to open it
j
Ah I gotcha. I found a "workaround", although I'm not 100% sure how it works. I put the Lucee_Extensions ENV variable as the last step of my Dockerfile, so that all the box installs run without that set. Seems like Box now doesn't install these extensions at build time, causing the "bundle56" folder to no longer be there, and thus at rest my container doesn't get flagged for jackson.datacore vulns hah. There were like 50+ criticals and 100's of high's
b
Yeah, that's not really a fix at all since the jar is still totally there at run time šŸ™‚
I'll caution, that will also slow down your docker deploys since the server isn't fully warmed up
j
Exactly. Gotta do what you gotta do for Compliance in the meantime lol
I've noticed it taking a minute longer to spin up
b
So you're really just sneaking in the bad guy past the bouncer by using the back door after the show has started šŸ™‚
j
Pretty much hahah
I'll have to look into a more long term solution next week
b
If this security is important to your company, I HIGHLY recommend reaching out to @micha and @gert to discuss possibly sponsoring the development work to update the library JaxB dependency.
If it comes from an extension, it can be released without an update to the Lucee core
Also, have you looked at just not installing that extension in case you don't use its features?
j
I want to say it's either the pdf extension or hibernate
b
Have you looked in the admin?
There is a bundles page that I think will tell you exactly what extension is loading it
j
Unfortunately I determined we need all the extensions we're using. I started with a light version and built it up from there
Oh good call I'll check that out
b
Look at the very top link in the nav in the server admin
It's called 
Bundle (jar)
under 
Info
j
Sweet, found it
Looking through it
Hmm I found jackson-databind but it's not showing as coming from that 
bundle56
.jar like the vulnerability scanner was (turns out I'm manually copying that in through java sdk includes in app.cfc)
b
What is the bundle name of that jar??
Look in 
META-INF/MANIFEST.MF
It will tell you exactly what it is
I see several bundles with the word "xml" in my Lucee admin, but one specifically that mentions Jackson
j
Your saying look in 
bundle56/version0.0/bundle.jar
?
b
Yes
Unzip it like I said above
Otherwise, you can stare at the outside of the jar all day long and you've have no clue what's in the box šŸ™‚
I'm rather confused however if your security scan found something in the felix cache that it didn't also find in the bundle dir, because so far as I know, all jars are in both places
So if your scanner is finding all the same vulns in two jars, you can just forget about the one in the felix cache for now since it's just a copy of the one in the bundles dir
j
These are local .jar's on my computer that didn't get packaged into the container and hosted
So they're pretty much irrelevant
b
Whatever-- I don't care where they are. The questions I'm asking are all still the same, lol
j
Ya exactly lol, I'm hoping to unzip that .jar soon
b
If they're irrelevant, why are you asking about them?
Also , the numbers on the cached jars mean nothing
Just because a random bundle is "bundle56" on one Lucee install doesn't mean it's the same as bundle56 on another Lucee server
Are you saying you're looking at some random cached bundle of your local PC's Lucee install that just has the same number on it as the actual jar that was the issue on a prod server's Lucee install??
j
Sorry to confuse, I'm looking at the exact same container that has that bundle56, I just pushed it up but have it running locally too
b
OK, wherever the bundle is that is causing the issue, unzip THAT bundle and see what the bundle name is
And don't assume that Felix has re-used the same number in its bundle cache between to server. Lucee wipes the cache on every start anyway I think
org.apache.commons.Collections
And you're saying that specific jar is hitting flags for JaxB vulns?
Version 3.2.1 is the latest version of that library
OK, there's no way you're looking at the right jar
Did you unzip the jar on the server where the scan was run (without restarting the server!)
Also, sharing that picture could have saved us all some time because the freaking bundle name and version are right there the whole time!!
com.fasterxml.jackson.core:jackson-databind
j
This was done running the same exact container that's hosted. Its just an image sitting in ECR that I pulled down locally to run
b
That... doesn't answer any of my questions ...
j
This was the bundle that I unzipped 
/root/.CommandBox/engine/cfml/cli/lucee-server/felix-cache/bundle56/version0.0/bundle.jar
and setn over the manifest
b
holy cow that lib is old!
Copy code
Jul 17, 2014
This was the bundle that I unzipped
No, it wasn't. I'm betting that server was restarted since the scan, the felix cache was deleted and re-created with different jars getting the same name
The manifest you sent was for an apache commons lib
j
But yeah something probably got messed up from spinning up the container
I see what you mean now
b
I don't think you're listening to me... I believe you that the jar you opened had the number 56 in the file name, but I'm saying I don't think that was the jar that was there when the scan was run
j
Yeah I got that
b
Like I said above, Lucee deletes that entire folder every time it starts and it's recreated with random names again
j
Sorry man it's late on a Friday šŸ˜“
b
Regardless, I'm having trouble figuring out which bundle that is šŸ¤”
j
I should probably call it a day lol
I'll definitely grab the right bundle on Monday
b
Your tool reported the maven group:artifact but it doesn't seem to match any of the jars I see, and OSGI's bundle names can be different
Also, Lucee tends to package up older libraries in its own bundles with changed names, making things even harder to trace down
j
I see šŸ˜•
But yo I l definitely earned a thing or two here, apologies for my slowness, I appreciate you. Hope you have a nice weekend
b
Ok, post back when you can confirm the bundle that's getting caught in the scanner
The bundle name in there should help us track down the ext
j
Sounds good
b
If the scan is running on a Docker container which is then shut down and saved, you need to mount the drive without allowing the container to start.
But again, all the cached files are just copies of a jar file in the bundles directory, so in theory you should be having all the same warnings coming up for two different jar files (which are basically copies of the same jar). You'll make your life easier if you focus on the one in "bundles" as it's name will not be generic and it will not get deleted ever time Lucee starts.
j
@bdw429s As promised, an update on this matter. The vulnerability is coming from this jar: 
root/.CommandBox/engine/cfml/cli/lucee-server/bundles/*org-lucee-ehcache-2-10-3.jar*
. Turns out it's coming from the installation of 
HibernateORMEngine v3.5.5.84
b
nice
j
Interestingly enough this doesn't appear (at least to the vuln scanner) that this particular .jar gets included in the regular Lucee bundles folder, only in commandbox, despite the same HibernateORMEngine extension getting installed on both
b
You'll notice the bundle name starts with 
org.lucee
even though it's ehcache-- that's one of those repackaged bundles Lucee makes
j
Ah I see
b
Yeah, there's no reason at all why two Lucee installs would be different really
CommandBox doesn't do anything special with Lucee at all when we bundle it. It's just the normal lucee jar downloaded right from Maven
And any extension or bundle downloading or installation that Lucee does in the CLI works the same as it would for any Lucee server
Now, there are many things that COULD affect it such as ā€¢ certain env vars ā€¢ certain system properties ā€¢ whether the internet is accessible ā€¢ whether Lucee boots up fully without being interrupted but those would all the factors of the environment Lucee is running int
So one thing I'm a little curious about is 
com.fasterxml.jackson.core
was reported as the vulnerable package, but I don't see any class files with that path anywhere in the ehcache jar
Are there perhaps more than one hit on your security scanner for different vulns on different jars and you're crossing the wires here?
j
Interesting. Good info. I'd have to test this again but I think that at one point I noticed that .jar doesn't get included without certain box packages. I'm installing commandbox-migrations, commadnbox-dotenv, and commandbox-cfconfig
Hmm lemme take another look
b
I think you're confusing CommandBox modules with jars
None of those CommandBox modules install any jars that I'm aware of, and they have nothing to do with Lucee extensions or bundles
j
Ah it could be just that it didn't install any of the LUCEE_EXTENSIONS until a box module was installed
b
Now, that said, Lucee will download bundles on-demand when you try to use them, so it's possible simply defining a datasource for example could lead to a bundle being downloaded.
j
Got it
There are hundreds of vulns too and just about all of them point to these same two places
b
Looking more deeply at that ehcache jar, I do see some references to Jackson libraries
I think the classes are embedded in different places inside of the ehcache jar
j
WIthout it, I only have 2 & 9
b
Regardless- while this reserach is interesting and helps tell us how out of date the jar is, none of this changes what you need to do now. ā€¢ either find a way to not install that extension/bundle if you can ā€¢ and put in a ticket to the Lucee bug tracker is there isn't one already for them to update those jar versions!
Also, keep in mind, the existence of a vuln doesn't mean there is a surface area that allows the attack. It would depend on what the vuln is, how it is hit, and whether that is even exposed in Lucee's usage of the jar.
j
Ah yep that's true. I've made some notes on our vuln tracker for such instances that look bad but there's actually no attack surface. In either case, I think I have a solid workaround to avoid its installation. I'll also make sure the Lucee bug tracker has this in its collection
Thanks again for helping me navigate this!
b
Version 
2.10.3
of 
net.sf.ehcache:ehcache
is from 2016
So yeah--- embarrassingly old šŸ˜•
Unfortunately Lucee's small budget doesn't give them a lot of time to keep up with the hundreds of open source Java libs they bundle
Which is why I suggested you help sponsor the update šŸ™‚
It looks like the 2.x series was the last of the 
net.sf.ehcache
and the 3.x series changed to 
org.ehcache
so it's likely a non-trivial amount of work to update Lucee as there are breaking changes in the API for sure
j
Ah yup, understandable. I'll chat with my CIO and let him know that sponsoring the development is an option, so we'll see šŸ™‚
3 Views
Open in Slack
PreviousNext
Powered by