[concurrency-interest] Concurrency and security

David Holmes davidcholmes at aapt.net.au
Thu May 20 00:54:23 EDT 2010


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

I would expect many race-detector tools would flag the below as needing
synchronization.

David Holmes

> 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

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest at cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/concurrency-interest




More information about the Concurrency-interest mailing list