tracker issue : CF-3818547

select a category, or use search below
(searches all categories and all time range)

Stop Encrypting the Administrator Code

| View in Tracker

Status/Resolution/Reason: Closed/Won't Fix/

Reporter/Name(from Bugbase): Adam Tuttle / Adam Tuttle (Adam Tuttle)

Created: 09/04/2014

Components: Administrator

Versions: 11.0

Failure Type: Enhancement Request

Found In Build/Fixed In Build: CF11_Final /

Priority/Frequency: Trivial / Unknown

Locale/System: English / Platforms All

Vote Count: 24

Over the years, the majority of security issues for ColdFusion have been somewhere inside the /CFIDE/ and /CFIDE/Administrator/ folders. It's time to stop encrypting these. What is the point, anyway? If you decrypt them, then the community can provide feedback and patches to make them even more secure.

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	3818547

External Customer Info:
External Company:  
External Customer Name: Adam Tuttle
External Customer Email:  
External Test Config: My Hardware and Environment details:



+1. In CFML code, we're more likely to find problems than your lot are.
Vote by External U.
11111 | September 04, 2014 09:38:47 AM GMT
+1 "I'm a leaf on the wind. Watch how I soar." - Wash, Serenity
Vote by External U.
11112 | September 04, 2014 10:26:06 AM GMT
+1 Please make this possible.
Comment by External U.
11099 | September 04, 2014 06:19:29 PM GMT
+1 - Couldn't agree more with Adam and Adam that the CF Administrator code should not be encrypted and that the community is more likely to find issues and fixes than Adobe are. Closing it without comments and a reason of "As Designed" is complete BS. The whole point of the report was challenging the way it is been designed, so in my mind that is not a valid reason for closing the ticket. Please either re-open and make the change as requested or provide a reason as to why it shouldn't be done.
Vote by External U.
11113 | September 09, 2014 07:26:42 AM GMT
Shame and embarrassment at the state of the code are the only reasons I can see to not do this. Adobe CF is not that special, and can not continue to treat its users poorly. Let's see what's in there, and get it fixed.
Vote by External U.
11114 | September 09, 2014 07:55:53 AM GMT
+1 Seems like a reasonable request. I won't impugn your integrity or your skills or your goals. If you ignore the tone of the comments here and just evaluate it with respect to the merits, seems like you should reverse your decision. Adam C makes a great point when he says the community is capable of helping here. And Adam T has done plenty to help the language and community int he past. Opening up the access shouldn't hurt your business model while at the same time getting the possibility of better tools for your customers. That can only help.
Vote by External U.
11115 | September 09, 2014 08:27:27 AM GMT
Make the code visible so we can help debug it.
Vote by External U.
11116 | September 09, 2014 08:36:52 AM GMT
+1 "As designed"? Is that even a reason in this case? When the community that sails your ship presents a issue or resolution, doesn't it make sense to at least respond? There are great points being brought to the table in regards to why this request would be positive. In the back of my mind I read this action as "we're not confident in this being un-encrypted and we don't want a potential security hole to come to light (if there are any. (ya, there probably are.)); and we're so arrogant that we know best for our community. Who needs explanations." Which is of course bitterly absurd. We test, beat, batter and help fix every other end of the language over time to help you guys. Might as well make it the whole lot right? Because if the admin is pieced together in any related way like some other bits of CF, it'd do everyone a favor to be able to analyze and fix any issues. We wouldn't have to wait 8 months for a patch either. But that's none of my business. Wait. ;)
Vote by External U.
11117 | September 09, 2014 10:59:47 AM GMT
25 characters or more 25 characters or more Take one down Pass it around Encrypted code makes me frown I agree the source should be available somewhere to view and audit.
Vote by External U.
11118 | September 09, 2014 11:09:57 AM GMT
"Withdrawn" "As designed" Seriously wtf? It has been proven time and again that not only are you guys not good cfml developers, you are not good web developers period. This really sounds to me like you are afraid that if you unencrypt it then the world will see how true this statement is. Well guess what, the bad guys have probably already got the unencrypted version of this, so why not give the good guys a chance to look over the code and fix the problems before we have yet another embarrassing breach. The sheer arrogance of closing this ticket like that without even offering a reason is beyond the pale.
Vote by External U.
11119 | September 09, 2014 11:38:22 AM GMT
AsDesigned? The BUG here is in that design. In this day and age - with increased security exploits and the benefits of more eyes on the source code - you really need to CHANGE that design to fix this "BUG".
Vote by External U.
11120 | September 09, 2014 07:46:34 PM GMT
Makes perfect sense to me...
Vote by External U.
11121 | September 10, 2014 12:10:57 AM GMT
AsDesigned and Withdrawn both seem like invalid for closing this. Of course it works as designed, but thats why it is a enhancement request and shouldn't withdrawn be something the reporter does. There should be some reasoning explaining why this doesn't deserve to be implemented.
Vote by External U.
11122 | September 10, 2014 12:47:58 AM GMT
Thank for all the attention and feedback on this issue. This is issue will be reopened and evaluated internally. Any further update on the issue will be communicated through the comments here.
Comment by Rakshith N.
11100 | September 10, 2014 07:24:33 AM GMT
It would certainly be nice to know the code powering the admin. Even though we follow the lock down guide, everyone should be able to review all the code that runs on their servers.
Vote by External U.
11123 | September 10, 2014 08:16:10 AM GMT
I could not agree more with this statement from Adam. "If you decrypt them, then the community can provide feedback and patches to make them even more secure." Please decrypt.
Vote by External U.
11124 | September 10, 2014 09:16:33 AM GMT
+1 for decrypt. Better to fix the bugs/security issues then to locked down access to it
Vote by External U.
11125 | September 10, 2014 12:25:30 PM GMT
It would allow a good community review to find any security holes.
Vote by External U.
11126 | September 10, 2014 02:05:30 PM GMT
I wrote about this in the beta forums before. As the source code was stolen from Adobe anyway, it does not make sense to hide the source from your supporters in the CF community and leave it only available to those who are trying to exploit it.
Vote by External U.
11127 | September 24, 2014 02:16:53 PM GMT
+1 - It should use the Admin API.
Vote by External U.
11128 | October 01, 2014 12:54:38 AM GMT
Agree totally. There is no advantage to doing this any more, if there ever was.
Vote by External U.
11129 | January 01, 2015 03:42:13 PM GMT
I believe the community could improve the admin, as well as extend it. Encrypting the admin makes no sense any more.
Vote by External U.
11130 | July 15, 2015 11:51:25 AM GMT
So anyway Rupesh... you've had the best part of a year to mull this over, and here we are in the CF12 pre-release phase. "Any further update on the issue"...?
Comment by External U.
11101 | July 15, 2015 06:13:40 PM GMT
Oops... "Rakshith", rather than "Rupesh". I picked the wrong procrastinator ;-)
Comment by External U.
11102 | July 15, 2015 06:15:03 PM GMT
I would welcome an opportunity to help Adobe improve admin security by having the ability to access unencrypted code.
Vote by External U.
11131 | July 16, 2015 12:18:10 AM GMT
+1 - I'll add my vote to this list. Please decrypt the Admin.
Vote by External U.
11132 | July 23, 2015 08:59:20 PM GMT
I've been asking for this for years. Considering there is an Admin API, and the Admin API should have 100% parity with the Admin, there is no need to encrypt the admin.
Vote by External U.
11133 | July 24, 2015 07:26:26 AM GMT
+1 ... More eyes can only be a good thing.
Vote by External U.
11134 | July 26, 2015 12:44:40 PM GMT
+1 to Adam's question. "Any further update on the issue"? +1 to Ray's comment: "Considering there is an Admin API, and the Admin API should have 100% parity with the Admin, there is no need to encrypt the admin." Thanks!, -Aaron
Comment by External U.
11103 | August 25, 2015 09:22:09 PM GMT
Two months later now. Adobe?
Comment by External U.
11104 | September 16, 2015 04:58:58 AM GMT
While we appreciate the request for decrypting the administrator cfm files from a security review perspective, the recommendation from the security group at Adobe is to not ship decrypted administrator cfm files. The reason for this that we (Adobe) would like to be full control of the changes that are made to these cfm files. Decrypting the source files will potentially lead to cfml developers at our customer locations make changes to the code without understanding the security impact of the changes that are made. At Adobe we take security very seriously. To address the potential security issues with the administrator code, we will be arranging for a private security audit of the entire source code and any other measures as required.
Comment by Rakshith N.
11105 | September 18, 2015 04:58:09 AM GMT
OK, in that case how about you open source CFAdmin as a project. That way the community can help with bug fixing and security concerns, and when you come to build CF for release, you can encrypt the files you ship. Deals with both requirements.
Comment by External U.
11106 | September 18, 2015 05:09:24 AM GMT
Sorry Rakshith, I find that response unacceptable. There are a million and one ways I can make my server insecure. I could drop a vulnerable unencrypted file into the CFIDE folder. I could modify query.cfc (currently provided unencrypted) to not use query params, making all of my script queries that use it vulnerable to SQL Injection. Encryption is not the solution to this problem. Education is. And OF COURSE if someone modifies the code in their CFIDE folder they are liable for any vulnerabilities they introduce. Granted, Adam Cameron's proposal for an alternate path is... reasonably acceptable. If you were to publish the unencrypted code, say, on GitHub; and accept pull requests that improve it in meaningful ways (security, performance, usability, etc)... and then encrypt that to be included in the installer... I guess I will grudgingly accept that as a (poor) solution to this request.
Comment by External U.
11107 | September 18, 2015 07:44:24 AM GMT
Hi Rakshith, The private security audit should be of the Admin API code, not the CF Admin code. First, the CF Admin should use -only- the Admin API. Then have private security audit of the Admin API. This would allow 2 things: 1) Admin API would have 100% parity w/ CF Admin (ex: DSN creation via Admin API would have the same defaults as DSN creation via CF Admin) 2) A security audit of Admin API would implicitly cover CF Admin. (no need for 2 separate audits) Currently, a private security audit of only the CF Admin would not be sufficient. B/c the non-parity of non-audited Admin API could still potentially allow a breach. And, again, there's no need for 2 separate audits. And there's no need for the confusion caused by Admin API having separate defaults from CF Admin. The solution to both can be fixed simultaneously: have CF Admin -only- use Admin API. My primary issue w/ CF Admin and Admin API is: they're not in-sync. Then, once they're in-sync, this ticket could be re-visited since there would be less reason to encrypt the CF Admin code. Thanks!, -Aaron
Comment by External U.
11108 | September 18, 2015 02:03:55 PM GMT
Thanks for all the inputs and the feedback. The Security team does not want to go with the approach of open-sourcing the Administrator. @Aaron, we will evaluate the suggestion of bringing Admin API and Admin code in sync.
Comment by Vamseekrishna N.
11109 | September 25, 2015 04:40:21 AM GMT
Is this the same security team that facilitated the h.cfm hack? Are you sure you should be listening to them? (in case you hadn't worked it out, that was not a serious question, but was a serious observation that your "security team" isn't really up to much, and never has been. Which is why we started this discussion in the first place)
Comment by External U.
11110 | September 25, 2015 04:50:06 AM GMT