Mercurial 4.5.1 / 4.5.2 (2018-03-06)
(4.5.2 was released immediately after 4.5.1 to fix a release
oversight.)
This is a regularly-scheduled bugfix release.
1.1. Security Fixes
All versions of Mercurial prior to 4.5.2 have vulnerabilities in
the HTTP server that allow permissions bypass to:
Perform writes on repositories that should be read-only
Perform reads on repositories that shouldn't allow read access
The nature of the vulnerabilities is:
Wire protocol commands that didn't explicitly declare their
permissions had no permissions checking done. The web.{allow-pull,
allow-push, deny_read, etc} config options governing access
control were never consulted when running these commands. This
allowed permissions bypass for impacted commands.
The batch wire protocol command did not list its permission
requirements nor did it enforce permissions on individual
sub-commands.
The implication of these vulnerabilities is that no permissions
checking was performed on commands and this could lead to accessing
data that web.* config options were supposed to prevent access to
or modifying data (via wire protocol commands that can mutate data)
without authorization. A Mercurial HTTP server in its default
configuration is supposed to be read-only. However, a well-crafted
batch command could invoke commands that perform writes.
The batch write permissions bypass has been present since Mercurial
1.9. The flaw of not checking permissions for wire protocol commands
that don't declare their needed permissions has been present since
Mercurial 1.0.
Assuming you are running a server without any custom commands
provided by extensions, your exposure is unauthorized data access
(if relying on the web.* config options to limit access) and
unauthorized data mutation via the batch command.
Server operators can detect unauthorized use of the batch command
by looking for requests to URLs of the form repo?cmd=batch with
arguments containing pushkey or unbundle. This may produce false
positives. A more comprehensive check would decode the argument
string and verify that pushkey or unbundle are command names (not
values). The arguments specified via x-hgarg-<N> request headers
can span multiple headers. So advanced attackers could hide the
vulnerability by splitting a pushkey or unbundle string across
multiple headers. So the only reliable way to detect if this
vulnerability is being exploited is to decode these headers like
Mercurial does. The format for specifying arguments is documented
at
https://www.mercurial-scm.org/repo/hg/file/4.5/mercurial/help/internals/wireprotocol.txt#l26.
Python code for decoding headers is at
https://www.mercurial-scm.org/repo/hg/file/4.5/mercurial/hgweb/protocol.py#l70.
Mercurial 4.5.2 fixes these vulnerabilities by:
Performing permissions checking on all wire protocol commands,
not just commands that list their permissions.
Checking permissions on sub-commands issued to the batch command.
Wire protocol commands not declaring wire protocol permissions will
be assumed to be read-write commands and a server in its default
configuration (which only allows read-only access), will refuse to
execute these commands.
For package maintainers needing to backport the fixes, the relevant
changesets from 4.5.2 are 2c647da851ed::2ecb0fc535b1. These can be
viewed online at e.g.
https://www.mercurial-scm.org/repo/hg/rev/2ecb0fc535b1. The author
of these commits has backports to 4.4 and 4.3 on a personal fork
at https://hg.mozilla.org/users/gszorc_mozilla.com/hg. The backports
for 4.4 are a4843835c835::7cf827e5f8af and for 4.3 are
db527ae12671::86f9a022ccb8. To obtain these changesets, run e.g.
hg pull -r 7cf827e5f8af https://hg.mozilla.org/users/gszorc_mozilla.com/hg.
1.2. Backwards Compatibility Changes
The "batch" wire protocol command now enforces permissions of
each invoked sub-command. Wire protocol commands must define
their operation type or the "batch" command will assume they
can write data and will prevent their execution on HTTP servers
unless the HTTP request method is POST, the server is configured
to allow pushes, and the (possibly authenticated) HTTP user is
authorized to perform a push.
Wire protocol commands not defining their operation type in
"wireproto.PERMISSIONS" are now assumed to be used for "push"
operations and access control to run those commands is now
enforced accordingly.
1.3. Bug Fixes
fileset: don't abort when running copied() on a revision with a removed file
date: fix parsing months
setup: only allow Python 3 from a source checkout (issue5804)
annotate: do not poorly split lines at CR (issue5798)
subrepo: don't attempt to share remote sources (issue5793)
subrepo: activate clone pooling to enable sharing with remote URLs
changegroup: do not delta lfs revisions
revlog: do not use delta for lfs revisions
revlog: resolve lfs rawtext to vanilla rawtext before applying delta
c1f9cb035a