bugzilla's shadow dir allows viewing of bugs without permission

VERIFIED FIXED in Bugzilla 2.12

Status

()

--
critical
VERIFIED FIXED
18 years ago
6 years ago

People

(Reporter: uamjet602, Assigned: barnboy)

Tracking

unspecified
Bugzilla 2.12

Details

(Whiteboard: security)

(Reporter)

Description

18 years ago
Look at bug 34674. Using a normal bugzilla account (or no account) you will get
'you do not have permission to view this bug'.

Now look at http://bugzilla.mozilla.org/shadow/34674

Actual result: shows bug
Expected result: Permission denied

The shadow directory should contain an .htaccess file disallowing viewing
anything from this directory. The documentation and the checksetup script do not
mention this.
Yowsers!  Ping endico, dmose.

Comment 2

18 years ago
Oops, there are hidden bugs? Why is there a need for something like this anyways?
I thought this would be an open source project?
Security bugs mainly.  There were Netscape-confidential bugs but they're being
added to Bugscape now.

But that's irrelevant.  This is about Bugzilla, not Mozilla.

Comment 4

18 years ago
just added a .htaccess file to bugzilla.mozilla.org to keep people out of the
shadow directory on bugzilla.mozilla.org.

leaving the bug open so the problem can be dealt with in the main codebase.
Definite 2.12 configuration fix or at least documentation.
Whiteboard: 2.12
(Reporter)

Comment 6

18 years ago
endico, would you mind telling what .htaccess file you used?

I'm no expert in using them, they never do what I intend :)
I recall Tara mentioning in IRC earlier that she was going to reassign this to 
Matt for documation review.  Guess she didn't get a round tuit.
Assignee: tara → barnboy

Updated

18 years ago
Blocks: 66091
Am I correct in thinking that the shadow directory is only used by oldemailtech?  
So when we nuke the code for oldemailtech, this problem will go away....

Comment 9

18 years ago
Dave: correct; killing oldemailtech will kill this bug too.

Comment 10

18 years ago
Does killing oldemailtech actually wipe the shadow directory, or does it just 
cause the shadow directory to not get updated any more?
Shadow directory would no longer get updated.  I assume at the point we kill it 
that checksetup.pl would start deleting it if it existed.
What needs to be done here for 2.12? Documenting the need for a .htaccess?

Dawn - any chance of posting the one you used?

Gerv

Comment 13

18 years ago
I can't say for sure what Dawn used, but the simplest form of .htaccess to solve
this appears to be:
------------- begin .htaccess ------------------------------------------
deny from all
-------------- end .htaccess -------------------------------------------

Comment 14

18 years ago
documenting the need for .htaccess would be the easiest fix. Adding something
to checksetup.pl to create the file automatically would be better wouldn't it?

I have .htaccess files in bugzilla/data and bugzilla/shadow

As Jake mentioned, they just contain "deny from all".
They don't include Dawn's data .htaccess.  They seem to be responsible for
breaking quip lists and bug charts.  =)
(Reporter)

Comment 16

18 years ago
If you allow the machine that creates dependency graphs (typically:
www.research.att.com) they will probably work.

Perhaps the data needs to be split (one dir for (potentially) confidential
things like bug description, one dir for public things like the quip list).

Comment 17

18 years ago
... or perhaps the quip list should be moved to the database finally (bug 67950).
... or provide access through cgis.

But I think the point is that we need to decide what to do for 2.12, which is
due RSN.
ok, in data/, you need this:

----- begin .htaccess -----
<Files comments>
  allow from all
</Files>
deny from all
----- end .htaccess -----

That will get the quip list working again.

Comment 20

18 years ago
hihi

if ( FireWall ) {
  We Need Master Genius 
}
else if ( Software_IP_filter ) {
  We Need still need Master Genius
} else { 
  Your Dead Meat For Sure -:))
}

Updated

18 years ago
Whiteboard: 2.12 → 2.12, security

Updated

18 years ago
Summary: bugzilla allows viewing of bugs without permission → bugzilla's shadow dir allows viewing of bugs without permission
moving to real milestones...
Whiteboard: 2.12, security → security
Target Milestone: --- → Bugzilla 2.12
So, to fix this bug, we check the above .htaccess into the data directory?

Gerv
The above .htaccess will probably break charting.
I thought charting uses the "graphs" directory now, instead of "data" for this 
reason...
I'm only going on b.m.o.  If this has changed since 2.10, ignore my above
comments.
(Assignee)

Comment 26

18 years ago
I have put the relevant information into the Bugzilla Guide now, instructing
to disallow access to $BUGZILLA_HOME/localconfig and $BUGZILLA_HOME/data/ except
for data/comments.  I should be checking the change in tonight or tomorrow
morning.  I mention that the .htaccess files are *not* effective for anything
other than Apache or NCSA; I am unsure of if iPlanet honors .htaccess controls.

I have placed the following .htaccess files in these locations in my local cvs
repository (I would appreciate your buyoff in a comment before I check them in,
I plan on checking in late tonight or early tomorrow morning)

$BUGZILLA_HOME/data/
--begin .htaccess
<Files comments>
allow from all
</Files>
deny from all
--end .htaccess

$BUGZILLA_HOME/shadow/
--begin .htaccess
deny from all
--end .htaccess

$BUGZILLA_HOME/
<Files localconfig>
deny from all
</Files>
allow from all

I am marking these bugs as *resolved fixed* since the fix remains simply to
check into CVS.  If you disagree with this assessment, feel free to reopen the
bug : )
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
(Assignee)

Comment 28

18 years ago
Allow me to caveat: *I* will be checking this in tonight : )
V.  This is documented adequately in the README and Bugzilla Guide.
Status: RESOLVED → VERIFIED
Moving closed bugs to Bugzilla product
Component: Bugzilla → Bugzilla-General
Product: Webtools → Bugzilla
Version: other → unspecified
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.