Nada de novo: Não é nenhuma novidade a possibilidade de utilizar macros/linguagens de script inclusas em programas para escrever códigos maliciosos. É a mesma coisa de dizer que o bash é perigoso porque permite que scripts escritos por pessoas malévolas coloquem códigos maliciosos para serem executados. O mesmo vale para qualquer programa que integre uma linguagem de programação poderosa (mesmo javascript) que não rode em um sandbox (o que muitas vezes não é possível).
O que é necessário e educar usuários para que estes não abram a apresentação que receberam por e-mail de um desconhecidos

A questão que precisa ser: A questão que precisa ser abordada/discutida é o limite do potencial de macros para um software como um editor de textos.

Coisas como acesso de escrita em disco (criação/remoção de arquivos); execução arbitrária de comandos externos (sistema, shell, etc.); envio de informações via internet (p.e. envio automático de informações do usuário) são eminentemente perigosas.

Acredito, como medida de segurança, ser possível bloquear certas chamadas que vão além das operações básicas de uma macro (essencialmente a simples automação de comandos). O que teria como vantagem a permissão de execução de macros "seguras", isto é, aquelas inofensivas fora da aplicação.

O javascript é um exemplo de linguagem segura (exceto por falha alheia), limitando o poder de atuação de scripts da web no espaço do navegador.

--
GAFFitter: a file fitter powered by a genetic algorithm.

mais ou menos isso.: o simples fato de fazer uma macro para abrir 6.000 arquivos texto, tabular dados, fazer gráficos com os dados e ir agrupando em várias planilhas e salvar os arquivos com outros nomes, em outros diretórios, faz parte de uma coisa "nociva". Assim como o shell e seus redirecionadores ">" são um perigo em mãos mau-intencionadas, uma macro que trata arquivos também é. Depende de quem está usando.

"vírus" de macro no OO: ...tudo dito, tudo esclarecido!!!!!!!
;-)

Coisas como acesso de: Coisas como acesso de escrita em disco (criação/remoção de arquivos); execução arbitrária de comandos externos (sistema, shell, etc.); envio de informações via internet (p.e. envio automático de informações do usuário) são eminentemente perigosas.

Parabens! Voce acabou de matar a linguagem de programação. :)
Se voce bloquear as principais utilidades dum script é então melhor arrancar o recurso de scripting. Não querendo ser chato, mas como o colega aí acima disse vamos considerar bash script tão letal quanto o OOo.

Na boa, eu viveria muito bem sem scripts, alias se algo é tão essencial que necessite de programação então vamos para uma linguagem de programação; Sei que vou parecer egoista, mas se linguagens de scripting de macros já são fracas e o pouco que tem dá para escrever um vírus, então porque não retira-las logo de vez ?

Se você perceber, em vez de: Se você perceber, em vez de banir/desabilitar completamente as macros, defendo "apenas" o isolamento das funções potencialmente destruidoras --como opcional, obviamente.

Isto seria útil para uma boa gama de macros, geralmente as mais simples, que limitam-se a automatizar tarefas dentro do escopo do aplicativo. Estas poderiam estar previamente liberadas sem qualquer aviso de periculosidade.

--
GAFFitter: a file fitter powered by a genetic algorithm.

É muito dificil faz isso,: É muito dificil faz isso, os programadores vão passar a vida inteira se concentrando e fechar buracos e vão acabar esquecendo do filão que é o OOo.

Um meio termo seria vir com o OOo com recursos de macro desativado. Se uma pessoa precisa programar com ele tem que revelar sua intenção por habilitar tal recurso de alguma forma a manifestar-se de forma não automatica por exemplo instalando a linguagem separadamente ou num wizard que identifique de que repositório veio tal macro, assim como acontece com as "extensions" do firefox.