New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

Welcome to the DNN Community Forums, your preferred source of online community support for all things related to DNN.
In order to participate you must be a registered DNNizen

HomeHomeDevelopment and...Development and...DNN Platform (o...DNN Platform (o...Strong NamesStrong Names
Previous
 
Next
New Post
8/4/2012 12:50 AM
 

Why doesn't DotNetNuke corporation ship signed assemblies in the Install package?

 
New Post
8/4/2012 10:08 AM
 
traditionally open source projects do not sign their assemblies as that would "brand" them - whilst we could ship the private key pair (and snk) for users to use it would mark it as coming from us - and our licence allows users to take the code and rebrand it as theirs. In addition, signed assemblies are primarily used by users with access to the GAC and many of our users only use shared hosting so dont have access to the GAC. In addition signed assemblies add an overhead with the need to provide binding redirects, as opposed to just working with the compiled code

Buy the new Professional DNN7: Open Source .NET CMS Platform book Amazon US
 
New Post
8/4/2012 3:33 PM
 

That argument only flies in you don't also distribute the source code. Since you do, signing the compiled binaries delivered via the install package (and keeping your private key private!) makes perfect sense. It would allow you, and any third party developers targeting the DotNetNuke platform, to easily distinguish 'official' DNN builds from random forks or builds that have had non-coordinated adjustments made to the core. 

But the key point is that it *doesn't* prevent folks from rebranding DNN; all they need to do is to download the source package, rebrand to their hearts content, and recompile. It does mean that folks can't rebrand DNN while pretending to others to be the version released by DotNetNuke.

I consider this a security issue to boot; since DNN assemblies are bin deployed, and the bin folder does not typically require Administrator privileges on the host to modify or replace, a deployed copy of DotNetNuke.dll could be replaced with a malicious copy with only exposure of privileges to the bin folder. That sort of thing is preventable with a strong name, as the assembly manifest of referring assemblies will specify the full name and the assembly binder would refuse to load the assembly if the key token was mismatched. 

In fact, if DotNetNuke signed the compiled assemblies shipped for the Community Edition, it would *prevent* fracturing in the core - folks like me building modules could strong name their own assemblies, and be sure that I won't be cornered into supporting my module deployed on some random version of DNN.

Admittedly, a "suddenly signed" version of DNN will might blow backwards compatibility for existing modules, since any module's assemblies deployed today *isn't* signed (can't be, if they reference DotNetNuke.dll), but that is no excuse to continue shipping non-signed assemblies. Perhaps an intermediate period where a signed version is offered by default, while a non-signed Install package is made available while folks update their modules?Certainly, a variety of options might exist to mitigate impacts to backward compatibility once the impact is studied and understood.

That the store must today accept and distribute non-signed assemblies because of this frightens me beyond words.

Looking forward to continuing this conversation...

 
New Post
8/4/2012 6:46 PM
 

there are a number of other reasons but the main one is that if the assemblies were signed people would look to add them to the GAC (to try to get performance benefits/maintaince benefits), however this leads to potential dll-hell (Chris Sells covers this well at http://www.sellsbrothers.com/Posts/De... ). In addition, DotNetNuke runs under medium trust - adding a signed assembly to the GAC would allow people to easily (with the APTC attribute) get it to operate as Full trust -whilst this would be handy in certain cases, we have never tested or supported that elevated security model.

Regarding the security risk - if someone can update the contents of your bin folder your site is already compromised , updating a dll is the least of your worries - in fact most hackers simply drop a classic asp file as their hacker tool (or a php toolkit) as that allows them to work around the asp.net sandbox

Please note, we always try to consider what our users want, however this is the first time in at least 5 years I can recall seeing this request - perhaps you might consider adding it to the community voice http://www.dotnetnuke.com/Community/C... to see if others feel likewise so we can guage the level of interest (we only have limited resources and can't spend anaysis time on ever request)


Buy the new Professional DNN7: Open Source .NET CMS Platform book Amazon US
 
New Post
8/4/2012 11:21 PM
 

I've read Chris's article before, and frankly Chris's argument that GAC deployment causes a new type of DLL-hell doesn't bear scrutiny. In the scenario he depicts, the assembly deployed to the GAC is only being referenced by a single application - that's hardly "shared". In such a case, yes, GAC deployment doesn't make a great deal of sense. But not signing an assembly because someone might put it in the GAC doesn't make any sense, either. You can sign an assembly, and not support GAC deployment just fine. 

Signing is not intended to allow us to deploy an assembly to the GAC; it's not a GAC gateway. Signing allows us to ensure that the assembly we reference from our components at compile time is the assembly that the CLR loads at runtime, and that the assembly we load at runtime has not been tampered with since it was built.

If DotNetNuke Corporation (or the community at large) isn't prepared to support GAC deployed signed assemblies, fine; don't.

Security is about layering, not locking the front door and hoping for the best. We're talking about a weak FTP server, or poorly chosen password, being the only real obstacle to an attacker absent signing. The fact that most attackers don't abuse a vector doesn't mean we shouldn't protect against it. Yes, I agree, should an attacker gain FTP access to your site they may do all sorts of nefarious things, but the example you give is, relatively speaking of course, easy to detect and react against. What would be easier to detect - a net-new file dropped in the site (your scenario), or the injection of code in an unsigned assembly that emails a copy of every submitted credit card to criminal_element@hotmail.com? The fact that the *only* way you'd detect the latter absent signed assemblies is by carefully inspecting the deployed assemblies for tampering makes that attack vector scenario almost impossible to detect. The fact is, it probably would *never* be detected by the site owner. Assembly signing tosses that entire scenario out the window - it simply wouldn't be possible.

I'll certainly submit this through the community voice process, but I believe that DotNetNuke Corporation should be taking a leadership position on this topic. 

While I am certainly new to this community, I have some passion around this topic and am interested in helping. Please let me know how.

 
Previous
 
Next
HomeHomeDevelopment and...Development and...DNN Platform (o...DNN Platform (o...Strong NamesStrong Names


These Forums are dedicated to discussion of DNN Platform and Evoq Solutions.

For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

  1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DNN.
  2. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
  3. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
  4. No Flaming or Trolling.
  5. No Profanity, Racism, or Prejudice.
  6. Site Moderators have the final word on approving / removing a thread or post or comment.
  7. English language posting only, please.