Baseline for Ed 2 of tr 24772

7.22 Time Consumption Measurement [CCM]

7.22.1 Description of application vulnerability

All applications consume resources as they execute, in particular Time. Each thread, event, interrupt and OS service consume CPU time that may be separately measurable by the system.

A common paradigm in managing applications is to monitor such resource usage by thread and take action to cease the calculation for that thread, such as abort, raise exception, lower priority or suspending the thread. If the calculation cannot be completed in time or within the resource constraints imposed upon it, then the application may fail.

The consumption of CPU resources (execution time) can be affected by changes in the CPU itself: for example, CPU’s may slow down to manage heat, resulting in more execution time to achieve a result. Similarly, cache misses due to the way a program is organized and executed, due to multiprocessor effects, can increase the execution time needed to complete a calculation.

The measurement of resource timing and consumption can be used to break sensitive algorithms. For example, some devices draw power from systems that they piggyback onto (such as chip cards and proximity-based passive systems).

7.22.2 Cross references

TBD

7.22.3 Mechanism of failure

Many applications measure resource consumption to detect failures of portions of portions of the algorithm and to make decisions about alternative actions. For example, excessive consumption of CPU may indicate that a thread is executing erroneously; or that other needed threads may not be able to execute due to excessive resource consumption.

Other factors, such a CPU speed changes and cache misses can cause a thread to consume significantly more CPU resources than expected to perform the same calculations.

A thread consuming more CPU resources than planned can result in missed deadlines for itself, or can take CPU resources needed by other threads, causing incorrect processing or missed deadlines for other threads. Missed deadlines are catastrophic for hard real-time systems, and cover the range of causing wrong results through to complete failure of the application.

For systems that live in the low powered consumption domain but require modern encryption, the device providing the power can use knowledge about power consumed to narrow the possible hashing algorithms or encryption algorithms used which may let the attacker defeat encrypt-ion or digital signing security systems.

7.22.5 Avoiding the vulnerability or mitigating its effect

Software developers can avoid the vulnerability or mitigate its effects in the following ways:

• 
  THINK ABOUT THIS. Scenarios exist where success at the slow speed /=> success at normal speed.
  
• 
  Where cache misses provide a significant potential hindrance, execute the application with cache disabled
  
• 
  For ultra-low powered devices (and for encryption-based systems in general), base the protection on more than encryption, such as obfuscation and indirection inside of the encryption protection.
  

7.23 Incorrect Authorization [BJE]

7.23.1 Description of application vulnerability

The software performs a flawed authorization check when an actor attempts to access a resource or perform an action. This allows attackers to bypass intended access restrictions.

7.23.2 Cross reference

CWE:

863. Incorrect Authorization

7.23.3 Mechanism of failure

Authorization is the process of determining whether that user can access a given resource, based on the user's privileges and any permissions or other access-control specifications that apply to the resource.

When access control checks are incorrectly applied, users are able to access data or perform actions that they should not be allowed to perform. This can lead to a wide range of problems, including information exposures, denial of service, and arbitrary code execution.

7.23.4 Avoiding the vulnerability or mitigating its effects

Software developers can avoid the vulnerability or mitigate its ill effects in the following ways:

Ensure that you perform access control checks related to your business needs. These checks may be different and more detailed than those applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor.

7.24 Improper Restriction of Excessive Authentication Attempts [WPL]

7.24.1 Description of application vulnerability

The software does not implement sufficient measures to prevent multiple failed authentication attempts within in a short time frame, making it more susceptible to brute force attacks.

7.24.2 Cross reference

CWE:

307. Improper Restriction of Excessive Authentication Attempts

7.24.3 Mechanism of failure

In a recent incident an attacker targeted a member of a popular social networking sites support team and was able to successfully guess the member's password using a brute force attack by guessing a large number of common words. Once the attacker gained access as the member of the support staff, he used the administrator panel to gain access to a number of accounts that belonged to celebrities and politicians. Ultimately, fake messages were sent that appeared to come from the compromised accounts.

7.24.4 Avoiding the vulnerability or mitigating its effects

Software developers can avoid the vulnerability or mitigate its ill effects in the following way:

Disconnect the user after a small number of failed attempts

Implement a timeout on authentication

Lock out a targeted account

Require a computational task on the user's part.

Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.

Consider using libraries with authentication capabilities such as OpenSSL or the ESAPIAuthenticator.