[Owasp-leaders] Reentrant Code, Sensitive Data

John Steven John.Steven at owasp.org
Sun Nov 18 22:53:50 UTC 2012


I'm working on some risk-based (unit) testing of reentrant code that
handles sensitive objects. I'm writing to ask for a bit of perspective
and help. At issue is this:

In a reentrant server-/service-based implementation pooling sensitive
objects may provide scale. However, a race condition on this  pool
could result in information leakage or privilege escalation between
two users: A and B. In another vein, no one wants deadlock or resource
exhaustion to result in D.o.S.

Unfortunately, I'm programming in Java. I currently have a rather
performant implementation (currently performs at 1-2X the furious
object pool [*fop]). However, I'm really struggling to test and prove
the security properties of this code. I've adopted the following

* [In]formal methods:
* Identify [CS := Critical Sections] of code (reentrant blocks)
* Identify [GV := Global Variables] relative to scope of [CS] on which
[CS] or calling code operate
* Identify any [GV] mutation within [CS]:
* Remove contended [GV] mutation from [CS], -or-
* Use atomic update for primitive [GV]s && list potential side-effects, -or-
* Convert complete [GV] to a monitor && provide external access only
through monitor.
* Identify any [GV] access within [CS]:
* Use atomic update for primitive [GV], -and-
* Implement relative ordering allowing for correct operation with
stale values, -or-
* (where coupling is unavoidable:
* Implement fail-fast scheme for stale value access, -or-
* Implement monitor access of [GV] && coupled entities.
* Diagram a [ST := State-Transition digraph] for [CS] and callers,
visit ensuring:
* Integrity of [GV] access/mutation;
* No deadlock exists;
* No state of resource exhaustion occurs.

* Testing:
* Conduct [BV := Boundary Value testing] on [GV] structures
* Conduct [BV] under:
* Single-threaded operation,
* Threads = # of hardware [hyper-]threads (e.g. 8 on a quad-core i7),
* Tons o' Threads (e.g. 256).
* Scaffold a 'chaos' [FI := Fault Injection], test.

In particular, I'm really struggling to implement [FI] in Java.
Currently, I can inject the following states:

* Thread yield;
* Temporary thread starvation;
* Raise Thread interruption.

By seeding the code with issues such as improper [GV] mutation,
deadlock, and similar, I was able to show [FI] effective. [FI] even
found something that I'd overlooked with my prior application of
[in]formal methods. At a thread count of 32-64, the [FI] code proves
effective in under 90 seconds (that is a test FAIL occurs). What
percentage of false negatives are occurring is beyond my
understanding. I'm unable to discern whether another combination of
threads, faults, and time would create additional FAIL conditions.

Three major problems with my regime remain:

1) I'm unable to conduct real [FI] to handle more subtle issues (such
as reliable interruption of threads during seemingly atomic
actions--such as assignment) without VM instrumentation;
2) I can not apply proper code-modeling or formal methods to this code.
3) Scaffolding code to "Stop the music" to test state requires rather
invasive changes that won't be easily pulled out for production
employment and will affect speed.

#2 and #3 are particularly troubling because of the patterns the
design leverages. Monitor, semaphore, wait/notify, and the
synchronized block are constructs easily modeled, but their
performance is tragic. More modern java.util.concurrent APIs and
AtomicXXX objects provide better performance but are more difficult to
model (even informally). For instance, it's incredibly hard to "see"
critical blocks when pairing a concurrent container with constant-time
element counts.

I've done a fair bit of threaded programming in my time and don't need
help w/ wait/notify or conditions/signals. The design's [ST] already
accounts for:

* Spurious thread wake-up;
* Unexpected interruption;
* Conditions requiring a watch dog (i.e. detected resource exhaustion);
* As much of an event-driven paradigm as is idiomatic in Java.

My questions are these. Does anyone:

A) Use pencil-and-paper exercises they've used to prove their code
correct in the past?
B) Know of a [FI] package that can ease my testing tasks?

Any help/experience would be appreciated. Thanks,
Phone: 703.727.4034
Rss: http://feeds.feedburner.com/M1splacedOnTheWeb

* [fop] - http://code.google.com/p/furious-objectpool/

More information about the OWASP-Leaders mailing list