[concurrency-interest] Concurrency and security

James Gan ganzhi at gmail.com
Thu May 20 00:48:53 EDT 2010


A nice example! A follow-up open question: is it possible to detect
such error by atomatic tool? Seems very difficult!

On Thu, May 20, 2010 at 12:24 PM, Enno Shioji <eshioji at gmail.com> wrote:
> 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
>



-- 
Best Regards
James Gan
Current Project: Concurrent Building Block at http://amino-cbbs.sourceforge.net/
Blog: http://ganzhi.blogspot.com



More information about the Concurrency-interest mailing list