Hi all...

I have a question/concern about a typical scenario that could happen and was wondering if anyone can help me figure out the right solution.

Assuming I am a hosting company called Mike's Hosting and that I host 5 different sub-portal for 5 different companies. The layout of my Portal and sub-portal would be similar to this:

-Mike's Hosting (Portal)
---Company A (sub-portal)
---Company B (sub-portal)
---Company C (sub-portal)
---Company D (sub-portal)
---Company E (sub-portal)

Now let's say I'm a module developper and work for Company C and decide to create a module that holds a nice little TEXTAREA field so that I can execute queries kinda like the one in the HOST-->SQL Menu when logged has "host"

Let's say I log in my sub-portal for Company C as admin, and upload my brand new cool module.
I decide to insert this module inside one of my pages.

Then I can execute SQL queries from within my brand new cool module.

My question is:
Isn't that a BIG security risk ? What If I decide to execute xp_ or sp_ store procedure on DB ? What if I decide to run queries and view the results in a datagrid, I could be executing queries and obtain data from all the other companies being hosted at the same place since we are all using the same DB right ?

I could be viewing data from Company A or B or C or ...I could even make by accident a DROP table or even worst, damage a system TABLE that would screw the entire 5 sites being hosted no ?

Is there a workaround for this potential vulnerability ?

Who's to stop a Module developper to create such a TEXTAREA module that allows to run queries and display results in a datagrid ?

Many thanks!
Sincerely

Vince

I am surprised no one else has brought this up already.  I may have to search the forums to see if there is a post.  It is a very good question.

From what I see with the current security module, the only way you would be able to control that is to build some kind of SQL GUI query tool.  Allow the users to insert conditions and spit out results while controlling the portal ID with the module code.  Giving access to run scripts would be a definite issue.

Wallew

Please don't take this the wrong way. Of course it is a big security risk!

I don't think you were implying that the design of DotNetNuke could somehow be at fault here, however I think it is prudent to say that it certainly is not. There is a good reason that the SQL module is on the Host menu. It is the same reason that the Module Definitions module is on the Host menu. The reason is to prevent anyone except the host from executing any dangerous SQL queries or installing any dangerous modules.

You wouldn't install anything that gave this sort of access to others on your computer, and you shouldn't do it on your website either.

>> Let's say I log in my sub-portal for Company C as admin, and upload my brand new cool module.
Admin users cannot upload modules.  Only the host user can.  Therefore, there is no security risk in your scenario, unless you supply the host password to people you shouldn't, or install modules that you have not reviewed.

Vlince wrote:

Assuming I am a hosting company called Mike's Hosting and that I host 5 different sub-portal for 5 different companies. [...]Now let's say I'm a module developper and work for Company C and decide to create a module that holds a nice little TEXTAREA field so that I can execute queries kinda like the one in the HOST-->SQL Menu when logged has "host".Let's say I log in my sub-portal for Company C as admin, and upload my brand new cool module.

If you set up your hosting like this, the only way to handle this in a secure way is to not allow admins of subportals to upload module definitions. This is something that should be done by the host, after the host inspected the modules to ensure that the modules cause no security issues for the other subportals. In my opinion the host should be able to go thru the source for this. Anyway, the host is the only one capable of making modules premium, so that only certain portals can use certain modules. If you let admins of subportals upload modules, how will you prevent other subportals to use the same modules?

If you want to make a secure setup, don't work with subportals, but use seperate instances of dotnetnuke and seperate db's ...

cheers,

erik

Just wanted to add a little emphasis on the responsibility of the Host/SuperUser here.

If you are hosting multiple portals on your DNN install then as a host you must realize that security should become your #1 priority.  DNN allows for you to delegate trust in several ways but it is up to you as a host to do it responsibly.

Here are a few more places to be alert with:

Making another user a SuperUser - should go without saying, but don't do this unless you trust the other person more than you do yourself. 

Giving another user Administrator privledges - If they are in their own portal then they are sandboxed and can only add modules that the Host allows, and upload files to their own folders, but remember that they share the account that you have with your ISP, and that they can make other users administrators (within their sandbox) also.

If you (or an admin) gives a role Edit Permissions to a page/tab- you are giving them the same ability as an administrator for that smaller sandbox.

And most important in my opinion is something that can be easily overlooked:

If you set Skin upload permission to "Site" under Host>Host Settings then you are giving your sub-portal administrators access to run server-side code just as if you allowed them to upload modules.  Don't use this last setting unless you fully trust the administrators of your sub-portals.

Hello all and thanks for the answers!

gsc4 :
No I'm certainly not implying that the design of DotNetNuke could somehow be at fault here, no way. I was just concern with the "potential" vulnerability that's all!

anthony-glenwright :
Admin users *can* upload modules if they are given the right to do so(and not necessarily given the Host password)! Like the others seem to say is that the responsibility comes back to the Host Company, making sure they do not give those rights to those admins!

ErikVB :
"...the only way to handle this in a secure way is to not allow admins of subportals to upload module definitions. This is something that should be done by the host, after the host inspected the modules to ensure that the modules cause no security issues for the other subportals. In my opinion the host should be able to go thru the source for this...."

Wouldn't that be problematic, to a certain point, having the hosting company viewing your source code for each and every module you upload(or send them) and what about simple PA that you simply bought off snowcovered like this one:
http://www.snowcovered.com/snowcovered2/user_uploads/QuickSQLGrids1.8_viewlet_swf.html

without the source code?

I understand everyone's answer and it all comes down to the HOST responsibility to not allow module uploading until its been *approved* nor am I questionning DNN's design/architecture.

I was simply pointing out a scenario that could/would happen on a regular basis, if the hosting companies are already busy and can't give you proper support, imagine the hell of having to call them each time you need to upload a module and then *wait* for their approval. What are the chances they have developpers that work there *waiting just for that* checking your code!

The reason I'm asking is because it hit me while I was developping a module, in fact its a simple module like the one in the link I gave you. You type an SQL query in a TEXTAREA field and it links that to a datagrid nothing complicated and not dangerous(well unless used maliciously of course) so that's how it flashed me...

The great thing I like about DNN is in fact the possibility to develop modules and upload the PA once your done. If in the process I have to *wait* for that module to be approved then that could become a problem for some people and changing Host company might not be a possibility and/or workaround.

As a developper for Company C, all I want is to create modules that are relevent for my web site and give myself some flexibility. I don't know how many sub-portals will be hosted along with my web site. Should I take this into consideration, me the simple programmer, while I create modules ? Should I not develop these kinda of modules ?

As for ErikVB's suggestion of using seperate instances of DNN, what if they all point to one SQL Server wont I still be able to execute queries allowing me to view all the databases on the SQL Server ?

Anyway...this is not a rant in any way/form I'm just sharing my concern and want to learn from your suggestions that's all!

Many thanks to all
Sincerely

Vince

 

Vlince wrote:

anthony-glenwright : Admin users *can* upload modules if they are given the right to do so(and not necessarily given the Host password)! Like the others seem to say is that the responsibility comes back to the Host Company, making sure they do not give those rights to those admins!

Where can you give admins the right to upload modules? I've yet to see anywhere that can be done in all three major versions of DNN.

Two small points.

You could test the PA on a local install to see what you can do with it, without being given the Source Code, if receiving the source is a problem.

Separate installs of DotNetNuke get separate databases.  If the user is not granted access to the database of another install they shouldn't be able to execute queries on it.

Aloha,

James

Reading the red text from J7Mitch

If you set Skin upload permission to "Site" under Host>Host Settings then you are giving your sub-portal administrators access to run server-side code just as if you allowed them to upload modules.

Other then that you are right, I haven't seen it/tested it...

I'm gonna have a try and get back to you if I find out!

Sincerely
Vince

You are correct James!

For sure they(the hosting) company could try and test your PA on a local machine to see if it is correct, but to the untrained eye the guy/girl testing the module might not see/know the potential vulnerability...I suppose I could even code something like:

If username = "vlince" Then
...panel1.Visibility = true
End If

Then inside panel1 would be my TEXTAREA where I could then execute my queries and view the databse schema...but that is pushing it I agree...but its still there! So while testing the PA localy, they'll never see that!

As far as the seperate databases then you are correct, I suppose you could create a user with proper permission to only execute queries for its database and not the others...

Like everyone seems to say, and I agree, the responsability comes down to the Hosting company and making sure they know what they are doing...

Chose wisely I suppose!

Sincerely
Vince

Vince,

I think you are missing the point that you are the Host/SuperUser in this scenario.  As the owner of the web account from your ISP it is your responsibility to ensure the security of the modules you install into your DotNetNuke Portal Framework.

There is not a built-in function to allow the Host/SuperUser to delegate the authority for uploading new modules except for adding a new SuperUser as I mentioned above.

BTW, For any module developers out there who are reading this. You also have a huge responsibility here.

It should go without saying but... Do not even attempt to release a module like Vince is suggesting and expect it to go unnoticed.  If your module has security vulnerabilities like these then you can be sure that there are many alert developers who will find out about them.  What they do next will depend on the developer but the best you can hope for is that they contact you directly.

If you are developing a module that involves uploading code that can be executed on the server (including SQL statements) then you would be well advised to let a trusted third-party verify your security before releasing said module.

Again I don't think it can be over-stated.  If you are the Host/SuperUser then you should be very conscious of the implications of uploading a module that you are not familiar with.

Thank you J7Mitch

I'd just like to add that my intentions where not to create a malicious module, in fact I got inspired by the one shown at snowcovered...

I thought it would be a nice module to have...you simple put the module on a page, then go into the options, enter a SELECT query and bind that to a datagrid also allowing more options like enable paging, sort column headers, search, add, modify, delete a row in a datagrid, change bgcolor and what not...

But then as I got more and more involved in my module, it flashed! What if I binded my datagrid to a xp_ Sproc ? and I did and it worked so I thought I'd share that with you guys/girls...

I think J7Mitch says it best :

"...you should be very conscious of the implications of uploading a module that you are not familiar with."

Vince

Vince,

I understand where you are coming from with the issue of the super user being able to test 3rd party code in modules for security (including your example of backdoors). Have you considered that this issue is exactly the same on every computer system (of any kind) that involves 3rd party code? The issue is no different for Microsoft Windows operating systems for example. Taking that as a precedent, I assure you that anybody considering writing such 3rd party code should be very concerned with the very real possibility of a law suit. The malicious code will be found by someone and invariably they will alert the wider community. If in doubt stick to respected module developers with a good track record. (If you want to get extreme find yourself a decompiler - but becareful of legal implications. Alternatively, demand source code and recompile).

Consider that in an earlier release of DNN the number of DNN installations around the world was being tracked via a seemingly obscure piece of code that accessed dotnetnuke.com. Somebody found that code and the resulting feedback saw it quickly removed. The more of the community that is looking for this type of thing, the more reason there will be for 3rd parties to act responsibly. (This is a good topic, good healthy conversation about security - don't be discouraged about giving us these ideas).