[concurrency-interest] Concurrency and security

达子 fslzdd at gmail.com
Thu May 20 03:56:43 EDT 2010


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/d6014c8c/attachment.html>


More information about the Concurrency-interest mailing list