Last modified: 2014-08-04 23:31:57 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 69047 - Develop countermeasures to the merge page histories attack
Develop countermeasures to the merge page histories attack
Status: NEW
Product: MediaWiki
Classification: Unclassified
Page deletion (Other open bugs)
1.24rc
All All
: Lowest normal with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on: 69049
Blocks: 68311
  Show dependency treegraph
 
Reported: 2014-08-02 14:18 UTC by Nathan Larson
Modified: 2014-08-04 23:31 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Nathan Larson 2014-08-02 14:18:50 UTC
See [[mw:User:MZMcBride/Attacks#Merge_page_histories]]: This attack by a rogue sysop "causes a royal mess that very few people can clean up properly. Find two pages with less than 2500 revisions (A and B) and one page with thousands and thousands of revisions (C). Delete page A and move page B to A's old location. Delete page B and then move page C to B's (and A's) old location. Restore the edits and suddenly you've merged three page's history into one. And there's nothing easy to do to reverse it."

One solution might be to track in log_search or log_params the revision IDs involved in page move, page deletion, and page undeletion events. Then a non-rogue sysop could select the log events to roll back, and the pages could be restored to their condition before those log events occurred.
Comment 1 Bawolff (Brian Wolff) 2014-08-03 02:13:31 UTC
Wasn't there some plan once Special:MergeHistory was better developed to disable history-merging-via-undelete? Maybe I'm misremembering.
Comment 2 Abd ulRahman Lomax 2014-08-03 13:18:48 UTC
The difficult-to-undo damage occurs when the deleted revisions are restored and thus merged, though the same effect arises when revisions are deleted (that is, revisions become merged in the history of deleted revisions). This is one of a class of problems where a single command actually performs many actions that are not reversible with a single command, an "undo." Page moves including subpages can show a similar issue, I found to my regret when I once moved a page and included subpages without checking, and there were hundreds of them and then the move turned out to be a Bad Idea.
Comment 3 Nathan Larson 2014-08-03 13:35:02 UTC
(In reply to Abd ulRahman Lomax from comment #2)
> The difficult-to-undo damage occurs when the deleted revisions are restored
> and thus merged, though the same effect arises when revisions are deleted
> (that is, revisions become merged in the history of deleted revisions). This
> is one of a class of problems where a single command actually performs many
> actions that are not reversible with a single command, an "undo." Page moves
> including subpages can show a similar issue, I found to my regret when I
> once moved a page and included subpages without checking, and there were
> hundreds of them and then the move turned out to be a Bad Idea.

It's not so much when the pages are deleted that the problem arises, as when they're undeleted. When they're deleted, the revisions get moved from the revision table to the archive table, where it's possible to tell which pages they came from by the [[mw:Manual:Archive table#ar_page_id]]. When they're undeleted, they get moved back to the revision table, and they all end up with the same [[mw:Manual:Revision table#rev_page]] if they're being undeleted to the same page title.
Comment 4 Nathan Larson 2014-08-03 13:37:10 UTC
(In reply to Bawolff (Brian Wolff) from comment #1)
> Wasn't there some plan once Special:MergeHistory was better developed to
> disable history-merging-via-undelete? Maybe I'm misremembering.

I hadn't heard of that. I wonder how that would be implemented? E.g., perhaps it would be disallowed to undelete revisions with different ar_page_id values in one undelete action, and/or it would be disallowed to undelete revisions to a page that already exists?
Comment 5 Nathan Larson 2014-08-04 00:20:40 UTC
Proof of concept for (one possible way of) reversing these attacks is [[Extension:MoveRevisions]].
Comment 6 Nathan Larson 2014-08-04 00:21:14 UTC
Er, [[mw:Extension:MoveRevisions]], rather.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links