
########################################################################

Applicazione: Pegasus mail (http://www.pmail.com)
Versione:     4.01 ma probabilmente anche le precedenti
Bug:          Cattiva gestione delle mail con i campi "From:" e "To:"
              di una certa grandezza
Rischio:      DoS e in alcuni casi il client non puo' essere riaperto
              finche' la mail salvata in locale non viene cancellata
Autore:       Auriemma Luigi (e-mail: bugtest@sitoverde.com)

########################################################################


Sezioni:
1) Introduzione
2) Bug
3) Il codice
4) Fix
5) Filosofia

----------------------------------------------------------------------

1) Introduzione

Pegasus mail sembra essere un mail client free abbastanza diffuso ed e'
disponibile per Windows (sia a 32 che a 16 bit) e per Dos.
La versione del programma da me testata e' l'ultima al momento in cui
scrivo: 4.01 per Win32.
Il sistema operativo utilizzato per i miei test e' Win98SE (quindi puo'
capitare che qualche piccolo dettaglio e' differente rispetto a chi
utilizza NT/2k/XP o altri).
Naturalmente ho contattato tutti gli indirizzi di supporto specificati
nel programma ma non ho ricevuto nessuna risposta, quindi nessun fix
ufficiale e' disponibile al momento.
Comunque questo non e' un gran problema in quanto uno degli scopi di un
advisory e' anche quello di catturare l'attenzione dell'autore del
programma vulnerabile.

----------------------------------------------------------------------

2) Bug

Il bug e' nella gestione degli header "From:" e "To:" nelle mail
inviate.
Pegasus mail puo' gestire al massimo 259 caratteri in questi due campi,
quindi il problema sorge quando l'attacker invia una mail con un numero
superiore di caratteri in questi header.

Per esempio, la seguente e' una mail proof-of-concept:

/*mail*/
From: myname <251'A's>
To: test@localhost
Subject: Good crash

You cannot see this text 8-)

/*end_mail*/

(i 260 caratteri sono contati dopo "From:" in modo da avere " myname <"
+ 250 'A' + ">" = 260, e con l'header "To:" e' tutto identico)

Ora ci sono differenti risultati riguardo il crash del programma, che
sembrano essere dovuti alle opzioni che abbiamo attivato nel programma.
Ad esempio puo' crashare quando vogliamo aprire la mail, o crashera'
durante il check delle mail ed il problema piu' grande e' nella
riapertura del programma in quanto la mail resta salvata nella cartella
mail dell'utente quindi il problema contina finche' non verra'
cancellata la mail.

Un altro problema e' che la mail malformata non e' cancellabile dal
programma in quanto se la si vuole cancellare dal cestino Pegasus
ricrashera' ancora.
Quindi dopo aver depositato la mail nel cestino dobbiamo uscire dal
programma in modo che lui la cancelli automaticamente all'uscita
senza crashare.

Ora voglio mostrare gli errori (difatti si ottengono ben 2 errori, uno
dopo l'altro) e le differenti situazioni riguardanti quale campo
vogliamo exploitare:

"From:"
Il primo errore lo otteniamo quando EIP raggiunge 0x004157c0 e l'header
malformato riempe il registro EDX

"To:"
Il primo errore lo otteniamo quando EIP raggiunge 0x004c668c e l'header
malformato riempe i registri EAX e EDI.

Il secondo riguarda Kernel32.dll all'EIP 0xbffc04d4.

----------------------------------------------------------------------

3) Il codice

In allegato c'e':
a) un piccolo proof-of-concept per inviare una mail con il campo
   "From:" piu' grande di quanto supportato da Pegasus.
   Il codice sorgente e l'eseguibile sono per Win.
b) una patch temporanea non ufficiale che esegue il fix che ho
   suggerito (utile se qualcuno non sa usare un hex editor).
c) Quello che stai leggendo ora e' la versione in italiano dell'advisory
   in allegato.

----------------------------------------------------------------------

4) Fix

Nessuna patch ufficiale.
Quindi visita il sito di Pegasus mail (http://www.pmail.com) per
aggiornamenti.

Il mio fix PERSONALE e NON UFFICIALE per la versione 4.01 e' il
seguente:

File: winpm-32.exe
address	value
14DC3   90
14DC4   90
14DD7   90
14DD8   90

Il trucco del NOP funziona sempre e sembra non recare nessun danno alle
funzionalita' del programma comunque e' da considerare solo come un fix
temporaneo!

----------------------------------------------------------------------

5) Filosofia

Io sono davvero fiducioso riguardo la FULL-DISCLOSURE perche' con essa
"chiunque" puo' conoscere il reale effetto di un attacco, il reale
pericolo di un bug, qualcuno puo' anche imparare un po' di programmazione
(io alcune cose del C le ho imparate dai codici sorgenti di alcuni
exploits) ed essa e' utile per tutti coloro che sono fiduciosi in questo
tipo di disclosure proprio come me.
Nessun segreto!

----------------------------------------------------------------------

Qualsiasi tipo di feedback e' benvenuto!

Byez


