1202447 - (CVE-2015-4499) [SECURITY] The email address is not properly validated during registration if longer than 127 characters

Status: RESOLVED FIXED

(Bugzilla :: User Accounts, defect)

Description

[Netanel Rubin]

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.157 Safari/537.36

Steps to reproduce:

Hello,

My name is Netanel Rubin, I work as a vulnerability researcher at PerimeterX.

This is a critical vulnerability report for an issue I discovered in the Bugzilla platform. The successful exploitation of the vulnerability allows the creation of a user account under any email address, even those which are not under the attacker control.

As a PoC, I've created a test account under bugzilla.mozilla.org:
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb[e-mail]
I apologize for the length, it is required for the vulnerability.

I would like to report the complete vulnerability description over a private channel. I can post it here like the last time or can mail it to you, so please contact me at nati (-at-) perimeterx or in this thread.
Please assign a CVE number for this issue. We would also like to coordinate the public disclosure with you.

Best regards,
Netanel.

Comment 1

[Frédéric Buclin]

Please paste the details here.

Comment 2

[:glob ✱]

confirming.

looks like the account was created as

bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb[e-mail]

mysql truncates that to 255 chars when we insert into the db, resulting in 

bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb[e-mail]

Comment 3

[Netanel Rubin]

Attachment: Bugzilla - Authentication Mechanism Bypass.pdf

Comment 4

[Netanel Rubin]

@Byron - precisely.

Comment 5

[Frédéric Buclin]

Nice catch! :)

Comment 6

[:glob ✱]

Attachment: Patch for 4.4, 5.0 and master

Comment 7

[Netanel Rubin]

Thank you very much Frédéric :)
Any estimate about when you will release a patch?

Comment 8

[Frédéric Buclin]

(In reply to Netanel Rubin, from comment #7)
> Any estimate about when you will release a patch?

Very soon, I hope. But please do not disclose this vulnerability before new releases are publicly available from our website.

Comment 9

[Netanel Rubin]

(In reply to Frédéric Buclin from comment #8)
> (In reply to Netanel Rubin, from comment #7)
> But please do not disclose this vulnerability before newreleases are publicly available from our website.

Of course, just let us know a couple of days prior to your release so we can get prepared.

Comment 10

[Frédéric Buclin]

Comment on attachment 8657874 [details] [diff] [review]
Patch for 4.4, 5.0 and master

r=LpSolit

A backport is needed for 4.2.

Comment 11

[:glob ✱]

Attachment: patch for 4.2

Comment 12

[Frédéric Buclin]

Comment on attachment 8657881 [details] [diff] [review]
patch for 4.2

>+        && length($addr) < 255)

For consistency with the patch for 4.4+, please use <= 255 instead of < 255. r=LpSolit with this fix.


Note that here, we check the length of $addr while in the patch for 4.4+, we check the length of $email (i.e. $addr + emailsuffix). So 4.2 could potentially allow longer email addresses, but the string is not truncated by MySQL anyway, so this is fine. Said differently, in the patch for 4.4+, we could check the length of $addr instead of the length of $email. I'm fine with both approaches.

Comment 13

[Frédéric Buclin]

Oops, your fix doesn't cover all cases. While testing your patch, I wondered why I got a trick_taint() error, and the reason is that the tokens.eventdata DB column is also of type TINYTEXT. So if the combination of old_address:new_address is longer than 255, then the string is truncated again and you can again abuse checks.

STR:

- your initial email address is a valid [e-mail] (15 characters long).
- you go to userprefs.cgi and change your email address to [e-mail] where xxx...xxx is 255 - 28 characters long.
- the concatenated string stored in tokens.eventdata should be [e-mail]:[e-mail], but this string is too long and is truncated to [e-mail]:[e-mail].
- when the user gets the confirmation email and confirms the change, the token will point to the truncated string and you now have a @mozilla.com email address, getting all the privileges associated to such accounts.

So to not be abused, the email address should not be longer than 127 characters, so that 127+1+127=255, 1 being for the ":" character used to concatenate the old and new addresses. The only problem is that if there are already email addresses longer than 127 characters, they could use this trick to abuse Bugzilla. One way to fix it is to increase the size of the tokens.eventdata DB column to 512 characters, but this would be a DB schema change. Not good for branches.

Comment 14

[Frédéric Buclin]

Comment on attachment 8657874 [details] [diff] [review]
Patch for 4.4, 5.0 and master

r- per my previous comment.

Comment 15

[Frédéric Buclin]

Comment on attachment 8657881 [details] [diff] [review]
patch for 4.2

r- per my previous comment.

Comment 16

[Dave Miller [:justdave]]

forcing addresses to 127 or fewer in order to accommodate the size of the token table is probably a good idea.  Just for safety (and another security measure) we could also read the email address back out of the database after writing it to make sure us and the database have the same concept of reality before sending the validation mails.  That would cause the validation mail to go to the spoofed address, correctly blocking it.  Telling MySQL to error instead of truncating would probably be good long-term but I'd be hesitant to do that on a branch.  We probably want to do that on trunk.

Comment 17

[Frédéric Buclin]

(In reply to Dave Miller from comment #16)
> Telling MySQL to error
> instead of truncating would probably be good long-term but I'd be hesitant
> to do that on a branch.  We probably want to do that on trunk.

This is certainly not doable for branches without heavy DB changes. For trunk, I filed bug 1202509.

Comment 18

[:glob ✱]

Attachment: patch for 4.4, 5.0 and master

Comment 19

[:glob ✱]

Attachment: patch for 4.2

Comment 20

[Frédéric Buclin]

Comment on attachment 8658072 [details] [diff] [review]
patch for 4.4, 5.0 and master

r=LpSolit

Comment 21

[Frédéric Buclin]

Comment on attachment 8658073 [details] [diff] [review]
patch for 4.2

r=LpSolit

Comment 22

[Frédéric Buclin]

Bugzilla maintainers: you have been CC'ed to this bug to get early access to a critical security vulnerability which affects all supported Bugzilla versions. Patches are available for Bugzilla 5.0.1, 4.4.10 and 4.2.15, see the attachments table above.

We ask you to not disclose this vulnerability in any way before new releases are available from https://www.bugzilla.org/. This means for instance that you shouldn't use git/bzr/cvs to commit this patch to your local installation if untrusted users may read the commit message and guess what's going on. In this case, applying the patch manually should be prefered.

The ETA for releases is not set yet. We will let you know once we have this information.

Comment 23

[Frédéric Buclin]

GCC Bugzilla patched.

Comment 24

[Daniel Veditz [:dveditz]]

CVE-2015-4499 is assigned to this issue.

Comment 25

[Netanel Rubin]

(In reply to Daniel Veditz [:dveditz] from comment #24)
> CVE-2015-4499 is assigned to this issue.

Thanks. Do you have any updates on the patch ETA?

Comment 26

[austinenglish]

WineHQ Bugzilla is patched.

Comment 27

[Matt Tyson]

Red Hat Bugzilla has been patched, thanks for the heads up.

Comment 28

[Denis Roy]

Just to be clear, if we're using LDAP and have disabled Bugzilla account creation, we're not affected, right?

Comment 29

[Frédéric Buclin]

(In reply to Denis Roy from comment #28)
> Just to be clear, if we're using LDAP and have disabled Bugzilla account
> creation, we're not affected, right?

Shouldn't be affected, right.

Comment 30

[Robin H. Johnson [:robbat2]]

FYI, meant to say before, Gentoo bugzilla is patched, but patch is explicitly NOT committed to our Bugzilla tracking git pending the official release.

Comment 31

[David D. Kilzer (ddk)]

bugs.webkit.org has been patched locally on the server without committing the fix to the svn.webkit.org repository.

Comment 32

[Dave Miller [:justdave]]

OK, The plan at this point is that we're going to release today.  This is a volunteer-driven process, and dependent on working in time around day jobs, and the process can take 2 to 3 hours to complete once it's set in motion, if everything goes smoothly and people don't get called away.  I hate to put uncertainty on the exact time like that, but it'd be appreciated if posting about this elsewhere could be held off at least until the information about it is live on the website (which usually gets posted after the files are available for download).

dkl plans to commit this as part of the release process.

Comment 33

[Netanel Rubin]

We would have appreciated a few days heads up, but do you have an estimate of the exact time the patch will be released?

Comment 34

[Dave Miller [:justdave]]

(In reply to Netanel Rubin, from comment #33)
> We would have appreciated a few days heads up, but do you have an estimate
> of the exact time the patch will be released?

No, I just said that. :-)  It depends on how long it takes to finish the release process.  I do apologize for short notice, but the opportunity arose to get time to do the release and we had to take it (or chance it not happening later)

Comment 35

[Netanel Rubin]

(In reply to Dave Miller [:justdave] ([e-mail]) from comment #34)
> (In reply to Netanel Rubin, from comment #33)
> > We would have appreciated a few days heads up, but do you have an estimate
> > of the exact time the patch will be released?
> 
> No, I just said that. :-)  It depends on how long it takes to finish the
> release process.  I do apologize for short notice, but the opportunity arose
> to get time to do the release and we had to take it (or chance it not
> happening later)

I understand. Please keep us updated.

Comment 36

[Dave Miller [:justdave]]

It may end up taking longer than expected to get it out the door anyway, the upload process for ftp.mozilla.org has changed since our last release and we're having issues getting it to work, so it's dependent on getting that straightened out as well.

Comment 37

[David Lawrence [:dkl]]

To ssh://[e-mail]/bugzilla/bugzilla.git
   7e3042e..10b1fef  4.2 -> 4.2

To ssh://[e-mail]/bugzilla/bugzilla.git
   2fdebb9..be1be8c  4.4 -> 4.4

To ssh://[e-mail]/bugzilla/bugzilla.git
   eff343a..69386c5  5.0 -> 5.0

To ssh://[e-mail]/bugzilla/bugzilla.git
   e32682d..9d64d15  master -> master

(In reply to Dave Miller [:justdave] ([e-mail]) from comment #36)
> It may end up taking longer than expected to get it out the door anyway, the
> upload process for ftp.mozilla.org has changed since our last release and
> we're having issues getting it to work, so it's dependent on getting that
> straightened out as well.

The tar files should be available for download and website updated in a couple hours or less.

dkl

Comment 38

[Netanel Rubin]

Just wanted to make sure - the CVE you assigned for this vuln has already been reserved June 10th (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-4499), it is the correct CVE?

Comment 39

[Frédéric Buclin]

(In reply to Netanel Rubin, from comment #38)
> (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-4499), it is the
> correct CVE?

That page says: "The entry creation date may reflect when the CVE-ID was allocated or reserved, and does not necessarily indicate when this vulnerability was discovered".

Comment 40

[austinenglish]

(In reply to Frédéric Buclin from comment #39)
> (In reply to Netanel Rubin, from comment #38)
> > (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-4499), it is the
> > correct CVE?
> 
> That page says: "The entry creation date may reflect when the CVE-ID was
> allocated or reserved, and does not necessarily indicate when this
> vulnerability was discovered".

FWIW, there aren't any other recent CVE's published for bugzilla, at least:
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=bugzilla

Comment 41

[Frédéric Buclin]

Tests for too long login names added to test_create_user_accounts.t and webservice_user_create.t.

Comment 42

[Daniel Veditz [:dveditz]]

(In reply to Netanel Rubin, from comment #38)
> Just wanted to make sure - the CVE you assigned for this vuln has already
> been reserved June 10th [...], it is the correct CVE?

MITRE assigns CVE numbers in blocks to CNAs, of which Mozilla is one. We then assign numbers from these blocks as issues come up.

Comment 43

[Netanel Rubin]

(In reply to Daniel Veditz [:dveditz] from comment #42)
> (In reply to Netanel Rubin, from comment #38)
> > Just wanted to make sure - the CVE you assigned for this vuln has already
> > been reserved June 10th [...], it is the correct CVE?
> 
> MITRE assigns CVE numbers in blocks to CNAs, of which Mozilla is one. We
> then assign numbers from these blocks as issues come up.

Got it. Thanks!