Does Lucee support secure archives, like Railo did with .ras files?

dev support
1

Hey guys!

I clearly remember Railo offering not only Railo archive (.ra) files, but also a secured (encrypted) version, which had the extension .ras instead of .ra.

This was for when you didn’t want recipients/users of an archive to be able to just pull it into any ZIP program and look at the contents easily. For example, code you were selling and didn’t want reverse-engineered, other sorts of sensitive code, or similar situations where you wanted people to be able to use the code in the archive (via a mapping), but you didn’t want them to be able to (easily) see or read it.

I find no equivalent in Lucee. The admin lets you make Lucee archive (.lar) files, but there’s no apparent secure option (which would be a .lars file extension, I assume).

I’d really love to have this functionality. It’s a big step down from Railo which had it, and it’s very useful!

Am I missing something? Does Lucee have this capability and it’s just not mentioned in the admin (or anywhere on the web that I could find), or something?

I did find a commercial product that is apparently distributed as a .ras file and the instructions say to assign it to a mapping in Lucee (yes, Lucee not Railo), so can Lucee still use “legacy” Railo .ras files? If so, how can I make a new .ras file for Lucee to use? Please don’t tell me I have to use an old Railo version to make one, that’d be silly!

Also, in Railo and in Lucee (if it does support it), what’s the mechanism of securing the file? Does it use ZIP encryption (which if I remember right is weak), or some other, better method? Is a password needed when creating the secure archive file? How does it work behind the scenes?

Can anyone give me answers? Thanks guys! Here’s my stack info:

OS: Linux (5.4.59) 64bit
Java Version: 11.0.11 (AdoptOpenJDK) 64bit
Tomcat Version: Apache Tomcat/9.0.11
Lucee Version: 5.3.6.61

2

Aren’t these files simply zipped containers (with aes encryption or not) and having the file extensions renamed from .zip to .whatever?

3

Aren’t these files simply zipped containers (with aes encryption or not) and having the file extensions renamed from .zip to .whatever?

I used the lucee admin to create a .lar file, then I changed the extension to .zip, unzipped it into a temp directory, then I used the 7za command line tool to re-zip it three times:

  1. non-encrypted version
  2. AES-128 version
  3. AES-256 version

I then renamed each to have the .lar file extension, then tried to assign each to a mapping in the lucee admin.

Only #1, the non-encrypted version, worked. Both AES versions resulted in the archive field in the admin turning red, on both the summary (list) and detail mapping screens.

I then tried #2 and #3 again after renaming the file from a “.lar” extension to a “.lars” extension, just in case the same naming convention as Railo (“.ra” and “.ras”) was followed by Lucee. It didn’t work, still came up red in the admin. Same result for trying the “.ras” extension, red fields in the admin.

So it appears one can’t just make their own AES ZIP file, rename it to .lar (or .lars or .ras), and expect it to work.

Railo provided options in its admin panel to select either a normal (.ra) or encrypted (.ras) file when making the archive. No external tools were needed, although I don’t mind using them if it means I can get this working in Lucee.

So does Lucee support encrypted archives for mapping, or not? If so, how can it be done?

4

Also, if it helps, here’s the page I was talking about where a vendor gives instructions for adding their secure archive file with “.ras” extension to a mapping in Lucee:

https://support.icthrive.com/hc/en-us/articles/115012060627-Railo-Lucee-Configuration#mappings

This implies that Lucee CAN assign secure archives to a mapping, apparently if they were made by the Railo admin (or some other method I’m unaware of).

Is that web page incorrect, it really won’t work with Lucee, and they simply haven’t updated that section of their documentation since they wrote it for Railo?

Any ideas anyone? Thanks!

6

Perhaps

7

That video discusses the deploy directory and how Lucee automatically picks up and uses stuff placed in there, but it’s all regular, presumably non-secure “.lar” files and there’s no discussion of secured archives or encryption.

8

Here’s the error message you get in the console when you try to make a mapping with an encrypted (zip with AES) archive:

OSGi->invalid CEN header (encrypted entry)
java.util.zip.ZipException: invalid CEN header (encrypted entry)

So either Lucee doesn’t support encrypted archives like Railo did (why would they drop this functionality?) or there’s nowhere to enter the password, or there’s some other problem.

9

I think this thread post will shed light on what you are trying to do.

https://groups.google.com/g/railo/c/tzEyfhNIlp8

This is how Ralio used to do this, there was no code, just a button.
https://www.screencast.com/t/gOStkZPnM

You could then go look at the source code

And then if you want to build a big flaming source secured project, code it up.

1 Like
10

I’m not very sure, but looks like this secure archives have beem removed from lucee. At least Administrator.cfc only have .lar archives creation:

As these would need a password for decrypting, don’t know how Lucee would know it.

I think that functionality may have been
removed, because encryption for such archives in my personal opinion don’t really make sense in terms of security. That’s because these arvhives would need to be compiled anyway to java classes by the cfml engine,which can then be found in the web-inf folder as compiled code, and then available for decompliling. Such security for hiding code isn’t really that strong.

1 Like
11

Very interesting! Thanks, Terry and Andreas.

Terry’s video of the Railo admin hints that “secured” Railo archives were actually just sourceless archives, not encrypted, as the checkbox for “secure” has explanation text indicating simply that the source won’t be included, nothing is said about encryption.

I’m guessing that in Lucee, this “secure” checkbox was changed to a clearer and more explicit pair of checkboxes about including source files (CFML, CFC) and including other files (CSS, JS, etc.) instead of lumping them both together and calling it “secured”.

This suspicion makes sense because I never recall having to enter a password back when I made “.ras” files, which makes no sense if they were truly encrypted.

Andreas, your comments were great too, thanks. You said that Lucee has to have class files to use no matter what, and thus they can be grabbed and decompiled, yielding no more effective overall security than a simple sourceless archive file has. Good point.

So, I’m going to assume there apparently never really was encrypted archive support in Railo, just sourceless archives, with the misleadingly-named “secured” button changed to a clearer and better-worded pair of checkboxes in the newer Lucee admin.

Of course if anyone knows otherwise, please do say so.

Thanks guys, you were a big help!

2 Likes
12

I do recall @micstriit or @Gert speaking at a CF conference years ago and talking about an ability they were building (into Railo at the time) to actually sign class files so a secure key had to be present, and if someone tried to run any unsigned code on the server, it wouldn’t work. This was for a prod deploy to prevent any sort of RCE. However, I have no idea if that idea ever was completed or made available and I’m not sure it was related to .ra files at all. I think you’re most likely correct that the only “secure” part simply means the CFML was compiled to class files (which could be decompiled back to java code, but not back to CFML code (easily). The source code to Railo is available on Github, so you can always just go and look at what the admin used to do.

I will also add a warning that from time to time, Lucee updates change the bytecode of the compiled class files and compiled class files from an older version of Lucee will no longer work. This means that any library you create where you want to distribute a compiled version of it, basically must be re-created for every release of Lucee and your customers will be dependent on you to keep providing them new versions every time they update their server. This is a total pain in the butt, and one of the reasons we stopped trying to do this with our commercial Ortus libraries. It just wasn’t worth the effort and there were easier ways to keep honest people honest.

1 Like
13

Even Adobe’s base jars are not “secure”, which comes down to trusting people to do the right thing.

As for framework libraries, most if not all constantly take work to keep “up to date” which becomes a security concern.

My suggestion, if you can you should convert only the needed parts of your applications dependent frameworks to ColdFusion code. once done you will eliminate a lot of security problems and its easier to maintain only your single block of code vs trying to have everything work nicely with xyz, even if xyz is based upon the same underlying technology (Java).

1 Like
14

I will also add a warning that from time to time, Lucee updates change the bytecode of the compiled class files and compiled class files from an older version of Lucee will no longer work.

Great info bdw429s, I didn’t know that, thanks. I assumed “bytecode is bytecode” and the .class files would work almost indefinitely despite version updates. As far as I know, this is correct for Java itself (usually really old class files can run on the newest JVMs), but it sounds like there’s a Lucee-level, not a Java-level, issue preventing such long forward-compatibility. Interesting and good to know.

Even Adobe’s base jars are not “secure”, which comes down to trusting people to do the right thing.

Good point Terry_Whitney. At some point, an unencrypted .class file has to exist on the server for it to be run and used, and at that point someone could grab it (from the disk wherever it’s temporarily put, directly out of memory, whatever).

I’ll just forget about the whole encrypted classes thing, and be content with a sourceless archive, because from what I hear, decompiling .class files is not easy or fun, and should be sufficient protection for my needs.

As for framework libraries, most if not all constantly take work to keep “up to date” which becomes a security concern. My suggestion, if you can you should convert only the needed parts of your applications dependent frameworks to ColdFusion code. once done you will eliminate a lot of security problems and its easier to maintain only your single block of code vs trying to have everything work nicely with xyz, even if xyz is based upon the same underlying technology (Java).

I’ve never used any of the Lucee/CF “frameworks”. I just make my own which suit my needs perfectly, and I obviously have all the source code and know it 100% because I designed and wrote it, and I never have to worry about any third-party framework update (or other) issues like you describe. It’s not for everyone, but it’s really nice. My apps are 100% my code, right on top of Lucee, no third-party framework middle layers to worry about.

Thanks for all the info guys, it’s been a real help! It’s nice to know that encrypted archive functionality WAS NOT removed when Railo was forked into Lucee, rather it was just a change from one checkbox to two more granular (and thus useful) checkboxes that were labelled better.

1 Like
15

The bytecode isn’t nearly as low level as you’re thinking. Even though it’s “bytecode”, it still represents the java code equivalent that your CFML is turned into which includes many hard dependencies on the exact internal APIs of Lucee

  • The PageContext class
  • The Config classes
  • Any of Lucee’s internal services/Utils

So if there is a LuceeService class inside of the Lucee core with a method called luceeMethod() with a specific set of params and the class file for your code calls that as part of its execution, changing or removing that method signature from Lucee’s core makes the old class file/bytecode now binary incompatible. Lucee’s internal compiler will always create bytecode that matches the internal method APIs for its current version, and since those are an undocumented implementation detail, Micha can and does change then whenever he needs, even in patch releases.

16

Lucee’s internal compiler will always create bytecode that matches the internal method APIs for its current version, and since those are an undocumented implementation detail, Micha can and does change then whenever he needs, even in patch releases.

Great information bdw429s, thanks! Very important to know.

This is a total pain in the butt, and one of the reasons we stopped trying to do this with our commercial Ortus libraries. It just wasn’t worth the effort and there were easier ways to keep honest people honest.

Yes, I can imagine it’s a minor nightmare to keep distributing new sourceless archives to customers with every Lucee version upgrade, or even some patches. Not worth it.

17

So what IS the best practice Lucee way of distributing source securely to production servers (or client servers)

I would imagine there isn’t one.

What is current advice?

18

As we’ve been discussing, “secure” is a relative term. You can create the archives as described in the thread above, but it’s worth noting it’s obfuscation at best.

I was hoping Micha or Gert would chime in on the code signing project I recalled them announcing years ago, but I really don’t know if it was aimed at securing the bytecode itself or just limiting what code the engine would run, which are two different concerns.

To be honest, I think CFer’s get off on too much of a rabbit trail here. Trying to “secure” your code is a pain, makes your builds and deployments more brittle, and provides limited benifit. I’d spend the $$ on a lawyer to write a good contract so you can sue the pants off any clients who try and steal your trade secrets. That’s just my advice though, :wink:

1 Like
19

If its your production servers, rsync… :smiley:

Everything else,

If you are trying to sell the software, update early, update often and require a valid account to download.

You can do what some do and provide it opensource, but then provide enterprise service agreements and support. This model works well for many.

The other is require contracts and large purchase orders in order to ever receive more than a “demo” of your software.

Lastly, PaaS, which can be as simple as a google , azure, or aws image or building your own API service that requires some critical functions to use.

1 Like