História verdadeira dos meus primeiros dias na Microsoft.
Você não conhece o medo até o dia em que acorda e vê a manchete no ZDNet.com naquela manhã: "O pior buraco de segurança do Internet Explorer já foi descoberto em 'Blah' ", onde 'Blah' é o código que você escreveu seis meses antes .
Imediatamente após o trabalho, verifiquei os logs de alterações e descobri que alguém de outra equipe - alguém em quem confiávamos para fazer alterações no produto - havia retirado o meu código, alterado várias configurações da chave de registro de segurança sem um bom motivo, fez o check-in novamente e nunca recebeu uma revisão de código nem contou a ninguém sobre isso. Até hoje não tenho idéia do que ele pensava estar fazendo; ele deixou a empresa logo depois. (Por sua própria vontade.)
(ATUALIZAÇÃO: Algumas respostas a questões levantadas nos comentários:
Primeiro, observe que escolho assumir a posição de caridade de que as alterações na chave de segurança foram não intencionais e baseadas em descuido ou desconhecimento, em vez de malícia. Não tenho evidências de um jeito ou de outro e acredito que é sensato atribuir erros à falibilidade humana.
Segundo, nossos sistemas de check-in são muito, muito mais fortes agora do que há doze anos atrás. Por exemplo, agora não é possível fazer o check-in do código sem que o sistema de check-in envie a lista de alterações por email para as partes interessadas. Em particular, as alterações feitas no final do ciclo do navio têm muito "processo" em torno delas, o que garante que as alterações corretas sejam feitas para garantir a estabilidade e a segurança do produto.)
De qualquer forma, o problema era que um objeto que NÃO era seguro para ser usado no Internet Explorer havia sido acidentalmente lançado como marcado como "seguro para scripts". O objeto foi capaz de gravar arquivos binários - bibliotecas do tipo OLE Automation, de fato - em locais arbitrários do disco. Isso significava que um invasor podia criar uma biblioteca de tipos que continha determinadas seqüências de códigos hostis, salvá-la em um caminho que era um local executável conhecido, dar a extensão de algo que faria com que um script fosse executado e esperar que, de alguma forma, o usuário acidentalmente executaria o código. Não conheço ataques bem-sucedidos do "mundo real" que usem essa vulnerabilidade, mas foi possível criar uma exploração funcional com ela.
Enviamos um patch rapidamente para esse, deixe-me dizer.
Causei e, posteriormente, consertei muitas outras falhas de segurança no JScript, mas nenhuma delas chegou nem perto da publicidade que se fez.