Libreoffice Macro

LibreOffice viene fornito in bundle con macro di esempio scritte in Python. Una macro può essere eseguita al verificarsi di un evento.
Esiste una vulnerabilità di path traversal nel componente che fa riferimento allo script Python da eseguire. Lo script pydoc.py incluso in LibreOffice contiene la funzione tempfilepager che passa argomenti a os.system(), permettendo remote code execution.

Soluzione SELinux:
Negare a libreoffice la possibilità di accedere alla rete.
In quanto libreoffice non ha come supporto nessun modulo di policy nella reference, ho dovuto optare per la generazione di un modulo da zero con il comando sepolgen e quindi assegnando ricorsivamente tutti i type relativi in tutta la directory in cui è installato. Quindi ho obbligato al dominio dell’utente utente_u a transitare in quello di libreoffice_t.
Successivamente dopo un’attenta fase di debugging di tutti i permessi che esso andava a richiedere, ho consentito tutti tranne quelli che permettevano a libreoffice di creare socket UDP e TCP. In realtà questa è una soluzione alternativa a tante altre che si potevano adottare, per esempio la classica soluzione di non consentire una shell oppure una soluzione che non permetteva al libreoffice di eseguire in /tmp, dal momento che l’attacco sfrutta tale directory.

Soluzione AppArmor:
Anche con AppArmor possiamo attuare strategie differenti per limitare questo attacco. E’ bene dire che attivando in modalità enforce il profilo di chmod, creato per l’attacco 0, l’attacco viene bloccato, tuttavia in questo caso è bene creare un profilo specifico per LibreOffice in quanto quest’ultimo è un applicativo a tutti gli effetti e non uno script malevolo come nel caso precedente. Per confinare LibreOffice, in modo tale che l’attacco non vada a buon fine, abbiamo almeno tre soluzioni possibili: la più immediata consiste nell’impedire a LibreOffice di eseguire /bin/dash inserendo la regola “deny /bin/dash x”. Una soluzione più accurata è definire, sempre all’interno del profilo di LibreOffice, un sotto-profilo limitato per l’eseguibile /bin/dash ed inserire una regola per la transizione dal profilo padre al sotto-profilo ogni qual volta LibreOffice esegua la dash.
Per la transizione di profilo la regola è “/bin/dash mrcx -> subprofile”. Per quanto riguarda gli accorgimenti da prendere nel sotto profilo possiamo:
1) impedire accesso alla rete con la regola "deny network".
2) impedire l'esecuzione di chmod con la regola "deny /bin/chmod x".
Entrambe le regole sono efficaci per bloccare l'attacco.

Soluzione Tomyo:
Anche in questo caso la soluzione più semplice per Tomoyo è quella di bloccare il chmod nella cartella /tmp eseguito dalla shell aperta da libreoffice limitandone, come prima, i permessi di esecuzione. Questa soluzione è più granulare in quanto influenza solo il /bin/chmod richiamato dalla shell di libreoffice (quindi il chmod richiamato con una storia di esecuzione diversa da altri programmi non risentirà di questa limitazione).
Un’altra soluzione, più limitativa, sarebbe quella di non permettere a libreoffice di aprire una shell (rimuovendo il permesso nella policy di “file execute /bin/sh”

Soluzione GrSecurity:
In questo caso le soluzioni sono molteplici, di default la policy non consente di eseguire su /tmp, così anche se sfrutta la vulnerabilità non riuscirà ad aprire la reverse shell.
Ma se l'amministratore concede il permesso di eseguire su /tmp, un'altra soluzione potrebbe esser bloccare l’accesso a internet a solo libreoffice, ma mi sembra una soluzione troppo eccessiva.
Alla fine ho optato per ridurre il campo di visibilità di libreoffice, non permettendo di accedere a /bin/dash, aggiungendo il parametro h, in modo da bloccare la reverse shell.
Per far si che la policy sia granulare le regole varranno solo per determinati utenti.