Bug 1074812 (CVE-2014-1572)

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

RESOLVED FIXED in Bugzilla 4.0

Status

()

Bugzilla
User Accounts
--
blocker
RESOLVED FIXED
3 years ago
5 months ago

People

(Reporter: Netanel Rubin, Assigned: Frédéric Buclin)

Tracking

({regression, sec-high})

2.23.3
Bugzilla 4.0
regression, sec-high
Dependency tree / graph
Bug Flags:
blocking4.4.6 +
blocking4.2.11 +
blocking4.0.15 +
sec-bounty +

Details

(Whiteboard: [blocker will fix])

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
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)
(Reporter)

Comment 2

3 years ago
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
(Reporter)

Comment 4

3 years ago
I'm attaching the technical description to this bug. I hope it will make things clear :)
(Reporter)

Comment 5

3 years ago
Created attachment 8497570 [details]
Bugzilla.pdf

Comment 6

3 years ago
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

3 years ago
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?
(Assignee)

Comment 8

3 years ago
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
(Assignee)

Comment 9

3 years ago
Created attachment 8497591 [details] [diff] [review]
patch, v1
Attachment #8497591 - Flags: review?(dkl)
(Assignee)

Comment 10

3 years ago
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+

Updated

3 years ago
Flags: approval?
Flags: approval4.4?
Flags: approval4.2?
Flags: approval4.0?

Updated

3 years ago
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
(Assignee)

Comment 15

3 years ago
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

3 years ago
Thanks for the notification -- we're patched. Much appreciated!
(Assignee)

Comment 17

3 years ago
GCC Bugzilla patched too.

Comment 18

3 years ago
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.
(Assignee)

Comment 20

3 years ago
(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

3 years ago
OpenSSH bugzilla updated. Thanks for the warning!

Comment 22

3 years ago
Apache OpenOffice and main Apache.org patched. Thanks.

Comment 23

3 years ago
Red Hat Bugzilla has been patched, thanks for the notice.

Comment 24

3 years ago
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

Comment 26

3 years ago
For what it's worth, our audit found no other similar vectors in the code.

Shahar
(Assignee)

Comment 27

3 years ago
(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

3 years ago
(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.
(Assignee)

Comment 29

3 years ago
(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. :)
(Assignee)

Updated

3 years ago
Blocks: 1075578
Moving the CVE to the more complete fix for this anti-pattern in bug 1075578
Alias: CVE-2014-1572
(Assignee)

Comment 31

3 years ago
This patch is included in bug 1075578.
No longer blocks: 1075578
Depends on: 1075578
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
Last Resolved: 3 years ago
Resolution: --- → FIXED
(Assignee)

Comment 34

3 years ago
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

Updated

3 years ago
Group: bugzilla-security
Flags: sec-bounty? → sec-bounty+
Keywords: sec-high
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
Whiteboard: [blocker will fix] EMBARGO until Monday Oct 6, 7am PDT (10am Eastern)
(Assignee)

Updated

3 years ago
Whiteboard: [blocker will fix]

Comment 37

3 years ago
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.