308256 - [SECURITY] config.cgi doesn't check Param('requirelogin')

Status: RESOLVED FIXED

(Bugzilla :: Bugzilla-General, defect)

Description

[Frédéric Buclin]

Private installations use the 'requirelogin' parameter to prevent logged out
users to access their DB (with the addition of preventing users to create new
user accounts themselves or by limiting who can create new accounts), but
config.cgi doesn't check whether this param is turned on, allowing anyone to
access confidential information. If administrators think they are protected
thanks to this parameter, it is possible that some or all of their products are
not restricted to groups, making them publicly visible.

Comment 1

[Dave Miller [:justdave]]

"confidential information" in this case is not any bug content, but names of
products, components, keywords, milestones, versions, etc.

If the admin is limiting account creation and using requirelogin as the only
means of preventing access (which is perfectly logical to do), it's quite
logical to assume that there may be confidential product names that would be
otherwise publicly visible were it not for requirelogin being set.

Comment 2

[Frédéric Buclin]

Attachment: patch, v1

This patch applies on all branches >= 2.18 + tip.

Comment 3

[Myk Melez [:myk] [@mykmelez]]

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

After applying the patch, Bugzilla prompts me to log in when I access
config.cgi in my web browser if I am not already logged in and requirelogin is
set.  But config.cgi is intended for use by other applications, not end-users,
and it outputs data in only JavaScript or RDF, so it needs to output something
here that makes sense for applications which expect data in those formats.

At a minimum, that would be an empty (but valid) JS or RDF file.  Ideally, it
is some method of identifying to the application that a login is required (but
perhaps this should wait for a web services interface).

Comment 4

[Frédéric Buclin]

Attachment: patch for 2.20, v2

I now use Bugzilla->login(LOGIN_OPTIONAL) to avoid the login screen, but we
return empty fields if the user is not logged in already.

Comment 5

[Max Kanat-Alexander]

Comment on attachment 195960 [details] [diff] [review]
patch for 2.20, v2

Looks good, works correctly on landfill. I thought it might produce some
warnings or something, but nope, it's all clean. :-)

Comment 6

[Frédéric Buclin]

Attachment: patch for the tip, v2

Comment 7

[Max Kanat-Alexander]

Comment on attachment 197332 [details] [diff] [review]
patch for the tip, v2

This looks good and works properly.

By the way, I'm slightly concerned that we expose "maintainer" to people who
aren't logged in, but that's not as much of an issue as the primary one in this
bug, yes?

Comment 8

[Joel Peshkin]

Actually, I think that exposing maintainer by default is a good idea.  We might
want to have a way to disable that, though.  If we decide to do that, the param
controlling it should discourage admins from doing it.

Comment 9

[Frédéric Buclin]

Attachment: patch for 2.18.4

Comment 10

[Max Kanat-Alexander]

Comment on attachment 197340 [details] [diff] [review]
patch for 2.18.4

Looks good to me! :-) And works on landfill.

Comment 11

[Frédéric Buclin]

tip:

Checking in config.cgi;
/cvsroot/mozilla/webtools/bugzilla/config.cgi,v  <--  config.cgi
new revision: 1.12; previous revision: 1.11
done

2.20:

Checking in config.cgi;
/cvsroot/mozilla/webtools/bugzilla/config.cgi,v  <--  config.cgi
new revision: 1.8.4.1; previous revision: 1.8
done

2.18.4:

Checking in config.cgi;
/cvsroot/mozilla/webtools/bugzilla/config.cgi,v  <--  config.cgi
new revision: 1.5.2.1; previous revision: 1.5
done

Comment 12

[Max Kanat-Alexander]

Attachment: Remove "use diagnostics" from config.cgi to fix regression

Checking-in this bug caused Bugzilla to stop working with perl 5.6.1. For some
reason, removing "use diagnostics" from config.cgi fixes this. Discussed it on
IRC, got r+ and a+ there for the fix.

For some reason, 2.18 is not affected. It's probably some weird perl 5.6.1 bug.


tip:

Checking in config.cgi;
/cvsroot/mozilla/webtools/bugzilla/config.cgi,v  <--  config.cgi
new revision: 1.13; previous revision: 1.12
done

2.20:

Checking in config.cgi;
/cvsroot/mozilla/webtools/bugzilla/config.cgi,v  <--  config.cgi
new revision: 1.8.4.2; previous revision: 1.8.4.1
done

Comment 13

[Max Kanat-Alexander]

OK, security advisory sent, removing this bug from the sec group.

Comment 14

[Frédéric Buclin]

(In reply to comment #12)
> Remove "use diagnostics" from config.cgi to fix regression

Strange, 'use diagnostics' was already in the file.

Comment 15

[Max Kanat-Alexander]

(In reply to comment #14)
> Strange, 'use diagnostics' was already in the file.

  I know. As I said, it was an extremely strange bug. The error output looked
like an endless loop inside of the "use" statement. I was probably some strange
conflict in perl 5.6.1 between one of our modules and the diagnostics.pm module,
I'd guess.

Comment 16

[Juha-Matti Laurio]

This was assigned to very new http://www.securityfocus.com/bid/14995 entitled as
"Bugzilla config.cgi Information Disclosure Vulnerability" now.