SEC835 Runtime integrity and resource control

Application based Denial of Service Application can crash for many reasons and at any time due to programming errors Here we are considering crashes that may be triggered by an attacker who is exploiting programming errors Major attack vectors: Runtime incapacitation of system components Runtime resource depletion

Innocent but exploitable code The limit normally has been imposed on the number of logon attempts The exceeding number results in locking a user’s accounts (if ID is correct), or a hard- stop of an anonymous user If that is millions of anonymous users who are stopped, the system can crash Recommendation: 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 Application 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 allocation Application 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 session Care 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 resources If 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 loops Failure to control the number of items in queues Failure to control the number of instantiated objects Failure to release resources Failure to control opened but not used sessions

Runtime Resource Control Make sure all your iterations will be ended Evaluate and limit the number of instantiated objects Evaluate and limit the number of queued items Always release unused resources Implement secure session management Apply 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 following Changing 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.Buffer Overflow

14 Buffer Overflow Buffer 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 cases Array 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 mismatches Unicode functions deal with buffer sizes in wide characters (2 bytes), when ANSI deal with byte sizes

16 Integer Overflow Integer 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 Overflow May 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 ModelAs-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 task Work on the spreadsheet – cells B3, D3, L3, M3 and A16- 18, A Send for final review Links