Closed Bug 473924 Opened 15 years ago Closed 15 years ago

thunderbird crashes when trying to open a base64 encode vcard [@ fakeCString]

Categories

(MailNews Core :: Backend, defect)

1.9.1 Branch
x86
All
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 3.0b2

People

(Reporter: christian.fertig, Assigned: Bienvenu)

References

Details

(Keywords: crash, fixed1.8.1.21, testcase, Whiteboard: [sg:dos] null deref)

Crash Data

Attachments

(3 files)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.0.5) Gecko/2008121300 SUSE/3.0.5-1.1 Firefox/3.0.5
Build Identifier: Version 2.0.0.19 (20081227)

I can reproducable crash thunderbird (all 2.x versions, Linux and Windows, all younger seamonkeys on both platforms) when trying to open a special mail containing a base64 encoded attached vcf (vcard).



Reproducible: Always

Steps to Reproduce:
1. Klick on the mail (with the normal 3 panel view, where a mail is displayed 
   immediately


Actual Results:  
thunderbird crashes instantly

Expected Results:  
- thunderbird should not crash
- perhaps, this special attachment is broken somehow. Then tb should display an 
  error.

This is the content of such a mail, crashing tb:

Return-Path: <root@pelikan.consense.de>
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed;
        boundary="----_=_NextPart_001_01C8F7F4.5B0942B9"
Subject: test
Date: Wed, 6 Aug 2008 20:43:43 +0200
Message-ID: <2735BB01E874D3@example.com>
From: "Christian Fertig" <abc@example.com>
To: <abc@example.com>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8F7F4.5B0942B9
Content-Type: multipart/alternative;
        boundary="----_=_NextPart_002_01C8F7F4.5B0942B9"


------_=_NextPart_002_01C8F7F4.5B0942B9
Content-Type: text/plain;
        charset="utf-8"

Hello, World

------_=_NextPart_001_01C8F7F4.5B0942B9
Content-Type: text/x-vcard;
        name="ChristianFertig.vcf"
Content-Transfer-Encoding: base64
Content-Description: C:\DOKUME~1\Heinrich\LOKALE~1\Temp\2\ChristianFertig.vcf
Content-Disposition: attachment;
        filename="ChristianFertig.vcf"

QkVHSU46VkNBUkQKVkVSU0lPTjoxLjIKRk46Q2hyaXN0aWFuIEZlcnRpZwpOOkZlcnRpZztDaHJp
c3RpYW47O0hlcnI7CkFEUjtXT1JLOjs7RGVjaGVuc3RyYcOfZTtSYXRpbmdlbjs7NDA4Nzg7ClRF
TDtXT1JLOis0OSAxMjM0IC0gNTY3OApURUw7Q0VMTDorNDkgMTIzNCAtIDU2NzgKVEVMO0ZBWDor
NDkgMTIzNCAtIDU2NzgKRU1BSUw7OmNocmlzdGlhbi5mZXJ0aWdAY29uc2Vuc2Utc2VydmljZS5k
ZQpPUkc6Y29uc2Vuc2Ugc2VydmljZSBnbWJoICYgY28uIGtnOwpVUkw7V09SSzp3d3cuY29uc2Vu
c2Utc2VydmljZS5kZQpFTkQ6VkNBUkQK

------_=_NextPart_001_01C8F7F4.5B0942B9--
Fertig, need talkback crash id
Severity: normal → critical
Keywords: crash
oh, and can you reproduce using beta?
 http://www.mozillamessaging.com/en-US/thunderbird/early_releases/
backup your profile first
(In reply to comment #1)
> Fertig, need talkback crash id

I don't have one, thunderbird "is away" in milliseconds ;)
(In reply to comment #3)
> (In reply to comment #1)
> > Fertig, need talkback crash id
> 
> I don't have one, thunderbird "is away" in milliseconds ;)

This is where the early release will help as it's crash reporter is way more efficent.
(In reply to comment #2)
> oh, and can you reproduce using beta?
>  http://www.mozillamessaging.com/en-US/thunderbird/early_releases/
> backup your profile first

I took thunderbird 3.0 beta 1 for Linux

Saved the mail from my initial report to a file "test.eml"

tried to open the file via "file -> open"

tb 3.0 b1 crashes immediatly, like the other ones.

I get the following messages from talkback:

Add-ons: {972ce4c6-7e08-4474-a285-3208198ce6fd}:2.0
BuildID: 20081204114258
CrashTime: 1234443720
InstallTime: 1234443696
ProductName: Thunderbird
StartupTime: 1234443700
Theme: classic/1.0
UserID: 18e62187-1754-ea59-db98-76127291d320
Vendor: 
Version: 3.0b1

Diese Meldung enthält Informationen über den Status der Anwendung zum Zeitpunkt des Absturzes.


I told the dialog to inform mozilla about the crash and put the title of this bug report and the bug number in the notice field, if this helps...

regards,
Christian
why isn't processing finishing on bp-18e62187-1754-ea59-db98-76127291d320 ?
(In reply to comment #6)
> why isn't processing finishing on bp-18e62187-1754-ea59-db98-76127291d320 ?

is the report sent by mail? we're blocking this internally.
Can you please somehow attach such a mail as attachment to this bug? Just move it into its own folder and upload the MBOX file. Thanks.
Wayne or Ludovic, I don't have time right now to check bugs for Thunderbird. It would be great if one of you guys could have a look at this and try to reproduce.

Christian, can you crash Thunderbird again and see, if the new report is correctly processed? Probably something messed up on the last one. If it doesn't work we should call for help from IT.
(In reply to comment #10)

> doesn't work we should call for help from IT.

You should we ping ?
earlier today I PMed Christen to see if the crash actually submitted (sorry for not putting it in the bug, no time), because I found out after filing IT Bug 478244 that they couldn't find the crash.  

crash-stats apparently doesn't tell you when # given to crash-stats is invalid - it just says "processing". xref bug 428291
mmustermann@kojote:..mmustermann/.thunderbird > zip -r /tmp/crashreports.zip Crash\ Reports
updating: Crash Reports/ (stored 0%)
  adding: Crash Reports/UserID (stored 0%)
  adding: Crash Reports/crashreporter.ini (deflated 5%)
  adding: Crash Reports/LastCrash (stored 0%)
  adding: Crash Reports/submitted/ (stored 0%)
  adding: Crash Reports/submitted/bp-7354baa6-ca7f-46b2-a2dc-45d222090213.txt (stored 0%)
  adding: Crash Reports/InstallTime20081204114258 (stored 0%)
  adding: Crash Reports/submit.log (stored 0%)
  adding: Crash Reports/pending/ (stored 0%)
0  	thunderbird-bin  	fakeCString  	nsVCardObj.cpp:1317
1 	thunderbird-bin 	MimeInlineTextVCard_parse_eof 	mimevcrd.cpp:418
2 	thunderbird-bin 	MimeMultipart_close_child 	mimemult.cpp:616
3 	thunderbird-bin 	MimeMultipart_parse_line 	mimemult.cpp:185
4 	thunderbird-bin 	convert_and_send_buffer 	mimebuf.cpp:184
5 	thunderbird-bin 	mime_LineBuffer 	mimebuf.cpp:272
6 	thunderbird-bin 	MimeObject_parse_buffer 	mimeobj.cpp:287
7 	thunderbird-bin 	MimeMessage_parse_line 	mimemsg.cpp:240
8 	thunderbird-bin 	convert_and_send_buffer 	mimebuf.cpp:184
9 	thunderbird-bin 	mime_LineBuffer 	mimebuf.cpp:272
10 	thunderbird-bin 	MimeObject_parse_buffer 	mimeobj.cpp:287
11 	thunderbird-bin 	mime_display_stream_write 	mimemoz2.cpp:946
12 	thunderbird-bin 	nsStreamConverter::OnDataAvailable 	nsStreamConverter.cpp:938
13 	thunderbird-bin 	nsMailboxProtocol::ReadMessageResponse 	nsMailboxProtocol.cpp:593
14 	thunderbird-bin 	nsMailboxProtocol::ProcessProtocolState 	nsMailboxProtocol.cpp:690
15 	thunderbird-bin 	nsMsgProtocol::OnDataAvailable 	nsMsgProtocol.cpp:347
16 	thunderbird-bin 	nsInputStreamPump::OnStateTransfer 	netwerk/base/src/nsInputStreamPump.cpp:508
17 	thunderbird-bin 	nsInputStreamPump::OnInputStreamReady 	netwerk/base/src/nsInputStreamPump.cpp:398
18 	libxpcom_core.so 	libxpcom_core.so@0x4448c 	
19 	libxpcom_core.so 	libxpcom_core.so@0x58ca7 	
20 	libxpcom_core.so 	libxpcom_core.so@0x27342 	
21 	thunderbird-bin 	nsBaseAppShell::Run 	widget/src/xpwidgets/nsBaseAppShell.cpp:170
22 	thunderbird-bin 	nsAppStartup::Run 	toolkit/components/startup/src/nsAppStartup.cpp:192
23 	thunderbird-bin 	XRE_main 	toolkit/xre/nsAppRunner.cpp:3264
24 	thunderbird-bin 	main 	nsMailApp.cpp:103
25 	libc-2.9.so 	libc-2.9.so@0x16704
Status: UNCONFIRMED → NEW
Ever confirmed: true
IS this the same cause as bug 462528 ?
Component: General → Backend
Product: Thunderbird → MailNews Core
QA Contact: general → backend
Version: unspecified → 1.9.1 Branch
iirc that was my best guess after seeing comment 0
Summary: thunderbird crashes when trying to open a base64 encode vcard → thunderbird crashes when trying to open a base64 encode vcard [@ fakeCString]
I'll take a look at this.
Assignee: nobody → bienvenu
Status: NEW → ASSIGNED
Group: core-security
Attached patch proposed fixSplinter Review
this fixes the crash. It should also help if setVObjectUStringZValue were ever called with null (though I'm not sure it gets called). Thx very much for the test case.
Attachment #362232 - Flags: superreview?(neil)
Attachment #362232 - Flags: review?(neil)
I marked this security sensitive just to be on the safe side.
Attachment #362232 - Flags: superreview?(neil)
Attachment #362232 - Flags: superreview+
Attachment #362232 - Flags: review?(neil)
Attachment #362232 - Flags: review+
fix checked in.
Target Milestone: --- → Thunderbird 3.0b2
Comment on attachment 362232 [details] [diff] [review]
proposed fix

1.8.1 branch could use the same fix.
Attachment #362232 - Flags: approval1.8.1.next?
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Flags: wanted1.8.1.x+
Whiteboard: [sg:dos] null deref
Comment on attachment 362232 [details] [diff] [review]
proposed fix

>+  t = s = (char*)PR_CALLOC(len);

This will still crash if OOM, t is deref'd without checking. If alloc for a normal-sized vCard fails we're probably not going to survive anyway, but a super-huge one could still be a DoS attack here.

>+  if (u) {

Could change that to "if (u && t) {", and another if (t) before null terminating.
Or just "if (!s) return s;" right after the calloc.

Can all the callers of fakeCString handle a null return, or do they make unwarranted assumptions? Is this just moving a crash around (albeit a less common one)?
if I understand you correctly, with the patch I checked in, it won't be a null return; it will be an empty string, "", which fixes the problem. The callers definitely crash with a null return.
You won't return an empty string if PR_CALLOC fails, fakeCString will crash. If you protect against that crash in the simple ways I suggested then fakeCString returns null and apparently its callers will crash.
ah, yes, I see what you're saying - yes, the consumers of fakeCString will crash if it's null, I believe. I'm not sure how to handle calloc failures; that requires a bit more thought.
Attachment #362232 - Flags: approval1.8.1.next? → approval1.8.1.next+
Comment on attachment 362232 [details] [diff] [review]
proposed fix

Approved for 1.8.1.21, a=dveditz for release-drivers
fixed for 1.8.1.21
Keywords: fixed1.8.1.21
There is a minimal testcase for this bug in bug 480781.
Flags: in-testsuite?
Keywords: testcase
Group: core-security
Crash Signature: [@ fakeCString]
You need to log in before you can comment on or make changes to this bug.