Closed Bug 881680 Opened 11 years ago Closed 10 years ago

Mozilla Thunderbird v17.0.6 - Input Filter Bypass & Encoding Vulnerability

Categories

(Thunderbird :: Security, defect)

Product:
Thunderbird
Component:
Security
Version:
17 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: curtisk, Unassigned, NeedInfo)

Details

(Whiteboard: [reporter-external])

Attachments

(8 files)

1.png
224.65 KB, image/png
Details
2.png
148.62 KB, image/png
Details
3.png
174.26 KB, image/png
Details
4.png
183.80 KB, image/png
Details
5.png
119.69 KB, image/png
Details
7.png
115.14 KB, image/png
Details
9.png
258.96 KB, image/png
Details
Exported Database File - POC Filter & Embed String
6.00 KB, text/plain
Details 
Date: Mon, 10 Jun 2013 20:24:45 +0100
From: Vulnerability Lab <admin@vulnerability-lab.com>
To: Mozilla Security <security@mozilla.org>
Subject: Mozilla Thunderbird v17.0.6 - Input Filter Bypass & Encoding
	Vulnerability
-----//-----
Title:
======
Mozilla Thunderbird v17.0.6 - Input Filter Bypass & Encoding Vulnerability


Date:
=====
2013-06-09


References:
===========
http://www.vulnerability-lab.com/get_content.php?id=964


VL-ID:
=====
964


Common Vulnerability Scoring System:
====================================
4.6


Introduction:
=============
Thunderbird is a free, open-source, cross-platform application for
managing email and news feeds. It is a local
(rather than a web-based) email application that is powerful yet
easy-to-use. Thunderbird has lots of cool features.
Thunderbird gives you control and ownership over your email. There are
lots of add-ons available for Thunderbird that
enable you to extend and customize your email experience. Thunderbird is
part of the Mozilla Manifesto, a pledge that
describes Mozilla`s commitment to an open, accessible, egalitarian Internet.

Vendor Homepage: http://www.mozilla.org
Product website: http://www.mozilla.org/en-US/thunderbird/


Abstract:
=========
The Vulnerability Laboratory Research Team discovered a filter bypass
and encoding vulnerability in the Mozilla Thunderbird v17.0.6 software
client.


Report-Timeline:
================
2013-05-30: Researcher Notification & Coordination (Ateeq Khan)
2013-06-09: Vendor Notification (Mozilla - Security Incident Team)
2013-00-00: Vendor Response/Feedback (Mozilla - Security Incident Team)
2013-00-00: Vendor Fix/Patch (Mozilla - Developer Team)
2013-00-00: Public Disclosure (Vulnerability Laboratory)


Status:
========
Unpublished


Affected Products:
==================
Mozilla
Product: Thunderbird - EMail Application 17.0.6


Exploitation-Technique:
=======================
Remote


Severity:
=========
Medium


Details:
========
A input filter restriction bypass vulnerability is detected in the
official Mozilla Thunderbird Mail v17.0.6 Software Client.
The vulnerability allows to bypass the input restriction filter and
validation process to unauthorized include own context.

The addressbook impacts a filter restriction for the input of new
contacts. When an user inserts any kind of other context
then an email the validation drops an handled exception with the message
...
`The primary E-Mail Address must recognize the form name@domain.de`

We was testing another software with a mail encoding problem and send a
test mail to our thunderbird test client to review.
We found a way to bypass the address book input field filter form
restriction. When you try to inject emails and save them
as an account it is normally not possible and they get parsed but when
you use a manipulated client to submit with the
normal mail and a secound receiver (with an embed payload) the input can
be saved to the address book and bypasses
the email restriction exception.

After the bypass the attacker is able to include in the string which is
already parsed and saved a new entry for the embed code to
load other external link from the mailto: link which should normally
redirect to the mails itself. The attacker leaves the /embed
in the input field and includes for example the earlier inserted embed
string. When the contact itself is opened the mailto link
will become and href link and can unauthorized redirect to another
location as the standard email.

The vulnerability can be exploited by local attackers with a privilege
system user account without required user interaction.
Successful exploitation results in unauthorized input filter restriction
bypass and persistent implement of embed code to
manipulate contact mailto: links.

Vulnerable Section(s):
               [+] Address Book

Vulnerable Module(s):
               [+] Input Restriction Filter Form & Exception-Handling

Vulnerable Parameter(s):
               [+] Contact Email Name


Proof of Concept:
=================
The vulnerability can be exploited by local attackers with low
privileged system user account and low user interaction (click).
For demonstration or reproduce ...

1.  Install mozilla thunderbird and open the software
2.  Send a mail from another client and inject to the mail header (send
to:) an embed payload as test string with svg src object base64
3.  Go to the thunderbird mailbox and open the message listing
4.  Save the context and the base64 encoded embed string has been
changed to /embed after the first encoding of the thunderbird client
validation
5.  Exchange the name embed and include the original injected payload
with svg object base64 encoded from ago
6.  Leave the already included `/` on begin of the input to simulate as
already parsed from the client validation itself
7.  Save the message and resend the message to the contact with the same
details and the already new included payload
8.  Now you are able to save the context with the wrong values of the
input and the restriction input filter has also been bypassed
9.  Watch the mail and click the link inside of the contact listing
which has been marked in the screenshot
10. Vulnerability successful reproduced!

Reference(s):
           ../1.png
           ../2.png
           ../3.png
           ../4.png
           ../5.png
           ../6.png
           ../7.png
           ../8.png
           ../9.png


Solution:
=========
To fix/patch the input filter restriction bypass vulnerability in the
input field of the email the parse function need to catch
also embed obfuscated payloads with img svg object tags.

In the secound instance the wrong encoded payload redisplay in the email
contact listing of the `addressbook` needs to
be parsed in a seperate way.



Risk:
=====
The security risk of the persistent input validation web vulnerability
and filter bypass issue are estimated as medium(+).


Credits:
========
Vulnerability Laboratory [Research Team] - Benjamin Kunz Mejri
(bkm@vulnerability-lab.com)


Disclaimer:
===========
The information provided in this advisory is provided as it is without
any warranty. Vulnerability-Lab disclaims all warranties,
either expressed or implied, including the warranties of merchantability
and capability for a particular purpose. Vulnerability-
Lab or its suppliers are not liable in any case of damage, including
direct, indirect, incidental, consequential loss of business
profits or special damages, even if Vulnerability-Lab or its suppliers
have been advised of the possibility of such damages. Some
states do not allow the exclusion or limitation of liability for
consequential or incidental damages so the foregoing limitation
may not apply. We do not approve or encourage anybody to break any
vendor licenses, policies, deface websites, hack into databases
or trade with fraud/stolen material.

Domains:    www.vulnerability-lab.com       - www.vuln-lab.com       
          - www.vulnerability-lab.com/register
Contact:    admin@vulnerability-lab.com     -
support@vulnerability-lab.com            - research@vulnerability-lab.com
Section:    video.vulnerability-lab.com     -
forum.vulnerability-lab.com                - news.vulnerability-lab.com
Social:        twitter.com/#!/vuln_lab         -
facebook.com/VulnerabilityLab            -
youtube.com/user/vulnerability0lab
Feeds:        vulnerability-lab.com/rss/rss.php    -
vulnerability-lab.com/rss/rss_upcoming.php   -
vulnerability-lab.com/rss/rss_news.php

Any modified copy or reproduction, including partially usages, of this
file requires authorization from Vulnerability Laboratory.
Permission to electronically redistribute this alert in its unmodified
form is granted. All other rights, including the use of other
media, are reserved by Vulnerability-Lab Research Team or its suppliers.
All pictures, texts, advisories, source code, videos and
other information on this website is trademark of vulnerability-lab team
& the specific authors or managers. To record, list (feed),
modify, use or edit our material contact (admin@vulnerability-lab.com or
support@vulnerability-lab.com) to get a permission.

                          Copyright © 2013 | Vulnerability Laboratory




-- 
VULNERABILITY RESEARCH LABORATORY
LABORATORY ADMINISTRATION
CONTACT: admin@vulnerability-lab.com
Flags: sec-bounty?
Flags: needinfo?(mbanner)
Mark, what do you think about this issue? How severe is it?
To me, it is unclear. I *think* it is relying on someone to reply to the message, or add a contact and not notice the weird embed string.

It is also confusing, as steps 4 - 7 imply that there's some additional modifications to the email going on.

I'd really like to see an example email with the minimal steps to repeat from a Thunderbird perspective - what do I need to click on?
Flags: needinfo?(mbanner)
When the embed string will be injected the first time the validation of the software client parses the context in the first reload and replace the input with /embed ... after this parse you only need to include the payload a secound time again with %20 on beginning and the script code bypass the filter + will be executed from the listing context. 

When i tried to export the contact file i had some problem with the internal validation and the downlaod of the exported file was not working without any exception-handling or error. Later i was thinking about the validation perspective because it makes sense the export is not working because when it exports the validation is back working. 

~bkm
With the last sentence i was trying to say ... the function is running reverse which results maybe in the successful parse only on export.
Does the embed execute? Would a <script> tag?

If they execute this would probably be sec-moderate because of the user-interaction required (it's not a drive-by), although if it then executes with chrome privileges we could bump it up to sec-high (but don't think that's a privileged docshell).

If scripts or plugins don't execute then this is really just vandalism and we could call it sec-low.
After the bypass and include like shown in the pictures the attacker is of course able to execute the embed code. It is also possible to remotely exchange via export of the contacts and low required user interaction on the imports. The frame we injected got executed with chrome privileges in the normally secure encoded section.

I would estimate as risk of high but not critical because of the persistent vector combined with the input filter bypass issue.

~Benjamin Kunz Mejri
At this point, we really need another confirmation before we can rate, based on comments 12, 13 and 14.
Flags: needinfo?(mbanner)
Sorry for not responding earlier.

If I'm understand this right, then attacker sends email with payload. Attacker then modifies the payload and resends.

However, the instructions don't make it clear how the contact is saved without the user doing something or noticing the really weird string in the header.

I'd also really like to see a raw email with the example payload before sending to the client as per step 2.
Flags: needinfo?(mbanner)
"If I'm understand this right, then attacker sends email with payload. Attacker then modifies the payload and resends."

YES, with the already saved account from the embed inject in the input.
The user only one time needs to answer to save the contact and the code will be executed from the listing were i marked in the screenshot. You should not need to recognize on the reproduce the validation of the message itself because the contact name is the problem not the message.

Take the already uploaded file were the contact is listed. The mail itself does not impacts the problem only the sender is affected when listing after a successful send o the user mail as payload.

Created attachment 777325 [details]
Exported Database File - POC Filter & Embed String
Dan will try to rate this one.
Flags: needinfo?(dveditz)
yes much thanks! 

- Benjamin
...
Ludovic, can you look at this and see if you can reproduce the issue?
Flags: needinfo?(dveditz) → needinfo?(ludovic)
Ok so I was able to get the bogus AB loaded. I was unable to compose any new email with the bogus entries in it.
I was unable to use the other mailers I use to produce the bogus email in my mailbox :( benjamin feel free to send such email my way -> ludovic@mozilla.com
Flags: needinfo?(ludovic)
Are you able to reproduce the issue local after the import and second save?
Yes, we tested it remote by sending the AB and import of contact but not via mail.
We can try to verify the mail way too after you answered me the short question @Ludovic-Hirlimann

- Benjamin
(In reply to Benjamin Kunz Mejri from comment #23)
> Are you able to reproduce the issue local after the import and second save?
> Yes, we tested it remote by sending the AB and import of contact but not via
> mail.
no cause I'm a bit confused on what to do. So I'd like to be the victim of an attack to see by myself.
Flags: needinfo?(admin)
we definitely need more info on this.  we will keep it open for a little bit longer before we close in case the reporter has more info.
yes, i was in an important pentest. Now i am back, sorry for the delay.
Regular the issue does not execute when you send somebody a mail of course he has to implement the address-book too. i it already attached in a message ago. > attachment 777325 [details]

1. Include the address book
2. Write yourself a message
3. Open the address book (now the embed string has been changed to the tag \embed which proof that the valid is already bypassed because it is forbidden to include this characters.)
4. Change the string manually again to the embed string like ago and the save it by closing the mask of input
5. Open the included entry and you will see the code executes in the marked location were i produced a screenshot

- Ben
Flags: needinfo?(admin)
Ben, please can you attach an example email (not address book), so that we can track this through from the actual injection point (being able to see the structure of the email itself). Thanks.
Flags: needinfo?(admin)
Hello Mark,
yes i will send soon a test mail. Please provide me the arrival mailbox. (mbanner@mozilla.com ?)
Flags: needinfo?(admin)
(In reply to Benjamin Kunz Mejri from comment #28)
> Hello Mark,
> yes i will send soon a test mail. Please provide me the arrival mailbox.
> (mbanner@mozilla.com ?)

and cc ludovic@mozilla.com
not clear if the test case was e-mailed, or evaluated?

what are next steps here?
I am actually in a big pentesting job but at friday i send the testmail to the following account ...
mbanner@mozilla.com. Ensure that the mail arrival box impact the modified file of my thunderbird attached ago.

- Benjamin
Hi Benjamin,

do you mean you are sending it on Friday 6th, or that you sent it last Friday? I just checked my spam filters and I couldn't see anything from you at all.
6th when i am back in the office have not send it ago was waiting for a confirm.
sorry for the confusion.

~benjamin
Hi Benjamin,

Thanks for the email I received. I have tried some experiments both with the ldif file you sent me and with attachment 777325 [details] and I can't find a way to reproduce this.

My current thoughts are that this may be a possible attack for the address book by convincing the user to import a bad address book, but I can't see any way an attacker could cause it otherwise - but that is a guess, as I can't reproduce this.


What I really need to move forward with analysis:

1) An address book database in mork format as saved by Thunderbird, storing a card that shows the vulnerability in a new, unmodified (except for basic import of mail account) Thunderbird profile.

=> If you create a new address book and copy the contact into this, then in the profile, it should be one of the *.mab files (you can look at the ldap_2.* preferences to confirm which one).

2) An email with the payload that shows how this attack can be executed from outside, without the user changing items within the address book.


I'm sorry this is taking so long. I've tried multiple things, and feel like I'm missing something obvious. I'm hopeful that having an actual address book in Thunderbird's native format will make this easier to solve, and by having an email, confirm if this is reproducible by external attack, without user action.

Thanks.
Hello Mr. Banner,
no problem, its my job to do this daily. I am following your steps and will soon provide you the required files to continue. Like you can see in the images the local execute has already works excellent. I only want to ensure with you the remote exploitation works too. ~benjamin
Hi Benjamin, just to be clear - I can't reproduce neither the local case nor the remote case, which is why I'd like to get appropriate files and payloads.
If we cannot get a reliable repro case, we're going to close this as incomplete in a week. This bug is lingering and not currently actionable.
Flags: needinfo?(curtisk)
switching the needinfo to the reporter
Flags: needinfo?(curtisk) → needinfo?(admin)
Group: mail-core-security
Resolving as incomplete as discussed in comment 37 because it cannot be reproduced and reporter is not responding to questions.
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Flags: sec-bounty?
Resolution: --- → INCOMPLETE
Group: mail-core-security
Group: core-security → core-security-release
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: