Page MenuHomePhabricator

CVE-2022-47927: sqlite should not create DB file world-readable
Closed, ResolvedPublicSecurity

Description

Steps to replicate the issue (include links if applicable):

  • Install MediaWiki
  • Select sqlite as the DB type
  • Use a data directory that already exists with lax permissions (If mediawiki creates the directory itself, it will be 700)

What happens?:

DB files are created in mode 644

bawolff@bawolff:/var/www/data$ ls -lah
total 2.4M
drwxr-xr-x 3 www-data www-data 4.0K Nov  8 05:56 .
drwxr-xr-x 4 root     root     4.0K Nov  8 05:41 ..
-rw-r--r-- 1 www-data www-data   14 Nov  8 05:41 .htaccess
drwxr-xr-x 2 www-data www-data 4.0K Nov  8 05:56 locks
-rw-r--r-- 1 www-data www-data  12K Nov  8 05:41 my_wiki_jobqueue.sqlite
-rw-r--r-- 1 www-data www-data 1.4M Nov  8 05:42 my_wiki_l10n_cache.sqlite
-rw-r--r-- 1 www-data www-data 912K Nov  8 05:56 my_wiki.sqlite
-rw-r--r-- 1 www-data www-data  28K Nov  8 05:56 wikicache.sqlite

What should have happened instead?:

The file mode should be 600 not 644.

This allows anyone on the system to read the DB contents, including password hashes, session information, IP addresses (if checkuser installed), (unencrypted) 2FA codes, user preferences, deleted pages, and any other private data in the DB.

Related Objects

StatusSubtypeAssignedTask
ResolvedSecurityBawolff

Event Timeline

I'm not sure how seriously we consider this, since it does require the attacker to have local access to the host, which may happen in shared hosts but is generally pretty unusual. Should this be secret until release, or can i just put a patch up on gerrit?

One thing to note here, is that the object cache table is in a separate sqlite file with a name "wikicache", the idea being all wikis can share it. So potentially making it 600 could mess that up if different wikis are running on different users, but it would already be messed up in the current 644 permissions. Its unclear to me that using this shared name is a good idea, since even in WAL mode sqlite only supports one write at a time, however i suppose that is off-topic to this issue.

Patch:

Of course, this only would affect the installation process. It does not fix pre-existing DB files. I'm not sure if there is a good way to fix old files (Maybe we could do it in update.php) perhaps we should just inform users that they should adjust their DB permissions if they are on a shared host.

mmartorana changed the task status from Open to In Progress.Nov 21 2022, 3:03 PM
mmartorana triaged this task as Low priority.
mmartorana changed Risk Rating from N/A to Low.

Since the risk for this issue is very low, we are not going to deploy it to WMF production at this moment.

We will backport this at the next security release that is approaching.

Whoops, I think this task should be a subtask of {T318965}, not the other way around...

Reedy removed a subtask: Restricted Task.Dec 19 2022, 4:28 PM
Reedy added a parent task: Restricted Task.

Change 870979 had a related patch set uploaded (by Reedy; author: Brian Wolff):

[mediawiki/core@REL1_35] SECURITY: Make sqlite DB files not world readable

https://gerrit.wikimedia.org/r/870979

Change 870982 had a related patch set uploaded (by Reedy; author: Brian Wolff):

[mediawiki/core@REL1_38] SECURITY: Make sqlite DB files not world readable

https://gerrit.wikimedia.org/r/870982

Change 870985 had a related patch set uploaded (by Reedy; author: Brian Wolff):

[mediawiki/core@REL1_39] SECURITY: Make sqlite DB files not world readable

https://gerrit.wikimedia.org/r/870985

Change 870979 merged by jenkins-bot:

[mediawiki/core@REL1_35] SECURITY: Make sqlite DB files not world readable

https://gerrit.wikimedia.org/r/870979

Change 870982 merged by jenkins-bot:

[mediawiki/core@REL1_38] SECURITY: Make sqlite DB files not world readable

https://gerrit.wikimedia.org/r/870982

Change 870985 merged by jenkins-bot:

[mediawiki/core@REL1_39] SECURITY: Make sqlite DB files not world readable

https://gerrit.wikimedia.org/r/870985

Reedy claimed this task.
Reedy reassigned this task from Reedy to Bawolff.
Reedy subscribed.
Reedy renamed this task from sqlite should not create DB file world-readable to CVE-2022-47927: sqlite should not create DB file world-readable.Dec 23 2022, 12:52 PM
Reedy removed a project: Patch-For-Review.

Change 871186 had a related patch set uploaded (by Reedy; author: Brian Wolff):

[mediawiki/core@master] SECURITY: Make sqlite DB files not world readable

https://gerrit.wikimedia.org/r/871186

Change 871186 merged by jenkins-bot:

[mediawiki/core@master] SECURITY: Make sqlite DB files not world readable

https://gerrit.wikimedia.org/r/871186

It looks like https://cve.report/CVE-2022-47927 is still marked reserved and hasn't been published yet.

It looks like https://cve.report/CVE-2022-47927 is still marked reserved and hasn't been published yet.

Yeah, unfortunately, if you don't check the box that the issue has been disclosed on Mitre's form, it gets set to this indefinite status. And then, AFAIK, you need to contact Mitre (possibly a few times) to let them know that the issue really has been disclosed and then they'll fix the status of the CVE. Maybe @Reedy could follow up with them, as I believe they requested this CVE for the most recent security release?

sbassett changed the visibility from "Custom Policy" to "Public (No Login Required)".
sbassett changed the edit policy from "Custom Policy" to "All Users".
sbassett moved this task from Incoming to Our Part Is Done on the Security-Team board.
sbassett added a project: SecTeam-Processed.