Closed Bug 1074812 (CVE-2014-1572) Opened 10 years ago Closed 10 years ago

[SECURITY] The 'realname' parameter is not correctly filtered on user account creation, leading to user data override

Categories

(Bugzilla :: User Accounts, defect)

2.23.3
defect
Not set
blocker

Tracking

()

RESOLVED FIXED
Bugzilla 4.0

People

(Reporter: nati, Assigned: LpSolit)

References

Details

(Keywords: regression, sec-high, Whiteboard: [blocker will fix])

Attachments

(1 file)

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.
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
Flags: needinfo?(netanelr)
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?
Flags: needinfo?(netanelr)
(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
I'm attaching the technical description to this bug. I hope it will make things clear :)
Attached file Bugzilla.pdf
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
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.
Flags: sec-bounty?
Confirmed! And your fix is indeed correct. Thanks for catching that!
Assignee: user-accounts → LpSolit
Severity: normal → blocker
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Flags: blocking4.4.6?
Flags: blocking4.2.11?
Flags: blocking4.0.15?
Summary: User creation fields override → The 'realname' parameter is not correctly filtered on user account creation, leading to user data override
Target Milestone: --- → Bugzilla 4.0
Attached patch patch, v1Splinter Review
Attachment #8497591 - Flags: review?(dkl)
All versions newer and including 2.23.3 are affected, see bug 349349.
Depends on: 349349
Keywords: regression
Summary: The 'realname' parameter is not correctly filtered on user account creation, leading to user data override → [SECURITY] The 'realname' parameter is not correctly filtered on user account creation, leading to user data override
Version: unspecified → 2.23.3
Comment on attachment 8497591 [details] [diff] [review]
patch, v1

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

Verified fixed. r=dkl
Attachment #8497591 - Flags: review?(dkl) → review+
Flags: approval?
Flags: approval4.4?
Flags: approval4.2?
Flags: approval4.0?
Blocks: 1072497
Flags: blocking4.4.6?
Flags: blocking4.4.6+
Flags: blocking4.2.11?
Flags: blocking4.2.11+
Flags: blocking4.0.15?
Flags: blocking4.0.15+
Assigning CVE-2014-1572 to this bug.
Alias: CVE-2014-1572
CC'ing (old?) Bugzilla admins as they probably want to apply the patch before this bug becomes public. The patch applies to all branches.
Thanks for the notification -- we're patched. Much appreciated!
GCC Bugzilla patched too.
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.
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.
(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.
OpenSSH bugzilla updated. Thanks for the warning!
Apache OpenOffice and main Apache.org patched. Thanks.
Red Hat Bugzilla has been patched, thanks for the notice.
Wikimedia Bugzilla patched, thank you!
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
For what it's worth, our audit found no other similar vectors in the code.

Shahar
(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.
(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.
(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. :)
Moving the CVE to the more complete fix for this anti-pattern in bug 1075578
Alias: CVE-2014-1572
This patch is included in bug 1075578.
No longer blocks: CVE-2014-1573
Depends on: CVE-2014-1573
Flags: approval?
Flags: approval4.4?
Flags: approval4.2?
Flags: approval4.0?
Whiteboard: [blocker will fix]
Whiteboard: [blocker will fix] → [blocker will fix] EMBARGO until Monday Oct 6, 7am PDT (10am Eastern)
(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
Fix checked in in bug 1075578. Closing.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
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!
Restoring the original CVE to this bug since some installations have applied partial patches.
Alias: CVE-2014-1572
Group: bugzilla-security
Flags: sec-bounty? → sec-bounty+
Keywords: sec-high
Whiteboard: [blocker will fix] EMBARGO until Monday Oct 6, 7am PDT (10am Eastern)
Whiteboard: [blocker will fix]
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
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: