[concurrency-interest] Concurrency and security

David Holmes davidcholmes at aapt.net.au
Thu May 20 05:18:03 EDT 2010

It is extremely difficult for a general-purpose tool to know the
significance of a race condition or any other coding error (it would need to
understand the semantics of operations involved). But if you have no data
races you've eliminated one source of potential problems.

David Holmes

-----Original Message-----
From: ´ï×Ó [mailto:fslzdd at gmail.com]
Sent: Thursday, 20 May 2010 5:57 PM
To: Enno Shioji
Cc: dholmes at ieee.org; concurrency-interest at cs.oswego.edu
Subject: Re: [concurrency-interest] Concurrency and security

  Good example! But the reason why the race condition in this example can
cause security problem is that it can expose sensitive data to user. What if
the race condition only affects some internal states? In this case, it's not
related to security, but an internal error. I wonder how tools can identify
if the race condition is security related or not.

  2010/5/20 Enno Shioji <eshioji at gmail.com>

    A very silly (but it happens! I've seen one like this before) example
would be:

    class Auth {
       private boolean clearance = false;

       public void authenticate(){
           this.clearance = true;

       public void deauthenticate(){
           this.clearance = false;

       public String readSecretData(){
                return "Company secret";
                return "Gotcha, hacker!";

    And then Auth is made a singleton because "It will increase
    performance!*" and these three methods are called from random number
    of threads. Then users without clearance will start to see secret data

    *: Making a class a singleton doesn't make things faster in most of the


    On Thu, May 20, 2010 at 9:24 AM, David Holmes <davidcholmes at aapt.net.au>
    > An unidentified poster writes:
    >> I am investigating an interesting topic: if the concurrency can harm
    > software security.
    >> Is there any software security issue  stemming from concurrency?
    > Yes. In poorly constructed systems race conditions could lead to
    > invariant violations, including those pertaining to "security".
    > In a platform like Java, the programming language must ensure there
are some
    > basic guarantees even in the face of race conditions. For Java this is
    > defined as part of the Java Memory Model, which ensures that you can't
    > uninitialized fields (though they may be default initialized), and
    > for correct visibility of final fields.
    > But even if the language provides basic guarantees, it is up to
classes to
    > use the language facilities correctly to ensure that they can't be
    > compromised by race conditions induced by client code.
    > And of course the runtime system (for Java that's the VM) must also be
    > written correctly to ensure no concurrency related security holes
    > Hope this gives you enough to do a proper investigation. ;-)
    > David Holmes
    > _______________________________________________
    > Concurrency-interest mailing list
    > Concurrency-interest at cs.oswego.edu
    > http://cs.oswego.edu/mailman/listinfo/concurrency-interest

    Concurrency-interest mailing list
    Concurrency-interest at cs.oswego.edu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20100520/8bb86567/attachment.html>

More information about the Concurrency-interest mailing list