[cap-talk] FW: Broken captalk

[Karp, Alan H]

Forwarded for MarcS, who can no longer get his posts through to cap-talk.

________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
http://www.hpl.hp.com/personal/Alan_Karp


> -----Original Message-----
> From: Stiegler, Marc D
> Sent: Wednesday, September 02, 2009 3:38 PM
> To: Karp, Alan H
> Subject: Broken captalk
> 
> So, neither of my accounts can send to captalk any more apparently,
> could you ask this question for me?
> 
> --marcs
> 
> Subject: Needing a citation
> 
> So, we're putting together a tech report with a new approach to
> explaining why some of our stuff (in particular the waterken server) is
> good. There's a section on sequentiality hazards, to make the point
> that sequentiality isn't perfect either, to set up the case that
> concurrent systems can eliminate some hazards.
> 
> In the section below, we reference the security breach in FireFox from
> some years ago that was based on a script's ability to get added to the
> notification list on a page change, and it would throw an exception and
> prevent the security system from getting notified (since the security
> system was at the tail of the notification queue for security reasons
> :-)
> 
> Does anyone happen to know a good citation for that breach?
> 
> --marcs
> 
> The standard sequential observer pattern gives an example of
> interesting risk in sequentiality[Lee06]. In this example, a group of
> listeners are being notified that the observed value has changed:
> 
> public void setValue(Object newValue) {
>     myValue = newValue;
>     for (int i = 0; i < myListeners.length; i++) {
>         myListeners[i].valueChanged(newValue);
>     }
> }
> 
> In this ordinary example, there is an inappropriate sequential
> dependency among the listeners. The risk becomes evident when one
> considers what happens if one of the listeners throws an exception -
> the loop notifying the listeners is immediately exited, and listeners
> later in the list are not notified. This is not a common failure, but
> it can have severe consequences - a critical security breach of Firefox
> exploited exactly this weakness[???].