1074812 - (CVE-2014-1572) [SECURITY] The 'realname' parameter is not correctly filtered on user account creation, leading to user data override

Status: RESOLVED FIXED

(Bugzilla :: User Accounts, defect)

Description

[Netanel Rubin]

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:
- [e-mail]
- [e-mail]
- [e-mail]
- [e-mail]
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 [e-mail] and [e-mail] (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

[David Lawrence [:dkl]]

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

[Netanel Rubin]

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 [e-mail] to the list of viewers who can view this bug?

Comment 3

[David Lawrence [:dkl]]

(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 [e-mail], [e-mail] 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 [e-mail] to the list of viewers
> who can view this bug?

done

dkl

Comment 4

[Netanel Rubin]

I'm attaching the technical description to this bug. I hope it will make things clear :)

Comment 5

[Netanel Rubin]

Attachment: Bugzilla.pdf

Comment 6

[Shahar Tal]

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

[Mark Côté [:mcote]]

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

[Frédéric Buclin]

Confirmed! And your fix is indeed correct. Thanks for catching that!

Comment 9

[Frédéric Buclin]

Attachment: patch, v1

Comment 10

[Frédéric Buclin]

All versions newer and including 2.23.3 are affected, see bug 349349.

Comment 13

[David Lawrence [:dkl]]

Comment on attachment 8497591 [details] [diff] [review]
patch, v1

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

Verified fixed. r=dkl

Comment 14

[Daniel Veditz [:dveditz]]

Assigning CVE-2014-1572 to this bug.

Comment 15

[Frédéric Buclin]

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

[Kevin J. Woolley]

Thanks for the notification -- we're patched. Much appreciated!

Comment 17

[Frédéric Buclin]

GCC Bugzilla patched too.

Comment 18

[Daniel Stone]

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

[Robin H. Johnson [:robbat2]]

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

[Frédéric Buclin]

(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

[Damien Miller]

OpenSSH bugzilla updated. Thanks for the warning!

Comment 22

[Paul Querna]

Apache OpenOffice and main Apache.org patched. Thanks.

Comment 23

[Matt Tyson]

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

Comment 24

[Andre Klapper]

Wikimedia Bugzilla patched, thank you!

Comment 25

[Gervase Markham [:gerv]]

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

[Shahar Tal]

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

Shahar

Comment 27

[Frédéric Buclin]

(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

[Florian Weimer]

(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

[Frédéric Buclin]

(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

[Daniel Veditz [:dveditz]]

Moving the CVE to the more complete fix for this anti-pattern in bug 1075578

Comment 31

[Frédéric Buclin]

This patch is included in bug 1075578.

Comment 32

[David Lawrence [:dkl]]

(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

[David Lawrence [:dkl]]

Fix checked in in bug 1075578. Closing.

Comment 34

[Frédéric Buclin]

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

[Daniel Veditz [:dveditz]]

Restoring the original CVE to this bug since some installations have applied partial patches.

Comment 36

[Jeff Bryner [:jeff] (use NEEDINFO 😉)]

FYI: Here's all the accounts created: 
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]

Comment 37

[Shahar Tal]

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