Server mail con Exim sotto attacco

Sergey Kononenko ha segnalato su una delle mailing list di Exim di essere stato vittima di attacchi che sfruttano due vulnerabilità del MTA.

Le due vulnerabilità sono molto serie perché permettono uno di eseguire da remoto dei programmi con i privilegi dell’utente di Exim e un altro di escalare i privilegi e diventare root.

L’attacco consiste nell’inviare all’MTA una mail molto lunga in cui una riga è

HeaderX: ${run{/bin/sh -c 'exec /bin/sh -i <&3 >&0 2>&0'}}${run{/bin/sh -c 'exec /bin/sh -i <&4 >&0 2>&0'}}

Sono state pubblicate delle patch che permettono di mitigare il problema. Potrebbe essere anche utile seguire le guideline per far girare l’MTA con privilegi meno elevati.

Gli attacchi sono confermati sulla versione di Debian Lenny non patchata.

Aggiornamento 13/12/2010 18:30Nigel Metheringham ha detto su varie mailing list che il baco si riferisce ad una versione uguale o inferiore alla 4.69. Nel medesimo messaggio ha ricordato che la versione 4.70 risale al novembre 2009 e che la 4.72 del giugno 2010 contiene correzioni a problemi di sicurezza. Nigel ha detto che la prossima versione 4.73 conterrà altre modifiche di sicurezza che potrebbero, però, dare problemi su alcune configurazioni specifiche.

Autore: Luigi Rosa

Consulente IT, sviluppatore, SysAdmin, cazzaro, e, ovviamente, geek.

8 pensieri riguardo “Server mail con Exim sotto attacco”

  1. Ti sono vicino in questo triste momento (davvero, non sto cazzeggiando). Io uso Postfix e questo gioro mi e’ andata bene.

    Occhio che nmap non riesca ad identificare EXIM anche se togli la stringa dal greeting [E]SMTP

  2. E poi vediamo se con

    header_maxsize total size of message header
    header_line_maxsize individual header line limit

    possiamo impedire di mandare la bomba…

  3. Si puo` mitigare l’attacco in tre modi:

    prima di tutto, modificando il banner per non farsi riconoscere come Exim:

    smtp_banner=”Qualcosa di vostra fantasia ESMTP server ready”

    Poi, si disattiva il logging degli header malformati, che pare sia parte del problema di buffer overflow, cosi`:

    log_selector = +all -arguments -rejected_header

    (qui la parola magica e` “-rejected_header”)

    E anche, siccome pare che l’attacco funzioni cosi`: prima si manda una mail enorme che causa un buffer overflow e sporca la memoria delle ACL, e poi, NELLA STESSA CONNESSIONE, si manda una seconda mail che esegue il comando scritto nella memoria delle ACL, e` sufficiente impostare il numero massimo di sessioni SMTP accettate per ogni connessione a 1, cosi` facendo la seconda mail. quella che fa eseguire la roba sporca in memoria, non puo` essere mandata nella stessa connessione.

    Non sono sicuro che funzioni, e` solo un’idea. Nel caso, il comando e`:

    smtp_accept_max_per_connection = 1

    PS: Debian ha gia` la patch per Lenny, ma le vecchie macchine sono in merda… Spero che queste tre patch casalinghe reggano.

Spazio per un commento