[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(){
            if(clearance){
                return "Company secret";
            }else{
                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
    occasionally.

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


    Regards,
    Enno




    On Thu, May 20, 2010 at 9:24 AM, David Holmes <davidcholmes at aapt.net.au>
wrote:
    > 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
various
    > 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
see
    > uninitialized fields (though they may be default initialized), and
provides
    > 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
exist.
    >
    > 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
    http://cs.oswego.edu/mailman/listinfo/concurrency-interest


-------------- 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