Closed Bug 1202447 (CVE-2015-4499) Opened 5 years ago Closed 5 years ago

[SECURITY] The email address is not properly validated during registration if longer than 127 characters

Categories

(Bugzilla :: User Accounts, defect, critical)

defect
Not set
critical

Tracking

()

RESOLVED FIXED
Bugzilla 4.2

People

(Reporter: nati, Assigned: glob)

References

Details

(Keywords: sec-high, Whiteboard: [newcomers: read comment 22])

Attachments

(3 files, 2 obsolete files)

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:
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb@mozilla.com
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.
Please paste the details here.
Assignee: user-accounts → glob
@Byron - precisely.
Flags: sec-bounty?
Nice catch! :)
Severity: normal → critical
Flags: blocking5.0.1?
Flags: blocking4.4.10?
Flags: blocking4.2.15?
Summary: The email address is not properly validated during registration → [SECURITY] The email address is not properly validated during registration if longer than 255 characters
Target Milestone: --- → Bugzilla 4.2
Attached patch Patch for 4.4, 5.0 and master (obsolete) — Splinter Review
Attachment #8657874 - Flags: review?(LpSolit)
Thank you very much Frédéric :)
Any estimate about when you will release a patch?
(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.
Status: NEW → ASSIGNED
(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 on attachment 8657874 [details] [diff] [review]
Patch for 4.4, 5.0 and master

r=LpSolit

A backport is needed for 4.2.
Attachment #8657874 - Attachment description: 1202447_1.patch → Patch for 4.4, 5.0 and master
Attachment #8657874 - Flags: review?(LpSolit) → review+
Attached patch patch for 4.2 (obsolete) — Splinter Review
Attachment #8657881 - Flags: review?(LpSolit)
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.
Attachment #8657881 - Flags: review?(LpSolit) → review+
Flags: testcase?
Flags: approval?
Flags: approval5.0?
Flags: approval4.4?
Flags: approval4.2?
Flags: blocking5.0.1?
Flags: blocking5.0.1+
Flags: blocking4.4.10?
Flags: blocking4.4.10+
Flags: blocking4.2.15?
Flags: blocking4.2.15+
Blocks: 1202467
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 foo@company.com (15 characters long).
- you go to userprefs.cgi and change your email address to xxx...xxx@mozilla.com.company.com where xxx...xxx is 255 - 28 characters long.
- the concatenated string stored in tokens.eventdata should be foo@company.com:xxx...xxx@mozilla.com.company.com, but this string is too long and is truncated to foo@company.com:xxx...xxx@mozilla.com.
- 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.
Flags: approval?
Flags: approval5.0?
Flags: approval4.4?
Flags: approval4.2?
Comment on attachment 8657874 [details] [diff] [review]
Patch for 4.4, 5.0 and master

r- per my previous comment.
Attachment #8657874 - Flags: review+ → review-
Comment on attachment 8657881 [details] [diff] [review]
patch for 4.2

r- per my previous comment.
Attachment #8657881 - Flags: review+ → review-
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.
(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.
Attachment #8657874 - Attachment is obsolete: true
Attachment #8658072 - Flags: review?(LpSolit)
Attached patch patch for 4.2Splinter Review
Attachment #8657881 - Attachment is obsolete: true
Attachment #8658073 - Flags: review?(LpSolit)
Comment on attachment 8658072 [details] [diff] [review]
patch for 4.4, 5.0 and master

r=LpSolit
Attachment #8658072 - Flags: review?(LpSolit) → review+
Comment on attachment 8658073 [details] [diff] [review]
patch for 4.2

r=LpSolit
Attachment #8658073 - Flags: review?(LpSolit) → review+
Flags: approval?
Flags: approval5.0?
Flags: approval4.4?
Flags: approval4.2?
Summary: [SECURITY] The email address is not properly validated during registration if longer than 255 characters → [SECURITY] The email address is not properly validated during registration if longer than 127 characters
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.
Whiteboard: [newcomers: read comment 22]
Attachment #8658072 - Attachment description: patch for 4.4+ → patch for 4.4, 5.0 and master
GCC Bugzilla patched.
CVE-2015-4499 is assigned to this issue.
Alias: CVE-2015-4499
(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?
WineHQ Bugzilla is patched.
Red Hat Bugzilla has been patched, thanks for the heads up.
Just to be clear, if we're using LDAP and have disabled Bugzilla account creation, we're not affected, right?
(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.
FYI, meant to say before, Gentoo bugzilla is patched, but patch is explicitly NOT committed to our Bugzilla tracking git pending the official release.
bugs.webkit.org has been patched locally on the server without committing the fix to the svn.webkit.org repository.
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.
Flags: approval?
Flags: approval5.0?
Flags: approval5.0+
Flags: approval4.4?
Flags: approval4.4+
Flags: approval4.2?
Flags: approval4.2+
Flags: approval+
We would have appreciated a few days heads up, but do you have an estimate of the exact time the patch will be released?
(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)
(In reply to Dave Miller [:justdave] (justdave@bugzilla.org) 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.
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.
To ssh://gitolite3@git.mozilla.org/bugzilla/bugzilla.git
   7e3042e..10b1fef  4.2 -> 4.2

To ssh://gitolite3@git.mozilla.org/bugzilla/bugzilla.git
   2fdebb9..be1be8c  4.4 -> 4.4

To ssh://gitolite3@git.mozilla.org/bugzilla/bugzilla.git
   eff343a..69386c5  5.0 -> 5.0

To ssh://gitolite3@git.mozilla.org/bugzilla/bugzilla.git
   e32682d..9d64d15  master -> master

(In reply to Dave Miller [:justdave] (justdave@bugzilla.org) 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
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Group: bugzilla-security
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?
(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".
Flags: sec-bounty? → sec-bounty+
Keywords: sec-high
(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
Tests for too long login names added to test_create_user_accounts.t and webservice_user_create.t.
Flags: testcase? → testcase+
(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.
(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!
You need to log in before you can comment on or make changes to this bug.