Last Comment Bug 1074812 - (CVE-2014-1572) [SECURITY] The 'realname' parameter is not correctly filtered on user account creation, leading to user data override
(CVE-2014-1572)
: [SECURITY] The 'realname' parameter is not correctly filtered on user account...
Status: RESOLVED FIXED
[blocker will fix]
: regression, sec-high
Product: Bugzilla
Classification: Server Software
Component: User Accounts (show other bugs)
: 2.23.3
: All All
-- blocker (vote)
: Bugzilla 4.0
Assigned To: Frédéric Buclin
: default-qa
:
Mentors:
Depends on: 349349 CVE-2014-1573
Blocks: 1072497
  Show dependency treegraph
 
Reported: 2014-09-30 05:48 PDT by Netanel Rubin
Modified: 2014-10-06 20:44 PDT (History)
39 users (show)
justdave: blocking4.4.6+
justdave: blocking4.2.11+
justdave: blocking4.0.15+
dveditz: sec‑bounty+
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
patch, v1 (406 bytes, patch)
2014-09-30 09:01 PDT, Frédéric Buclin
dkl: review+
Details | Diff | Splinter Review

Description User image Netanel Rubin 2014-09-30 05:48:21 PDT
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.120 Safari/537.36

Steps to reproduce:

Hello,

My name is Netanel Rubin, I work as a vulnerability researcher at Check Point Software Technologies.

This is a critical vulnerability report for an issue I discovered in the Bugzilla platform. The successful exploitation of the vulnerability allows the manipulation of any DB field at the user creation procedure, including the 'login_name' field. This breaks the email validation process, and allows an attacker to create accounts which match the groups regex policies, effectively becoming a privileged user.

As a PoC, I've created test accounts under bugzilla.mozilla.org:
- admin@mozilla.com
- admin@mozilla.org
- admin@bugzilla.org
- admin@bugzilla.bugs
All of them have 'Admin' as a real name. Please remove these accounts as they were only meant to verify the issue.

We would like to report the complete vulnerability description over a private channel. Please contact us at netanelr@checkpoint.com and shahartal@checkpoint.com (my team leader).
Please assign a CVE number for this issue. We would also like to coordinate the public disclosure with you.

Best regards,
Netanel.


Actual results:

I was able to control every DB field in the user creation process, bypassing email verification.
Comment 1 User image David Lawrence [:dkl] 2014-09-30 06:59:55 PDT
Normally we require clicking a token sent via email before an account is actually created. How were you able to receive those particular emails and finish the account activation?

Also when you say that any db field can be manipulated by using crafted values for login_name or realname, can you provide an example of that?

Thanks
dkl
Comment 2 User image Netanel Rubin 2014-09-30 07:13:40 PDT
As for the DB fields, I could have created a user with an extern_id set, for example.

The vulnerability occurs after the email is already validated and is at the stage where the user could set his password and real name. Should I post the technical description here or do you prefer I'll post it elsewhere?

Also, could you please add shahartal@checkpoint.com to the list of viewers who can view this bug?
Comment 3 User image David Lawrence [:dkl] 2014-09-30 07:47:32 PDT
(In reply to Netanel Rubin from comment #2)
> As for the DB fields, I could have created a user with an extern_id set, for
> example.
> 
> The vulnerability occurs after the email is already validated and is at the
> stage where the user could set his password and real name. 

So basically you are saying that admin@mozilla.org, admin@bugzilla.bugs emails were delivered to you and you were able to click the finalize token link to fill in the full name, etc.?

> Should I post the
> technical description here or do you prefer I'll post it elsewhere?

It is preferable that we discuss this issue in this private bug as other Bugzilla developers who can see private security bugs would be interested in joining the discussion.

Also thank you for bringing this to our attention as well.
 
> Also, could you please add shahartal@checkpoint.com to the list of viewers
> who can view this bug?

done

dkl
Comment 4 User image Netanel Rubin 2014-09-30 08:29:19 PDT
I'm attaching the technical description to this bug. I hope it will make things clear :)
Comment 5 User image Netanel Rubin 2014-09-30 08:29:43 PDT
Created attachment 8497570 [details]
Bugzilla.pdf
Comment 6 User image Shahar Tal 2014-09-30 08:46:16 PDT
Hi guys,
Shahar here, I lead the vulnerability research team including our lovely talent Netanel here who just dropped what seems to be a major issue for Bugzilla.
I'd like to get in touch with Mark or whoever is going to be responsible for the public announcement, please drop me a line out of the bug here, I don't want to pollute the technical discussion.
Thx
Comment 7 User image Mark Côté [:mcote] 2014-09-30 08:48:32 PDT
We are currently investigating; when we confirm the bug we'll get Mozilla's security team involved, since it appears to affect BMO, and we'll contact you.
Comment 8 User image Frédéric Buclin 2014-09-30 08:57:02 PDT
Confirmed! And your fix is indeed correct. Thanks for catching that!
Comment 9 User image Frédéric Buclin 2014-09-30 09:01:49 PDT
Created attachment 8497591 [details] [diff] [review]
patch, v1
Comment 10 User image Frédéric Buclin 2014-09-30 09:14:29 PDT
All versions newer and including 2.23.3 are affected, see bug 349349.
Comment 13 User image David Lawrence [:dkl] 2014-09-30 09:40:35 PDT
Comment on attachment 8497591 [details] [diff] [review]
patch, v1

Review of attachment 8497591 [details] [diff] [review]:
-----------------------------------------------------------------

Verified fixed. r=dkl
Comment 14 User image Daniel Veditz [:dveditz] 2014-09-30 11:54:33 PDT
Assigning CVE-2014-1572 to this bug.
Comment 15 User image Frédéric Buclin 2014-09-30 13:56:14 PDT
CC'ing (old?) Bugzilla admins as they probably want to apply the patch before this bug becomes public. The patch applies to all branches.
Comment 16 User image Kevin J. Woolley 2014-09-30 14:31:13 PDT
Thanks for the notification -- we're patched. Much appreciated!
Comment 17 User image Frédéric Buclin 2014-09-30 14:35:48 PDT
GCC Bugzilla patched too.
Comment 18 User image Daniel Stone 2014-09-30 14:49:50 PDT
Thanks (on behalf of all of us, I'm sure) for the early heads-up. As I don't have access to CVE/vuln information, when will this become public? I don't want to alert people by patching the fd.o install before the embargo drops, as I think there are still a few users with access to that machine.
Comment 19 User image Robin H. Johnson [:robbat2] 2014-09-30 16:45:40 PDT
Ditto on Daniel's comment;

When's the embargo target date?

I don't want to accidentally release this to the public, since Gentoo's modified Bugzilla source is visible on public git.
Comment 20 User image Frédéric Buclin 2014-09-30 16:48:18 PDT
(In reply to Robin H. Johnson [:robbat2] from comment #19)
> When's the embargo target date?

Probably tomorrow or near the end of the week. We are tracking other potential issues.
Comment 21 User image Damien Miller 2014-09-30 16:58:10 PDT
OpenSSH bugzilla updated. Thanks for the warning!
Comment 22 User image Paul Querna 2014-09-30 18:36:11 PDT
Apache OpenOffice and main Apache.org patched. Thanks.
Comment 23 User image Matt Tyson 2014-09-30 20:00:15 PDT
Red Hat Bugzilla has been patched, thanks for the notice.
Comment 24 User image Andre Klapper 2014-10-01 00:52:54 PDT
Wikimedia Bugzilla patched, thank you!
Comment 25 User image Gervase Markham [:gerv] 2014-10-01 01:04:37 PDT
Blimey. This Perl "feature" seems like a footgun. Have we audited the rest of the code to see if we're doing this anywhere else?

<greps>
I count 15 other instances of the pattern "=> $cgi->param". None look vulnerable, but I'd prefer to have confirmation from others. (It seems that what you need is a call to $cgi->param as part of assigning to a hash, where the call is after a previous value you want to influence.)

Gerv
Comment 26 User image Shahar Tal 2014-10-01 02:18:11 PDT
For what it's worth, our audit found no other similar vectors in the code.

Shahar
Comment 27 User image Frédéric Buclin 2014-10-01 02:49:22 PDT
(In reply to Gervase Markham [:gerv] from comment #25)
> Have we audited the rest of the code to see if we're doing this anywhere else?

gerv, see bug 1074980.
Comment 28 User image Florian Weimer 2014-10-01 03:17:32 PDT
(In reply to Gervase Markham [:gerv] from comment #25)
> (It seems that
> what you need is a call to $cgi->param as part of assigning to a hash, where
> the call is after a previous value you want to influence.)

It's really about list context vs scalar context, and function arguments are (most of the time) list context.  The “=>” is just alternative syntax for “,”, so it's not a very compelling grep pattern.  Context is determined dynamically at run time in many places, unfortunately.  The best approach might be to ban “$cgi->param” altogether and uses something else which enforces scalar context.
Comment 29 User image Frédéric Buclin 2014-10-01 03:19:33 PDT
(In reply to Florian Weimer from comment #28)
> The best approach
> might be to ban “$cgi->param” altogether and uses something else which
> enforces scalar context.

Already done in bug 1074980. Please keep that discussion there. :)
Comment 30 User image Daniel Veditz [:dveditz] 2014-10-01 09:39:32 PDT
Moving the CVE to the more complete fix for this anti-pattern in bug 1075578
Comment 31 User image Frédéric Buclin 2014-10-01 17:46:13 PDT
This patch is included in bug 1075578.
Comment 32 User image David Lawrence [:dkl] 2014-10-03 07:23:18 PDT
(In reply to Frédéric Buclin from comment #20)
> (In reply to Robin H. Johnson [:robbat2] from comment #19)
> > When's the embargo target date?
> 
> Probably tomorrow or near the end of the week. We are tracking other
> potential issues.

It has been changed to 10AM ET on Monday Oct 6th. Please do not speak publicly about this or other dependent bugs til then.

Thanks
dkl
Comment 33 User image David Lawrence [:dkl] 2014-10-06 08:07:21 PDT
Fix checked in in bug 1075578. Closing.
Comment 34 User image Frédéric Buclin 2014-10-06 09:50:58 PDT
I want to publicly complain about the attitude of the team from Check Point Software Technologies to disclose the vulnerability to media before the new Bugzilla releases were available from the Mozilla FTP website. We made it *very* clear to not disclose the vulnerability to anyone before releases were publicly available, and we can already read articles such as http://krebsonsecurity.com/2014/10/bugzilla-zero-day-exposes-zero-day-bugs/ which is full of inacurracies (such as claiming that you get admin privileges and can read all confidential bugs, which is totally wrong). I suppose the media got these incorrect details from Check Point Vulnerability Research. The article compares this vulnerability to Heartbleed and Shellshock, but we are far several orders of magnitude lower than that. A very disappointing attitude!
Comment 35 User image Daniel Veditz [:dveditz] 2014-10-06 09:54:25 PDT
Restoring the original CVE to this bug since some installations have applied partial patches.
Comment 36 User image Jeff Bryner [:jeff] (use NEEDINFO) 2014-10-06 15:17:29 PDT
FYI: Here's all the accounts created: 
admin@mozilla.com
admin@bugzilla.org
admin@mozilla.org
ukv74546@qoika.com
admin@bmo.bugs
a4055078@trbvm.com
admin@bugzilla.bugs
Comment 37 User image Shahar Tal 2014-10-06 20:44:11 PDT
Hi Frédéric and team,
I apologize if you received a wrong impression of our attitude. Our research group has very clear intentions of responsibly helping to fix every vulnerability we find.
With regards to disclosure timeline, in the above I believe we clearly communicated an embargo lift time. After that was set, patch release timing is out of our control.
As for heartbleed/shellshock comparisons and the exaggerated extrapolation of implications - they are spins naturally made by media to attract more readers, which is to be expected. I do try to correct published pieces with a more accurate version of reality, including correcting my own words. (e.g. my post comment reply to you earlier).
Thanks again for putting in some very good work on this project, we have nothing but respect for the professional response by all maintainers and Mozilla reps in this process.
Please let me know if I can help otherwise.
Shahar

Note You need to log in before you can comment on or make changes to this bug.