[SECURITY] .htaccess doesn't prevent reading old-params.txt from the web

RESOLVED FIXED in Bugzilla 3.4

Status

()

Bugzilla
Installation & Upgrading
RESOLVED FIXED
9 years ago
7 years ago

People

(Reporter: Frédéric Buclin, Assigned: reed)

Tracking

3.1.4
Bugzilla 3.4
Bug Flags:
approval +
blocking3.6 +
approval3.4 +
blocking3.4.5 +

Details

Attachments

(2 attachments, 3 obsolete attachments)

(Reporter)

Description

9 years ago
When a parameter becomes obsolete, checksetup.pl automatically moves it into old-params.txt. If you have an old enough installation, or if you have customized your installation with your own parameters and some of these parameters are no longer in use, they will become publicly accessible from the web as .htaccess doesn't protect old-params.txt. This may be a problem if some parameters contain sensitive data (such as passwords), e.g. smtp_password and smtp_username (assuming they become obsolete one day).

.htaccess needs to be updated to protect old-params.txt.

Updated

9 years ago
Target Milestone: --- → Bugzilla 3.2
(Reporter)

Comment 1

8 years ago
Bugzilla 3.2 is restricted to security bugs only. Moreover, this bug is either assigned to nobody or got no traction for several months now. Rather than retargetting it at each new release, I'm clearing the target milestone and the bug will be retargetted to some sensible release when someone starts fixing this bug for real (Bugzilla 3.8 more likely).
Target Milestone: Bugzilla 3.2 → ---
(Assignee)

Updated

8 years ago
Group: bugzilla-security
Severity: normal → major
Target Milestone: --- → Bugzilla 3.0
(Assignee)

Updated

8 years ago
Duplicate of this bug: 534798
(Assignee)

Comment 3

8 years ago
Created attachment 417617 [details] [diff] [review]
patch - v1 (tip)

Patch from bug 534798.
Assignee: installation → reed
Status: NEW → ASSIGNED
Attachment #417617 - Flags: review?(mkanat)
(Assignee)

Updated

8 years ago
Summary: .htaccess doesn't prevent to read old-params.txt from the web → [SECURITY] .htaccess doesn't prevent to read old-params.txt from the web
(Assignee)

Updated

8 years ago
Summary: [SECURITY] .htaccess doesn't prevent to read old-params.txt from the web → [SECURITY] .htaccess doesn't prevent reading old-params.txt from the web
(Reporter)

Updated

8 years ago
Severity: major → normal

Comment 4

8 years ago
Comment on attachment 417617 [details] [diff] [review]
patch - v1 (tip)

I just checked in _rename_file, so you can use that instead, and it should probably be in Bugzilla/Install/FileSystem if possible. Look at how we do it for data/mailer.testfile on 3.4 tip and trunk.
Attachment #417617 - Flags: review?(mkanat) → review-

Comment 5

8 years ago
Also, what security implications does this have? Has there ever been a parameter moved into that file that would contain confidential information?
(Reporter)

Comment 6

8 years ago
(In reply to comment #5)
> Also, what security implications does this have? Has there ever been a
> parameter moved into that file that would contain confidential information?

Not yet, which is why I didn't restrict the bug to the security group when I reported it last year. IMO, it's rather a "good to fix" bug than a real security one.
(Assignee)

Comment 7

8 years ago
(In reply to comment #6)
> (In reply to comment #5)
> > Also, what security implications does this have? Has there ever been a
> > parameter moved into that file that would contain confidential information?
> 
> Not yet, which is why I didn't restrict the bug to the security group when I
> reported it last year. IMO, it's rather a "good to fix" bug than a real
> security one.

Bug 314871 is considered a security issue, and it's even more trivial than this bug, so I definitely think this should be considered a security issue.
(Assignee)

Comment 8

8 years ago
Created attachment 419624 [details] [diff] [review]
patch - v2 (tip)

Oops, I wrote this two weeks ago and forgot to attach it. :/
Attachment #417617 - Attachment is obsolete: true
Attachment #419624 - Flags: review?(mkanat)

Comment 9

8 years ago
Comment on attachment 419624 [details] [diff] [review]
patch - v2 (tip)

  Looks fine. :-)

>Index: Bugzilla/Config.pm
>+    my $datadir = bz_locations()->{'datadir'};
>+    my $old_param_file = "$datadir/old-params.txt";
>     if (scalar(keys %oldparams)) {
>-        my $op_file = new IO::File('old-params.txt', '>>', 0600)
>-          || die "old-params.txt: $!";
>+        my $op_file = new IO::File($old_param_file, '>>', 0600)
>+          || die "Couldn't create old-params.txt file: $!";

  Error should contain $old_param_file instead of "old-params.txt".
Attachment #419624 - Flags: review?(mkanat) → review+

Comment 10

8 years ago
I'm really of the opinion that this is not a security bug. Is there any research that shows that this could possibly actually expose something security-related from Bugzilla's history of parameters? As far as bug 314871, there is a possible security issue with it, as listed in the comments of that bug.
Flags: approval?
Flags: approval3.4?
Target Milestone: Bugzilla 3.0 → Bugzilla 3.4
(Reporter)

Updated

8 years ago
Blocks: 532517
(Assignee)

Comment 11

8 years ago
Created attachment 419686 [details] [diff] [review]
patch - v3 (tip)
Attachment #419624 - Attachment is obsolete: true
Attachment #419686 - Flags: review+
(Assignee)

Comment 12

8 years ago
Created attachment 419687 [details] [diff] [review]
patch - v3 (tip)

er, the real v3.
Attachment #419686 - Attachment is obsolete: true
Attachment #419687 - Flags: review+
(Assignee)

Updated

8 years ago
Attachment #419686 - Flags: review+
(Assignee)

Comment 13

8 years ago
(In reply to comment #10)
> I'm really of the opinion that this is not a security bug. Is there any
> research that shows that this could possibly actually expose something
> security-related from Bugzilla's history of parameters?

Several of the parameters removed over the years have been free-form text fields. There's no way for us to know if such fields contain private/confidential information, and if they do, such information would be leaked via old-params.txt even if the Bugzilla instance itself is locked down in other ways. So, yes, this is an information leak security bug.
(Assignee)

Comment 14

8 years ago
Created attachment 419695 [details] [diff] [review]
patch - v1 (3.4 branch)

Minor fuzz and one failed hunk from tip to 3.4, but same patch basically.
Attachment #419695 - Flags: review?(mkanat)

Comment 15

8 years ago
Comment on attachment 419695 [details] [diff] [review]
patch - v1 (3.4 branch)

Looks good. :-)
Attachment #419695 - Flags: review?(mkanat) → review+
(Assignee)

Comment 16

7 years ago
This will be classified under CVE-2009-3989.
(Reporter)

Comment 17

7 years ago
Let's have it in our radar.
Flags: blocking3.6+
Flags: blocking3.4.5+
(Reporter)

Updated

7 years ago
Flags: approval?
Flags: approval3.4?
Flags: approval3.4+
Flags: approval+
(Reporter)

Comment 18

7 years ago
tip:

Checking in Bugzilla/Config.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Config.pm,v  <--  Config.pm
new revision: 1.83; previous revision: 1.82
done
Checking in Bugzilla/Install/Filesystem.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Install/Filesystem.pm,v  <--  Filesystem.pm
new revision: 1.47; previous revision: 1.46
done


3.4.4:

Checking in Bugzilla/Config.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Config.pm,v  <--  Config.pm
new revision: 1.76.2.1; previous revision: 1.76
done
Checking in Bugzilla/Install/Filesystem.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Install/Filesystem.pm,v  <--  Filesystem.pm
new revision: 1.34.2.4; previous revision: 1.34.2.3
done
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED

Comment 19

7 years ago
Security advisory sent, removing from security group.
Group: bugzilla-security
You need to log in before you can comment on or make changes to this bug.