Microsoft Office Tutorials and References
In Depth Information
Protecting Against Attacks
Information disclosure — A UDF can read data off the workbook and send it to a malicious user
who does not have access to that data. The data might be coming from a database.
Denial of service — A UDF can use all the resources of the ECS machine, significantly lowering its
resources. Excel Services does not enforce any limits in the amount of resources that a UDF
consumes. It does not stop the UDF execution in the middle if the request timeout has expired.
For these threats to materialize, UDFs must either be malicious or be used in a malicious way.
In a similar way, data drivers are invoked as part of external data queries, and they can be malicious or
be invoked in a malicious way.
Malicious User-Defined Functions
A malicious UDF is intentionally designed to harm the security of the server or its users by stealing
information, changing data in an unauthorized way, or reducing the availability of the server.
To mitigate this threat, ensure that you fully control the executables that are deployed for the UDFs.
Follow these guidelines:
Deploy only UDFs that are developed by a trusted source. This guideline is the same as with
any other software that you deploy on your machines, from an external vendor or a developer
from your organization.
Limit the access to the location that the UDFs are deployed to. Only administrators should have
permissions to change the files deployed as the UDFs. UDFs deployed to the GAC are usually
more secure, because the permissions to the GAC are more limited and it allows versioning and
For UDFs written in managed code, use code access security to limit what the UDFs are allowed
to do. For example, do not allow them to access the network or the disk if they do not need to.
Malicious Use of User-Defined Functions
A non-malicious UDF can be used in a malicious way with grim results. Here are a few examples:
A UDF receives a range in the workbook as an argument and performs a complex mathematical
calculation over that range. An attacker could craft a workbook that calls this UDF and passes a
huge range of data as an argument, resulting in the UDF consuming a huge amount of CPU and
A UDF has a security defect that can be exploited to run arbitrary code. Altough the developer
of the UDF did not intend a malicious exploit, an attacker could potentially take advantage of it
to run some other code that results in a number of attacks.
A UDF is designed to write data to a database. It receives as a parameter the database to write
to, and the SQL command to execute. When used in a non-malicious way, such a UDF can have
a positive business value. On the other hand, an attacker can use this UDF to tamper with any
database that the user who opens the workbook has access to.