|
|
| (One intermediate revision by one other user not shown) |
| Line 1: |
Line 1: |
| − | In this talk we will be discussing anatomy of race conditions, various forms of race conditions (userland and kernel land), properties viz. concurrency, shared object property, change state property etc., possibility of instrumentation and symbolic execution, some examples. | + | In this talk we will be discussing anatomy of race conditions, various forms of race conditions, properties viz. concurrency, atomicity, shared object property, change state property etc., possibility of instrumentation and some examples. |
| − | | |
| − | An execution ordering of concurrent flows that results in undesired behavior is called a race condition—a software defect and frequent source of vulnerabilities. Race conditions result from runtime environments, including operating systems, that must control access to shared resources, especially through process scheduling.
| |
| − | | |
| − | Vulnerabilities due to race conditions have ever been prevalent in the systems, on both sides, be that userland or be that kernel land too. Considering today’s super complex state of applications and memory management mechanisms, race conditions are bound to occur. Reason being, the resource hungry processes are always kept starved using various memory management algorithms and thanks to multiplexing and parallel processing, they land in a lot of such situations where they are led to spirals resulting in some sort of decision confusion. As they say, exhaustive (100%) testing is not possible, the attacker can always find a juicy input to exploit such race conditions.
| |
| − | We reached this area of research because of some tricky experiences which we earned in our daily usage of computer applications. Majority of times while booking tickets online .
| |
| − | | |
| − | So, here is where our excursion towards race condition vulnerabilities began and is still ongoing ./../
| |
| − | Having said this, like us the humans, even applications expect resources in timely manner (resource hungry?, always), and though we don’t know how they feel in absence of the resources, for sure they heartlessly misbehave in such conditions, resulting in deadlocks, crashes, denial of service etc.
| |
| − | | |
| − | The talk will progress explaining concurrency, Time of Check Time of Use, systems specific (threads, processes, tasks), concurrent flows, application specific (shared objects, shared functions), concurrency property, shared object property, change state property, mutual exclusion, synchronization primitives, control flows and deadlocks, possible usage of SMT solvers in predicting deadlocks and hence race conditions, multitasking systems with shared resources (online ticket booking applications), possible use of dynamic instrumentation, symbolic execution, brief analysis of hang state, real world CVEs, possible ways of mitigations.
| |
In this talk we will be discussing anatomy of race conditions, various forms of race conditions, properties viz. concurrency, atomicity, shared object property, change state property etc., possibility of instrumentation and some examples.