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)
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)
1.45 KB,
application/octet-stream
|
Details | |
1.71 KB,
application/zip
|
Details | |
1.23 KB,
patch
|
neil
:
review+
neil
:
superreview+
dveditz
:
approval1.8.1.next+
|
Details | Diff | Splinter Review |
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--
Comment 2•15 years ago
|
||
oh, and can you reproduce using beta? http://www.mozillamessaging.com/en-US/thunderbird/early_releases/ backup your profile first
Reporter | ||
Comment 3•15 years ago
|
||
(In reply to comment #1) > Fertig, need talkback crash id I don't have one, thunderbird "is away" in milliseconds ;)
Comment 4•15 years ago
|
||
(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.
Reporter | ||
Comment 5•15 years ago
|
||
(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
Comment 6•15 years ago
|
||
why isn't processing finishing on bp-18e62187-1754-ea59-db98-76127291d320 ?
Reporter | ||
Comment 7•15 years ago
|
||
(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.
Comment 8•15 years ago
|
||
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.
Reporter | ||
Comment 9•15 years ago
|
||
Comment 10•15 years ago
|
||
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.
Comment 11•15 years ago
|
||
(In reply to comment #10) > doesn't work we should call for help from IT. You should we ping ?
Comment 12•15 years ago
|
||
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
Reporter | ||
Comment 13•15 years ago
|
||
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%)
Comment 14•15 years ago
|
||
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
Comment 15•15 years ago
|
||
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
Comment 16•15 years ago
|
||
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]
Assignee | ||
Comment 17•15 years ago
|
||
I'll take a look at this.
Assignee: nobody → bienvenu
Status: NEW → ASSIGNED
Assignee | ||
Updated•15 years ago
|
Group: core-security
Assignee | ||
Comment 18•15 years ago
|
||
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)
Assignee | ||
Comment 19•15 years ago
|
||
I marked this security sensitive just to be on the safe side.
Updated•15 years ago
|
Attachment #362232 -
Flags: superreview?(neil)
Attachment #362232 -
Flags: superreview+
Attachment #362232 -
Flags: review?(neil)
Attachment #362232 -
Flags: review+
Assignee | ||
Comment 21•15 years ago
|
||
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?
Assignee | ||
Updated•15 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Updated•15 years ago
|
Flags: wanted1.8.1.x+
Whiteboard: [sg:dos] null deref
Comment 23•15 years ago
|
||
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)?
Assignee | ||
Comment 24•15 years ago
|
||
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.
Comment 25•15 years ago
|
||
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.
Assignee | ||
Comment 26•15 years ago
|
||
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.
Updated•15 years ago
|
Attachment #362232 -
Flags: approval1.8.1.next? → approval1.8.1.next+
Comment 27•15 years ago
|
||
Comment on attachment 362232 [details] [diff] [review] proposed fix Approved for 1.8.1.21, a=dveditz for release-drivers
Comment 30•15 years ago
|
||
There is a minimal testcase for this bug in bug 480781.
Flags: in-testsuite?
Keywords: testcase
Updated•15 years ago
|
Group: core-security
Updated•13 years ago
|
Crash Signature: [@ fakeCString]
You need to log in
before you can comment on or make changes to this bug.
Description
•