714472 - (CVE-2012-0448) [SECURITY] utf8 homoglyphs are allowed in email addresses, which could allow an attacker to be CC'ed to private bugs by accident

Status: RESOLVED FIXED

(Bugzilla :: User Accounts, defect)

Description

[Jаmes Kettle]

Bugzilla allows utf8 in email addresses, including characters in the Cryllic alphabet that look identical to standard ascii letters. For example, [e-mail] and а[e-mail] are two distinct email addresses (the latter has a Cryllic a). Given that email addresses are used as usernames, this poses an impersonation risk. It could also be used by an attacker to maintain access to a victim's account, since their email address wouldn't appear to have changed.

Such attacks are severely limited by bugzilla's email validation process. I have been unable to figure out where emails sent by the current version of BMO to addresses containing utf8 actually end up. Bugzilla 4.2rc1+ sends emails to addresses with utf8 preceding the @ fine (eg bа[e-mail]), but again utf8 in the domain name (eg good@fridаy.slyip.net) causes the emails to go missing. Allowing utf8 in the domain name would be much worse, since anyone could register gmаil.com or mozillа.org

I'm not yet certain that I have fully explored the threats posed by this.

Comment 1

[Reed Loden [:reed]]

See also bug 714488, which caused me not to see this bugmail. :/

Comment 2

[Frédéric Buclin]

Bug 319953 would be a first step to fix this problem, or even fix it entirely. For the record, valid email addresses are defined in RFC 5322 section 3.4.1 (which obsoletes RFC 2822, which itself obsoleted RFC 822), see http://tools.ietf.org/html/rfc5322#section-3.4.1

Comment 3

[Jаmes Kettle]

Adhering to the RFC looks like a sensible fix.

Bugzilla 4.2rc1+ will send email to addresses with utf8 in the domain name. Rather than encoding the utf8 with punycode it uses some other method. This was established using good@bаd.sunday.slyip.net and setting a DNS wildcard for *.sunday.slyip.net

This means any legitimate email address can be spoofed.

Comment 4

[Frédéric Buclin]

I tested а[e-mail] (with the Cryllic a) against $Email::Address::addr_spec, and it passes.

rjbs: per RFC 2822 and RFC 5322 section 3.4.1, it appears that dot-atom is based on atext (section 3.2.3/3.2.4) which itself contains ALPHA, which seems to be "Any character except controls, SP, and specials". But it says nothing about US-ASCII or the whole Unicode range, unless I miss something. Do you know if ALPHA really means US-ASCII only or the whole Unicode range?

Comment 5

[Ricardo SIGNES]

mailbox data are entirely ASCII.  Those RFCs predate Unicode, and §1.2 specifies ASCII anyway.  I have just released 1.893, which rejects non-ASCII input prima facie.

Comment 6

[Frédéric Buclin]

Attachment: patch, v1

This patch is for branches only. It rejects non-ASCII characters. For trunk, we will use the patch from bug 319953.

With this patch, sanitycheck.cgi will now also catch email addresses with non-ASCII characters.

Comment 7

[Frédéric Buclin]

James said he successfully got bugmails from landfill with an account which has non-ASCII characters in the email address, so this is exploitable. The attacker could use this trick to get access to bugs he shouldn't be allowed to see if his email address looks similar to e.g. a member of the security team. The user wanting to CC the security guy could inavertendly CC the wrong user, as the email address would appear to be correct in the user-autocompletion list.

Comment 8

[:glob ✱]

Comment on attachment 585387 [details] [diff] [review]
patch, v1

r=glob

looks and works good.

the error message displayed could be misleading:

The e-mail address you entered (チーズ@glob.com.au) didn't pass our syntax checking for a legal email address. A legal address must contain exactly one '@', and at least one '.' after the @. It must also not contain any of these special characters: \ ( ) & < > , ; : " [ ], or any whitespace. 

perhaps:

... It must also not contain any of these special characters: \ ( ) & < > , ; : " [ ], any whitespace or non-English characters.

Comment 9

[Gervase Markham [:gerv]]

"Non-English characters" is not the right description - there are plenty of non-English languages which use these characters. "Non-Latin letters" would be a bit more accurate - A-Z is the Latin alphabet.

However, I'm not sure this is the right fix. 
http://en.wikipedia.org/wiki/Unicode_and_email says that there is an RFC 2047, which explains how e.g. Japanese people can use their own names as email addresses. That's a low-numbered RFC; presumably there is support for it? 

Also, we need to support IDN domain names, and the proper display thereof.

I agree that this problem is a problem; however, telling people they can't use their Internationalized Domain Names or perfectly legal email addresses in Bugzilla isn't the right fix.

Gerv

Comment 10

[Frédéric Buclin]

(In reply to Gervase Markham [:gerv] from comment #9)
> http://en.wikipedia.org/wiki/Unicode_and_email says that there is an RFC
> 2047, which explains how e.g. Japanese people can use their own names as
> email addresses.

No, RFC 2047 (which is updated by RFC 2231) says that you can use Unicode for your real name, not in the email address itself. Bugzilla is fine with Unicode in the real name.

The other RFC mentioned in this page, RFC 3490, is obsoleted by RFC 5891. And RFC 5891 states that (section 3.2.2):

  "IDNA does not update the
   existing email standards, which allow only ASCII characters in local
   parts.  Even though work is in progress to define
   internationalization for email addresses [RFC4952], changes to the
   email address part of the SOA RDATA would require action in, or
   updates to, other standards, specifically those that specify the
   format of the SOA RR."

RFC 4952 is itself updated by RFC 5336 which has the status "EXPERIMENTAL". So I wouldn't rely on it till it becomes a real standard. For now, I prefer the safe approach and ban non-ASCII characters.

For your information, the proposed syntax for email addresses is defined in RFC 5335, section 4.4: http://tools.ietf.org/html/rfc5335#section-4.4, where UTF8 characters would be allowed in both the local part and domain name of the email address.


> I agree that this problem is a problem; however, telling people they can't
> use their Internationalized Domain Names or perfectly legal email addresses
> in Bugzilla isn't the right fix.

No current specification says that it's currently legal to use the Internationalized Domain Names in email addresses. The two specs RFC 5335 and 5336 are still experimental.

Comment 11

[Frédéric Buclin]

Read also RFC 4952 section 9 "Security Considerations":

 http://tools.ietf.org/html/rfc4952#section-9

In particular:

  "In addition, email addresses are used in many contexts other than
   sending mail, such as for identifiers under various circumstances
   (see Section 6.3).  Each of those contexts will need to be evaluated,
   in turn, to determine whether the use of non-ASCII forms is
   appropriate and what particular issues they raise."

Comment 12

[Gervase Markham [:gerv]]

OK, fair enough. But once people work out how to do this, we are going to need a different fix :-)

Gerv

Comment 13

[Frédéric Buclin]

(In reply to Gervase Markham [:gerv] from comment #12)
> OK, fair enough. But once people work out how to do this, we are going to
> need a different fix :-)

Sure, but this won't happen before several years, IMO.


(In reply to Gervase Markham [:gerv] from comment #9)
> "Non-English characters" is not the right description - there are plenty of
> non-English languages which use these characters. "Non-Latin letters" would
> be a bit more accurate - A-Z is the Latin alphabet.

The problem with "Non-Latin letters" is that nobody will understand what this means, besides geeks. If we cannot propose a good wording which everybody can understand, I prefer to not rephrase the error message. Remember that the email address must be real, and I doubt there are non-latin email addresses in the wild already.

Comment 14

[Ricardo SIGNES]

"Non-Latin letters" is wrong for Geeks anyway.  There are 1176 Unicode codepoints considered Latin and Letter but not ASCII.  One of them is in my name, for Pete's sake!

I suggest "the email address you provided has illegal characters in it."  This restriction should never be hit unless (a) the user is doing something weird, and probably already knows it or (b) the user has made a mistake, and can see it by looking.

Showing the illegal characters would be possible, if someone feels this is absolutely necessary, at least in the case of non-ASCII characters.  Giving a complete list of allowed characters in a help document would not be out of the question.

I would suggest not accepting characters with qtext in the local-part, which should greatly simplify what would have to be enumerated.

Comment 15

[Max Kanat-Alexander]

(In reply to Ricardo SIGNES from comment #14)
> I suggest "the email address you provided has illegal characters in it." 

  I'm fond of this particular bikeshed color.

Comment 16

[:glob ✱]

(In reply to Max Kanat-Alexander from comment #15)
> (In reply to Ricardo SIGNES from comment #14)
> > I suggest "the email address you provided has illegal characters in it." 
> 
> I'm fond of this particular bikeshed color.

me too.

Comment 17

[Ricardo SIGNES]

Please note that I've made another Email::Address release that loosens the restriction so that non-ASCII content is now allowed in the address phrase, but not the address itself.  That is, this is legal:

    "R. Julián Signes" <[e-mail]>

but not:

    "R. Signes" <rj́[e-mail]>

Comment 18

[Frédéric Buclin]

Attachment: patch for 4.2, v1.1

Say "illegal characters" instead of listing them explicitly.

Comment 19

[:glob ✱]

Comment on attachment 590578 [details] [diff] [review]
patch for 4.2, v1.1

r=glob

the error should say: "It also must not contain any illegal characters.", please fix on commit.

Comment 20

[Frédéric Buclin]

We won't take it for trunk, as bug 319953 already implemented this fix. I need to backport the patch to older branches as it has some bitrots.

Comment 21

[Frédéric Buclin]

Attachment: patch for 3.4 - 4.0, v1

This backport is for 4.0 and older branches. The single change is that the check was still done in editflagtypes.cgi instead of FlagType.pm.

Comment 22

[:glob ✱]

Comment on attachment 590731 [details] [diff] [review]
patch for 3.4 - 4.0, v1

r=glob

Comment 23

[Frédéric Buclin]

Gen, could we get your input on this issue?

<dveditz> LpSolit: huh, anyone know any big bugzilla deployments in asia?
<dveditz> I would be surprised if they didn't allow non-ascii mail addresses
<dveditz> spec or no spec
<dveditz> and I know for sure people get mail at IDNA domains (but the mail software uses the punycode (ASCII) representation to talk to each other)
<dveditz> maybe ask Gen, he'd know if asians used non-ascii mail addresses

Comment 24

[Daniel Veditz [:dveditz]]

use CVE-2012-0448 for this bug

Comment 25

[Gen Kanai [:gen]]

Offhand I do not know of any large bugzilla deployments in Asia (or where IDN are used.) 

I do know that in Japan, SMS was never used by the mobile carriers and in place of SMS was email. Email addresses were ascii (as IDN support for email only arrived recently.) So the practice of not supporting IDN in email is quite broad in Japan. 

We can ask Channy Yun for the status in Korea, Bob Chao for the status in Taiwan, and the Mozilla Online team for the status in China but my guess is that all across Asia, email has not supported IDN for the most part.

Comment 26

[Frédéric Buclin]

(In reply to Gen Kanai [:gen] from comment #25)
> but my guess is
> that all across Asia, email has not supported IDN for the most part.

OK, that's good enough for me. :) Thanks!

Comment 28

[Frédéric Buclin]

Committing to: bzr+ssh://[e-mail]/bugzilla/4.2/
modified Bugzilla/FlagType.pm
modified Bugzilla/Util.pm
modified template/en/default/global/code-error.html.tmpl
modified template/en/default/global/user-error.html.tmpl
Committed revision 8020.


Committing to: bzr+ssh://[e-mail]/bugzilla/4.0/
modified editflagtypes.cgi
modified Bugzilla/Util.pm
modified template/en/default/global/code-error.html.tmpl
modified template/en/default/global/user-error.html.tmpl
Committed revision 7686.


Committing to: bzr+ssh://[e-mail]/bugzilla/3.6/
modified editflagtypes.cgi
modified Bugzilla/Util.pm
modified template/en/default/global/code-error.html.tmpl
modified template/en/default/global/user-error.html.tmpl
Committed revision 7275.


Committing to: bzr+ssh://[e-mail]/bugzilla/3.4/
modified editflagtypes.cgi
modified Bugzilla/Util.pm
modified template/en/default/global/code-error.html.tmpl
modified template/en/default/global/user-error.html.tmpl
Committed revision 6825.

Comment 29

[Frédéric Buclin]

Security advisory sent, removing sec flag.