Are there any security issues when you enable the CLR in SQL Server 2005?

Question

I play with the idea of ​​enabling CLR on my SQL server using EXEC sp_configure 'clr enabled', 1

However, I share my database server with several other developers and their projects. I have vaguely heard that they can be security issues by including this.

Does anyone know what it could be? Is the CLR safe to use on SQL Server?

Answer 1

No, SQLCLR code cannot do anything more in the database than the equivalent T-SQL code module, working under the same security context.

This has been and remains the most ignorant security requirement in all of SQL Server (especially since 2012), which can lead to disruption of UI communication with the SCCM database , the flagship ETL SSISDB deployment model (requires CLR), since a third-party security tool that inherits CIS tests ( mainly DBProtect), which also incorrectly marks SQL Server collation ratios through 2000, even if the server is down 2000, falsely directing database administrators to rebuild the wizard and permanently ruin their environment and applications as sensitive to register, if nobody talks about it. The CLR is not a security risk ; it allows flagship enhancements (after SQL Server 2012) to provide security in several ways with RDP and file system deletion rights and SSIS code management, for example. SSISDB, which can affect every 90% of SQL Server stores, including HA solutions that rely on not relying on a single SAN.

A note regarding database administrators who are simply not CLR-inclined because it’s “difficult to fix the problem if they are done poorly” - not mainly as part of DBA administration, troubleshooting older .NET developer code, if you hire bad database administrators, they it can also be difficult to fix the problem (see above by sorting). In addition, most people using the CLR do this for flagship functions and have little or nothing to do with writing CLR code (although script tasks in SSIS use this to some extent), and have much more in common with SSISDB and using groups SAN Availability. Database administrators who do not like this functionality should go into time mode and press stasis mode for 2008. This is written in terms of a full-stack BI / DBA, and not with some shortsighted internal sys point.

In addition, Availability Groups use the CLR , causing an error if the CLR is not enabled. Additional information also verified by Technet.

Both Availability Groups and SSISDB are the flagship features of today's SQL Server environments.

By enabling CLR and deploying SSIS packages through SSISDB now, you can mitigate the management and clutter of the file system, get legacy backup and even TDE service plans, and actually significantly reduce the need for RDP to eliminate the SSIS package.

Contact your database administrator if he cares so much about security with mixed-mode authentication, no SSL certificates for SSMS or SSRS or Excel clients, TDE is not enabled, and there is no audit or even registration of successful and unsuccessful logins.

http://www.codemag.com/article/0603031

To enable CLR, just run

 sp_configure 'show advanced options', 1; GO RECONFIGURE; GO sp_configure 'clr enabled', 1; GO RECONFIGURE; GO 

Answer 2

I'm with Skillman on this; unfortunately, the answer is not as simple as yes or no.

Enabling CLR on the server allows you to place certain CLR modules on your server, which opens up a non-trivial set of options for creating custom modules and data types, but also opens up a significant attack surface on your server.

There are additional considerations:

• Who has privileged database permissions? Do you trust other people who can create assemblies on your SQL Server? If not, keep in mind that they will be able to host the CLR code on your server, then I would not recommend it.

• Other settings on the server, including ownership of the database and reliable setting of bits in the database. The following article details this topic:
  https://blogs.msdn.microsoft.com/sqlsecurity/2007/12/03/the-trustworhy-bit-database-property-in-sql-server-2005/

• .Net in itself is not a mistake. When placing CLR code is much better than hosting eXtended stored procedures (XP), there is always a risk of a security vulnerability in the .Net infrastructure itself, in which case, as a rule, this is a secure CLR module hosted in SQL Server can become an attack vector to gain control over your SQL
  Server process This does not happen often, but you should always be vigilant and act accordingly when that happens.

I hope this helps,

-Raul Garcia

SQL Security

Answer 3

From the fact that the SQL CLR was unceremoniously removed from Azure for security reasons , and SQL Server 2017 introduces the new strict CLR security option, which is enabled by default, then it’s pretty clear that there are potential security problems and you should not allow the deployment of unsolicited code CLR

strict security conditions

The CLR assembly created using PERMISSION_SET = SAFE can access external system resources, invoke unmanaged code, and obtain the sysadmin privilege

One comment on a related post mentions above

Many of the ".NET Security Updates" launched through Windows Update are examples where someone can escape from the .NET sandbox using secure code. So many of these cases over the years.

Moreover

The SQL Server speculative execution side channel vulnerability protection guide specifically lists "SQL CLR assemblies" in "Extensibility mechanisms without reliable SQL Server".