345355 - (CVE-2006-2087) Thunderbird allows attackers to cause a DoS via an attachment with an MS-DOS device filename

Status: RESOLVED WORKSFORME

(MailNews Core :: Attachments, defect)

Description

[Kohei Yoshino [:kohei]]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4
Build Identifier: N/A

JPCERT/CC team recently informed us at Mozilla Japan about this vulnerability.

The bug was originally found in a specific email client last September. JPCERT team has examined details and confirmed that it affected other clients including Thunderbird.

They'd like to know the status of bug fix in Thunderbird. I confirmed guru dveditz the bug has not been filed.

CVE-2006-2087
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2087

USCERT/CC VU#146542 (not published yet)

Reproducible: Always

Comment 1

[Kohei Yoshino [:kohei]]

related? bug 29079

Comment 2

[Kohei Yoshino [:kohei]]

I'll ask JPCERT team to send the details.

Comment 3

[Daniel Veditz [:dveditz]]

having an attachment with any of the following names may exploit this issue:

   AUX.txt
   COM1.txt
   LPT1.txt
   NUL.txt
   PRN.txt

Comment 4

[Kohei Yoshino [:kohei]]

They sent us their test result of Thunderbird (see below), but used version was 1.0.6. I'll test with the nightly.

CON.txt
Saved file is renamed to "CON-1.txt".

AUX.txt, LPT1.txt, NUL.txt and PRN.txt
Saving attachment cannot be completed, but you can cansel the process.

CLOCK$.txt, CONOUT$.txt and CONIN$.txt
To be displayed in notepad as a plain text file.

Comment 5

[Kohei Yoshino [:kohei]]

JPCERT team also noted the test has been conducted by IPA, Information-technology Promotion Agency, Japan, and there was no program stoppage. (Ouch!)

They'd like to know if Mozilla recognize the bug as a vulnerability.

Comment 6

[Daniel Veditz [:dveditz]]

> They'd like to know if Mozilla recognize the bug as a vulnerability.

We recognize this as a Denial-of-Service vulnerability, which is a low severity on non-server products.

Comment 7

[Daniel Veditz [:dveditz]]

Restoring lost blocking flag

Comment 8

[Daniel Veditz [:dveditz]]

Scott, David: any ETA for this?

I wonder if the browser would have the same problem, if you saved a link target whose name was one of these files? If so maybe the fix is in nsLocalFileWin.cpp returning an error, or saying a file with that name already exists....

Comment 9

[Daniel Veditz [:dveditz]]

We still want this one.

Comment 10

[Scott MacGregor]

Putting on the list so I don't lose track of this bug.

Comment 11

[Jay Patel [:jay]]

Scott:  I'm assuming this is still on your list, but updating flags since we want this for TB2.  If we get a fix for that, we can fix it on a future 1.8.0.x release.

Comment 12

[David :Bienvenu]

I tried this with an attachment named aux.txt - it failed to save, and we reported the error to the user (unable to save attachment - please check file name and try again). Granted, we don't tell them it's a reserved name...but I don't really see this as a DOS. It's impossible to create a file named aux.txt on Windows in general. When I try to save a file from Dev Studio 8 called aux.txt, it just fails silently. Am I missing the DOS part of this somehow?

Comment 13

[David :Bienvenu]

I should say my tests were done with TB 2.0 beta 2.

Comment 14

[Daniel Veditz [:dveditz]]

Just tried Tbird 1.5.0.10pre and WFM as David described in comment 12. I can't remember what I was seeing before. I just retested 1.5.0.4, too, with the same results.

The error is obvious, doesn't hang anything, and the user can always pick a new name and try again.

I also tried opening the attachments in an external app rather than saving (so I didn't get a chance to pick a new name) and those quickly failed as well. No hangs.

In 1.0.7 the behavior was different. You still get the "AUX.txt already exists, would you like to replace it?", and then it goes to the "Saving" screen where nothing ever happens. The Save has already failed, but we don't know that I guess. It's trivial to give up and cancel though -- if the progress meter isn't moving when saving to a local file it's pretty obvious something is wrong.

So this is fixed somewhere on the way to 1.5 -- I'm very sorry I tested the wrong one.