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

Status: RESOLVED FIXED

(Bugzilla :: Installation & Upgrading, defect)

Description

[Frédéric Buclin]

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.

Comment 1

[Frédéric Buclin]

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).

Comment 3

[Reed Loden [:reed]]

Attachment: patch - v1 (tip)

Patch from bug 534798.

Comment 4

[Max Kanat-Alexander]

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.

Comment 5

[Max Kanat-Alexander]

Also, what security implications does this have? Has there ever been a parameter moved into that file that would contain confidential information?

Comment 6

[Frédéric Buclin]

(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.

Comment 7

[Reed Loden [:reed]]

(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.

Comment 8

[Reed Loden [:reed]]

Attachment: patch - v2 (tip)

Oops, I wrote this two weeks ago and forgot to attach it. :/

Comment 9

[Max Kanat-Alexander]

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".

Comment 10

[Max Kanat-Alexander]

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.

Comment 11

[Reed Loden [:reed]]

Attachment: patch - v3 (tip)

Comment 12

[Reed Loden [:reed]]

Attachment: patch - v3 (tip)

er, the real v3.

Comment 13

[Reed Loden [:reed]]

(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.

Comment 14

[Reed Loden [:reed]]

Attachment: patch - v1 (3.4 branch)

Minor fuzz and one failed hunk from tip to 3.4, but same patch basically.

Comment 15

[Max Kanat-Alexander]

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

Looks good. :-)

Comment 16

[Reed Loden [:reed]]

This will be classified under CVE-2009-3989.

Comment 17

[Frédéric Buclin]

Let's have it in our radar.

Comment 18

[Frédéric Buclin]

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

Comment 19

[Max Kanat-Alexander]

Security advisory sent, removing from security group.