OpenGL ES Security Threats and Measures

This topic provides a summary of some important security issues to be aware of when working with OpenGL ES on the Symbian platform.

Variant: ScreenPlay and non-ScreenPlay. Target audience: Device creators.

Security threats

The following table provides a summary of some important potential security threats and measures that can be taken to protect against them. The numbers in brackets indicate the security measure in the subsequent table.

Threat Description

Battery power

An attacker may want to drain the battery power of the handset to make it look like the battery life is poor. This inconveniences the handset owner by requiring the battery to be re-charged. It may cause the handset to be returned as faulty to the manufacturer. Use of OpenGL ES hardware drains the battery power.

Measure: Uninstall malicious applications (4).

CPU time

An attacker may want to cause a denial of service (DOS) attack or make games look slow on a handset.

Measure: Uninstall malicious applications (4).

Shader source code disclosure

A shader program present inside an OpenGL ES 2.0 application is loaded onto the GPU by the application. The shader program may be in source code format. This program is an asset which must remain confidential, because it may contain the application author's intellectual property. An attacker may want to read this program to discover how a given shader program works. For example a flight simulator may use a noise shader to produce a realistic cloud effect for the sky. An attacker may want to reproduce this effect in the product of a competitor.

Measures: Protect the DLL (1) and cage shader programs (2).

Shader binary replacement

An attacker may want to replace the binary code of a shader program. The motive might be to cause an amusing but annoying distortion of the screen. For example, to make the screen look as if it is melting or has holes in it.

Measures: Protect the DLL (1), cage shader programs (2) and validate pre-compiled shader programs (3).

Security measures

Measure Description

1

Protect the DLL

The Symbian platform provides a security model to protect deployment of malicious DLLs, by requiring all binaries to be placed in \sys\bin. This location can only be overwritten by trusted entities. Therefore the DLL is protected.

2

Data cage shader programs

The confidentiality of the shader program can be compromised if it is stored by the application program in plain text format either in the executable or in a resource file. Data caging can be used to prevent system-wide access to binaries. Do not place the shader program in \resource\apps\ because this directory is readable by other processes. A better location is \private\<SID>, where SID is the unique security identifier.

3

Validate pre-compiled shader programs

Some OpenGL ES 2.0 implementations support pre-compiled shader programs being loaded onto the graphics processing unit (GPU). The vendor must validate the supplied binary codes before loading them onto the GPU.

4

Uninstall malicious applications

Malicious OpenGL ES programs which attempt a DOS attack can be uninstalled. If the programs come through the Symbian Signed program, these can be revoked to prevent further distribution.