[Owasp-leaders] Reentrant Code, Sensitive Data

Jim Manico jim.manico at owasp.org
Fri Nov 30 03:28:03 UTC 2012


John,

What global variables are you using? This is Java and OO, right? There 
are no global variables in Java, or do you mean something like public 
statics? Don't global variables violate encapsulation anyhow?

So when you say  "In particular, I'm really struggling to implement [FI] 
in Java" - is this the same as saying "you are trying to achieve more 
test coverage?" And it seems like stress testing your thread code is the 
highest priority for you.

Some tests are not easily "unit testable" - especially when doing things 
like stress testing. You need a more formal load testing setup with a 
lot more beef than one developer machine.  You are also going to need 
some righteous logging, a load balance setup like loadrunner, and most 
likely utilization of the Java profiler API to see whats happening under 
the hood in real time. Also, I hope you are using ThreadPooling for high 
performance multi-threaded coding. :)

John, I have less mastery of academic thread terminology than you, I'm 
more of a mechanic. But I have done my fair share of threaded 
programming and I'd be happy to discuss this with you over the phone you 
have time. I also have some ideas to help you stress test more effectively.

Regards,
Jim Manico
@Manicode
(808) 652-3805

> All,
>
> 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
> strategy:
>
> * [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,
> -jOHN
> --
> 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