sec835 runtime integrity and resource control. application based denial of service application can...
TRANSCRIPT
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