The Netscape Communicator client was deployed on millions of desktops. It was also subject to attacks that attempted to gain unauthorized access to data on the client's computers, if not complete control of the computer. This talk discusses a broad range of examples of attacks that have been proposed against the Communicator application along with ways that the application evolved to block them.
As a bonus (not presented in RSA2001), a more generic discussion of issues surrounding security responses to identified security bugs is presented. The resolution to some of the above problems reveals that security patching is significantly different from software bug repair, and that fact needs to be used by response teams. The discussion ranges from problems caused by a lengthily QA cycle (and avoiding thrashing when bug inter-arrival/discovery time is smaller than a QA cycle), to why a bugs bounty is helpful (but why a bounty that is too large is actually problematic). Also presented is a proposed method to prevent reverse engineering of security patches (by distributing encrypted(??) patches). The method can also automate identification of *which* if any existing patch is critical during an attack, and it can accelerate and even automate patch deployment of the critical patch(es).
Gates 4B (opposite 490)