mirror of
https://github.com/git/git
synced 2024-08-27 19:49:21 +00:00
Merge branch 'mm/push-social-engineering-attack-doc' into maint
Doc update on fetching and pushing. * mm/push-social-engineering-attack-doc: doc: mention transfer data leaks in more places
This commit is contained in:
commit
f976c89a20
|
@ -2940,6 +2940,11 @@ is omitted from the advertisements but `refs/heads/master` and
|
||||||
`refs/namespaces/bar/refs/heads/master` are still advertised as so-called
|
`refs/namespaces/bar/refs/heads/master` are still advertised as so-called
|
||||||
"have" lines. In order to match refs before stripping, add a `^` in front of
|
"have" lines. In order to match refs before stripping, add a `^` in front of
|
||||||
the ref name. If you combine `!` and `^`, `!` must be specified first.
|
the ref name. If you combine `!` and `^`, `!` must be specified first.
|
||||||
|
+
|
||||||
|
Even if you hide refs, a client may still be able to steal the target
|
||||||
|
objects via the techniques described in the "SECURITY" section of the
|
||||||
|
linkgit:gitnamespaces[7] man page; it's best to keep private data in a
|
||||||
|
separate repository.
|
||||||
|
|
||||||
transfer.unpackLimit::
|
transfer.unpackLimit::
|
||||||
When `fetch.unpackLimit` or `receive.unpackLimit` are
|
When `fetch.unpackLimit` or `receive.unpackLimit` are
|
||||||
|
@ -2949,7 +2954,7 @@ transfer.unpackLimit::
|
||||||
uploadarchive.allowUnreachable::
|
uploadarchive.allowUnreachable::
|
||||||
If true, allow clients to use `git archive --remote` to request
|
If true, allow clients to use `git archive --remote` to request
|
||||||
any tree, whether reachable from the ref tips or not. See the
|
any tree, whether reachable from the ref tips or not. See the
|
||||||
discussion in the `SECURITY` section of
|
discussion in the "SECURITY" section of
|
||||||
linkgit:git-upload-archive[1] for more details. Defaults to
|
linkgit:git-upload-archive[1] for more details. Defaults to
|
||||||
`false`.
|
`false`.
|
||||||
|
|
||||||
|
@ -2963,13 +2968,19 @@ uploadpack.allowTipSHA1InWant::
|
||||||
When `uploadpack.hideRefs` is in effect, allow `upload-pack`
|
When `uploadpack.hideRefs` is in effect, allow `upload-pack`
|
||||||
to accept a fetch request that asks for an object at the tip
|
to accept a fetch request that asks for an object at the tip
|
||||||
of a hidden ref (by default, such a request is rejected).
|
of a hidden ref (by default, such a request is rejected).
|
||||||
see also `uploadpack.hideRefs`.
|
See also `uploadpack.hideRefs`. Even if this is false, a client
|
||||||
|
may be able to steal objects via the techniques described in the
|
||||||
|
"SECURITY" section of the linkgit:gitnamespaces[7] man page; it's
|
||||||
|
best to keep private data in a separate repository.
|
||||||
|
|
||||||
uploadpack.allowReachableSHA1InWant::
|
uploadpack.allowReachableSHA1InWant::
|
||||||
Allow `upload-pack` to accept a fetch request that asks for an
|
Allow `upload-pack` to accept a fetch request that asks for an
|
||||||
object that is reachable from any ref tip. However, note that
|
object that is reachable from any ref tip. However, note that
|
||||||
calculating object reachability is computationally expensive.
|
calculating object reachability is computationally expensive.
|
||||||
Defaults to `false`.
|
Defaults to `false`. Even if this is false, a client may be able
|
||||||
|
to steal objects via the techniques described in the "SECURITY"
|
||||||
|
section of the linkgit:gitnamespaces[7] man page; it's best to
|
||||||
|
keep private data in a separate repository.
|
||||||
|
|
||||||
uploadpack.allowAnySHA1InWant::
|
uploadpack.allowAnySHA1InWant::
|
||||||
Allow `upload-pack` to accept a fetch request that asks for any
|
Allow `upload-pack` to accept a fetch request that asks for any
|
||||||
|
|
|
@ -192,6 +192,8 @@ The first command fetches the `maint` branch from the repository at
|
||||||
objects will eventually be removed by git's built-in housekeeping (see
|
objects will eventually be removed by git's built-in housekeeping (see
|
||||||
linkgit:git-gc[1]).
|
linkgit:git-gc[1]).
|
||||||
|
|
||||||
|
include::transfer-data-leaks.txt[]
|
||||||
|
|
||||||
BUGS
|
BUGS
|
||||||
----
|
----
|
||||||
Using --recurse-submodules can only fetch new commits in already checked
|
Using --recurse-submodules can only fetch new commits in already checked
|
||||||
|
|
|
@ -237,6 +237,8 @@ If you tried a pull which resulted in complex conflicts and
|
||||||
would want to start over, you can recover with 'git reset'.
|
would want to start over, you can recover with 'git reset'.
|
||||||
|
|
||||||
|
|
||||||
|
include::transfer-data-leaks.txt[]
|
||||||
|
|
||||||
BUGS
|
BUGS
|
||||||
----
|
----
|
||||||
Using --recurse-submodules can only fetch new commits in already checked
|
Using --recurse-submodules can only fetch new commits in already checked
|
||||||
|
|
|
@ -559,6 +559,8 @@ Commits A and B would no longer belong to a branch with a symbolic name,
|
||||||
and so would be unreachable. As such, these commits would be removed by
|
and so would be unreachable. As such, these commits would be removed by
|
||||||
a `git gc` command on the origin repository.
|
a `git gc` command on the origin repository.
|
||||||
|
|
||||||
|
include::transfer-data-leaks.txt[]
|
||||||
|
|
||||||
GIT
|
GIT
|
||||||
---
|
---
|
||||||
Part of the linkgit:git[1] suite
|
Part of the linkgit:git[1] suite
|
||||||
|
|
|
@ -61,22 +61,4 @@ For a simple local test, you can use linkgit:git-remote-ext[1]:
|
||||||
git clone ext::'git --namespace=foo %s /tmp/prefixed.git'
|
git clone ext::'git --namespace=foo %s /tmp/prefixed.git'
|
||||||
----------
|
----------
|
||||||
|
|
||||||
SECURITY
|
include::transfer-data-leaks.txt[]
|
||||||
--------
|
|
||||||
|
|
||||||
Anyone with access to any namespace within a repository can potentially
|
|
||||||
access objects from any other namespace stored in the same repository.
|
|
||||||
You can't directly say "give me object ABCD" if you don't have a ref to
|
|
||||||
it, but you can do some other sneaky things like:
|
|
||||||
|
|
||||||
. Claiming to push ABCD, at which point the server will optimize out the
|
|
||||||
need for you to actually send it. Now you have a ref to ABCD and can
|
|
||||||
fetch it (claiming not to have it, of course).
|
|
||||||
|
|
||||||
. Requesting other refs, claiming that you have ABCD, at which point the
|
|
||||||
server may generate deltas against ABCD.
|
|
||||||
|
|
||||||
None of this causes a problem if you only host public repositories, or
|
|
||||||
if everyone who may read one namespace may also read everything in every
|
|
||||||
other namespace (for instance, if everyone in an organization has read
|
|
||||||
permission to every repository).
|
|
||||||
|
|
30
Documentation/transfer-data-leaks.txt
Normal file
30
Documentation/transfer-data-leaks.txt
Normal file
|
@ -0,0 +1,30 @@
|
||||||
|
SECURITY
|
||||||
|
--------
|
||||||
|
The fetch and push protocols are not designed to prevent one side from
|
||||||
|
stealing data from the other repository that was not intended to be
|
||||||
|
shared. If you have private data that you need to protect from a malicious
|
||||||
|
peer, your best option is to store it in another repository. This applies
|
||||||
|
to both clients and servers. In particular, namespaces on a server are not
|
||||||
|
effective for read access control; you should only grant read access to a
|
||||||
|
namespace to clients that you would trust with read access to the entire
|
||||||
|
repository.
|
||||||
|
|
||||||
|
The known attack vectors are as follows:
|
||||||
|
|
||||||
|
. The victim sends "have" lines advertising the IDs of objects it has that
|
||||||
|
are not explicitly intended to be shared but can be used to optimize the
|
||||||
|
transfer if the peer also has them. The attacker chooses an object ID X
|
||||||
|
to steal and sends a ref to X, but isn't required to send the content of
|
||||||
|
X because the victim already has it. Now the victim believes that the
|
||||||
|
attacker has X, and it sends the content of X back to the attacker
|
||||||
|
later. (This attack is most straightforward for a client to perform on a
|
||||||
|
server, by creating a ref to X in the namespace the client has access
|
||||||
|
to and then fetching it. The most likely way for a server to perform it
|
||||||
|
on a client is to "merge" X into a public branch and hope that the user
|
||||||
|
does additional work on this branch and pushes it back to the server
|
||||||
|
without noticing the merge.)
|
||||||
|
|
||||||
|
. As in #1, the attacker chooses an object ID X to steal. The victim sends
|
||||||
|
an object Y that the attacker already has, and the attacker falsely
|
||||||
|
claims to have X and not Y, so the victim sends Y as a delta against X.
|
||||||
|
The delta reveals regions of X that are similar to Y to the attacker.
|
Loading…
Reference in a new issue