300246 - (sa15907) Spoofing via attachment dragging

Status: RESOLVED FIXED

(Thunderbird :: Mail Window Front End, defect)

Description

[Daniel Veditz [:dveditz]]

From Andreas Sandblad, Secunia Research

-- SA15907: Mozilla Thunderbird Attachment Spoofing Vulnerability --

Secunia Research has discovered a vulnerability in Thunderbird, which can be
exploited by malicious people to trick users into downloading malicious attachments.

The vulnerability is caused due to attachments not being displayed correctly in
mails. This can be exploited to spoof the file extension and the associated file
type icon via a combination of overly long filenames containing whitespaces and
"Content-Type" headers not matching the file extension.

Successful exploitation may lead to malware being saved to e.g. the desktop.

NOTE: Attachments can be saved by dragging the attachment or using the "Save
As..." or "Save All..." functionality. For files on the desktop the icon can be
spoofed if it e.g. is a ".exe" or ".lnk" file.

-- PoC (Proof of Concept) --
The raw mail source to be sent can be found in mail.txt (in poc.zip). It is
recommended to send it manually via a telnet session.
E.g:
telnet <SMTP server> 25
HELO <SMTP server>
MAIL FROM: <FROM>
RCPT TO: <TO>
DATA
<mail.txt>

.

QUIT

Open mail, drag attachment to desktop and double click on it (see attached
screendumps). "You are vulnerable!" should be displayed in a dos window.
--

The vulnerability has been confirmed in Thunderbird 1.0.2 for Windows. Other
versions may also be affected.

Discovered by: Andreas Sandblad, Secunia Research

Comment 1

[Daniel Veditz [:dveditz]]

Attachment: zipped testcase mail

Comment 2

[Daniel Veditz [:dveditz]]

If you "Open" the attachment (double-click) you get the helper-app dialog which
truncates on the left and strips out extra spaces to show the true .lnk
extension, although it does say "which is a: Text Document" because of the
Content-Type: text/plain. The dialog defaults to "Save", but the "Open" choice
is not disabled as it should be for executable types, but is harmless because
we'll open it in the default text handler (e.g. notepad).

But if you drag it you never see that, and by default the windos OS is going to
hide the .lnk extension

There's some similarity to the Michael Krax "firedragging" bug 279945. That fix
was specific to image dragging code, though, and that approach probably doesn't
work here: we can't just neuter executable extensions because it might actually
be a legitimate executable the user wants.

If we kept the true extension from getting pushed off the side that would go a
long way toward preventing this type of spoofing. Like the helper app dialog we
need to squeeze out runs of spaces, and truncate on the left if necessary to
keep the end of the filename visible.

Comment 3

[Scott MacGregor]

I'll try to look at this. If you know where the helper app code lives that does
this fix up, that would help. 

Comment 4

[Scott MacGregor]

Attachment: the fix

It looks like crop="center" now works! So I backed out our change to Bug
#245331 which allowed the attachment name to have an arbitrary width so we
would never truncate off the extension. Now each attachment name is given 15em
again. We then crop long names in the middle. I copied the code the external
helper app dialog is using to strip down chunks of white space into a single
space. 

All of these issues are desireable UI changes.

The plus side is that fixing them the way we wanted them all along also fixes
this security issue.

Comment 5

[David :Bienvenu]

Comment on attachment 190485 [details] [diff] [review]
the fix

cool

Comment 6

[Scott MacGregor]

Attachment: fix for checking in

includes the changes to pinstripe in case this patch lands on a branch

Comment 7

[Scott MacGregor]

Dan, I've checked this in and we now get rid of the extra white space and we
crop the file name so you always see the extension. Let me know if there's more
work you'd like to see here. 

Comment 8

[Daniel Veditz [:dveditz]]

Comment on attachment 190646 [details] [diff] [review]
fix for checking in

a=dveditz for drivers

Comment 9

[Tim Riley [:timr]]

Too late for 1.0.8/1.7.14.

Comment 10

[Tim Riley [:timr]]

Comment on attachment 190646 [details] [diff] [review]
fix for checking in

Too late for 1.0.8

Comment 11

[Karsten Düsterloh]

Attachment: SeaMonkey patch

Changes needed for SeaMonkey's attachment box. I did only strip trailing whitespace to avoid Windows dropping them in filename extensions; inner whitespace will be caught by the crop attribute anyway.
The patch is against trunk, but should apply to branch with no real changes.
Requesting approval‑seamonkey1.1.3 via whiteboard. :-/

Comment 12

[Robert Kaiser]

a=me for 1.1.3 given this get positive reviews.

Comment 13

[Karsten Düsterloh]

Comment on attachment 271260 [details] [diff] [review]
SeaMonkey patch

Landed on trunk and MOZILLA_1_8_BRANCH without the superfluous regexp's g flag.

Comment 14

[Karsten Düsterloh]

Attachment: also fix SM's attachment menu

As David pointed out in bug 386855, we need to correct the File->Attachments menu also: you could choose "Open" and have it configured to automatically launch an application...

Comment 15

[Robert Kaiser]

Comment on attachment 271708 [details] [diff] [review]
also fix SM's attachment menu

a=me for 1.1.3 given it passes review (per IRC request)

Comment 16

[Karsten Düsterloh]

Comment on attachment 271708 [details] [diff] [review]
also fix SM's attachment menu

Landed on trunk and MOZILLA_1_8_BRANCH.