SEC835

Runtime integrity and resource control

Application based Denial of Service

Application can crash for many reasons and at any time due to programming errorsHere we are considering crashes that may be triggered by an attacker who is exploiting programming errorsMajor attack vectors:

Runtime incapacitation of system componentsRuntime resource depletion

Innocent but exploitable code

The limit normally has been imposed on the number of logon attemptsThe exceeding number results in locking a user’s accounts (if ID is correct), or a hard-stop of an anonymous userIf that is millions of anonymous users who are stopped, the system can crashRecommendation: avoid a hard-stop

Runtime incapacitation

Resource may be incapacitated if the access to the resources has been affected.

It may occur as the result of uncontrolled changes, that actually destroy runtime integrity.

Examples:DB is not available due to the ODBC parameters changed

Object is getting unavailable due to the pointer set to Null

CPU starvation

CPU starvationApplication function, preferably with intensive calculation, is forced to go into unlimited looping that results in CPU being consumed

That may occur if the number of iterations is not always verified (by the counter or by verifiable conditions)

But it may be forced to looping intentionally, by providing an abusive data input. One of the examples demonstrates DoS occurred as the result of input of 1 mln of backlashes (\)

Resource starvation

User specified object allocationApplication may request a number of objects instantiated but it does not specify the limit. Unlimited instantiation will result in memory exhausting.

A number of opened user’s sessions may create the case

That may be even more gravy if resources are not released properly when the session is dropped.

Other types of resources can be affected by a similar way, e.g. disk space, queue size, network bandwidth

Resource starvation

Storing too much data in sessionCare must be taken not to store too much data in a user session object. Storing too much information in the session, such as large quantities of data retrieved from the database, can cause denial of service issues.

Failure to release resourcesIf an error occurs in the application that prevents the release of an in-use resource, it can become unavailable for further use. Possible examples include:

An application locks a file for writing, and then an exception occurs but does not explicitly close and unlock the file Memory leaking in languages where the developer is responsible for memory management such as C & C++. In the case where an error causes normal logic flow to be circumvented, the allocated memory may not be removed and may be left in such a state that the garbage collector does not know it should be reclaimed Use of DB connection objects where the objects are not being freed if an exception is thrown. A number of such repeated requests can cause the application to consume all the DB connections, as the code will still hold the open DB object, never releasing the resource.

Weak Runtime Resource Control

Weak resource control results in the resource depletion. The most vulnerable application dependent resources are

Cache memory

Queue memory

Virtual memory

Processors

Weak Runtime Resource Control

Resource depletion may be caused by:Failure to control the number of iterations of your loopsFailure to control the number of items in queuesFailure to control the number of instantiated objectsFailure to release resources Failure to control opened but not used sessions

Runtime Resource Control

Make sure all your iterations will be endedEvaluate and limit the number of instantiated objectsEvaluate and limit the number of queued itemsAlways release unused resourcesImplement secure session managementApply resource request timeouts

Weak runtime integrity control

This is in fact a cumulative vulnerability that assume any sort of unauthorized changes of the code during runtime

It may refer to any of the followingChanging executable code through any injection attack

Overwriting the variable values

Acquiring malicious code by downloading dynamic content

Memory overrun

Buffer overflow

Any language where the developer has direct responsibility for managing memory allocation, most notably C & C++, has the potential for a Buffer Overflow. While the most serious risk related to a buffer overflow is the ability to execute arbitrary code on the server, the first risk comes from the denial of service that can happen if the application crashes.

14

Buffer OverflowBuffer Overflow happens when a buffer declared on the stack is overwritten by copying data larger than the buffer

Often happens when large volume of data input has been accepted unchecked

Extra (sometime malicious) portion of data overwrite the stack. That results in the following:

System crash

System is going into infinite loop

Arbitrary code is planted and executed in memory

Languages affected: C, C++, Assembler

Prevention

Validate the size of data input. It must be done on per character basis. That is possible with the “counted versions” of string handling functions

15

Other overrun casesArray indexing errors

A string is just an array of characters. If the number is not handled, a string of other types can be written into arbitrary memory location

Unicode and ANSI buffer size mismatchesUnicode functions deal with buffer sizes in wide characters (2 bytes), when ANSI deal with byte sizes

16

Integer OverflowInteger overflow occurs when the memory allocation size has been calculated dynamically. The core of the problem is that the binary format we chose to represent numbers cannot represent them precisely. As the result negative value may be returned by an operation, leading to setting a pointer to a wrong address

Especially it concerns floating data representation

Most sensitive parts of the code:

Casting, conversion and comparison operators

Underlying Win32 API calls are vulnerable. Be careful when your code passes signed 32-bit integers into system calls

Integer OverflowMay result in:

Application crash

Escalation of privileges

Arbitrary code execution

Denial of service

18

Integer Overflow (cont)Languages defences include checking operations and throwing exceptions that advise about potential integer overflows. Thus, the error handling mechanism is getting critical in integer overflows preventing. Out of the box possibilities:

C, C++ - not much, but you can write the code to check

C#, checks data types and contains exception handlers

VB 6.0 and VB.Net are not vulnerable itself, but API calls are

Java has no defence against integer overflows

Prevention:

Right error handling

Check returns

Code review

Prevention (cont.)Design: by selecting correct data types, both length and signed/unsigned.

Avoidance: by carefully ordering operations and checking operands in advance, it is possible to ensure that the result will never be larger than can be stored.

Handling: If it is anticipated that overflow may occur change processing. Example: it is possible to add two numbers each two bytes wide using just a byte addition in steps: first add the low bytes then add the high bytes.

Propagation: if a value is too large to be stored it can be assigned a special value indicating that overflow has occurred and then have all successive operation return this flag value.

Tools: CERT largely automated mechanism for eliminating integer overflow and integer truncation As-if Infinitely Ranged Integer Model

20

Format String“format string” is a parameter that specifies the formatting requirements in the printf class of functions

An attacker may submit an arbitrary value of the string, including a malicious code. That may result in the following:

System crash

System is going into infinite loop

Arbitrary code is planted and executed in memory

Escalating of privileges

Languages

C, C++, Fortran, Assembly

Preventing

Ensure that all format-string functions are passed a static string which cannot be controlled by the user

Runtime Integrity Control

Prevent injection attacks

Prevent buffer overflow

Prevent integer overflaw

Prevent format string

Prevent memory eavesdropping

Strong runtime access control

Digitally signed dynamic content

Lab taskWork on the spreadsheet – cells B3, D3, L3, M3 and A16-18, A 26-27

Send for final review

Links

http://en.wikipedia.org/wiki/Integer_overflow

http://www.owasp.org/index.php/Buffer_Overflow

http://www.owasp.org/index.php/Integer_overflow

http://www.owasp.org/index.php/Resource_exhaustion