Skip to content

Commit 6628eb4

Browse files
peffgitster
authored andcommitted
http: always update the base URL for redirects
If a malicious server redirects the initial ref advertisement, it may be able to leak sha1s from other, unrelated servers that the client has access to. For example, imagine that Alice is a git user, she has access to a private repository on a server hosted by Bob, and Mallory runs a malicious server and wants to find out about Bob's private repository. Mallory asks Alice to clone an unrelated repository from her over HTTP. When Alice's client contacts Mallory's server for the initial ref advertisement, the server issues an HTTP redirect for Bob's server. Alice contacts Bob's server and gets the ref advertisement for the private repository. If there is anything to fetch, she then follows up by asking the server for one or more sha1 objects. But who is the server? If it is still Mallory's server, then Alice will leak the existence of those sha1s to her. Since commit c93c92f (http: update base URLs when we see redirects, 2013-09-28), the client usually rewrites the base URL such that all further requests will go to Bob's server. But this is done by textually matching the URL. If we were originally looking for "http://mallory/repo.git/info/refs", and we got pointed at "http://bob/other.git/info/refs", then we know that the right root is "http://bob/other.git". If the redirect appears to change more than just the root, we punt and continue to use the original server. E.g., imagine the redirect adds a URL component that Bob's server will ignore, like "http://bob/other.git/info/refs?dummy=1". We can solve this by aborting in this case rather than silently continuing to use Mallory's server. In addition to protecting from sha1 leakage, it's arguably safer and more sane to refuse a confusing redirect like that in general. For example, part of the motivation in c93c92f is avoiding accidentally sending credentials over clear http, just to get a response that says "try again over https". So even in a non-malicious case, we'd prefer to err on the side of caution. The downside is that it's possible this will break a legitimate but complicated server-side redirection scheme. The setup given in the newly added test does work, but it's convoluted enough that we don't need to care about it. A more plausible case would be a server which redirects a request for "info/refs?service=git-upload-pack" to just "info/refs" (because it does not do smart HTTP, and for some reason really dislikes query parameters). Right now we would transparently downgrade to dumb-http, but with this patch, we'd complain (and the user would have to set GIT_SMART_HTTP=0 to fetch). Reported-by: Jann Horn <jannh@google.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
1 parent 986d7f4 commit 6628eb4

File tree

4 files changed

+21
-4
lines changed

4 files changed

+21
-4
lines changed

http.c

Lines changed: 8 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1491,9 +1491,9 @@ static int http_request(const char *url,
14911491
*
14921492
* Note that this assumes a sane redirect scheme. It's entirely possible
14931493
* in the example above to end up at a URL that does not even end in
1494-
* "info/refs". In such a case we simply punt, as there is not much we can
1495-
* do (and such a scheme is unlikely to represent a real git repository,
1496-
* which means we are likely about to abort anyway).
1494+
* "info/refs". In such a case we die. There's not much we can do, such a
1495+
* scheme is unlikely to represent a real git repository, and failing to
1496+
* rewrite the base opens options for malicious redirects to do funny things.
14971497
*/
14981498
static int update_url_from_redirect(struct strbuf *base,
14991499
const char *asked,
@@ -1511,10 +1511,14 @@ static int update_url_from_redirect(struct strbuf *base,
15111511

15121512
new_len = got->len;
15131513
if (!strip_suffix_mem(got->buf, &new_len, tail))
1514-
return 0; /* insane redirect scheme */
1514+
die(_("unable to update url base from redirection:\n"
1515+
" asked for: %s\n"
1516+
" redirect: %s"),
1517+
asked, got->buf);
15151518

15161519
strbuf_reset(base);
15171520
strbuf_add(base, got->buf, new_len);
1521+
15181522
return 1;
15191523
}
15201524

t/lib-httpd/apache.conf

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -132,6 +132,14 @@ RewriteRule ^/ftp-redir/(.*)$ ftp://localhost:1000/$1 [R=302]
132132
RewriteRule ^/loop-redir/x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-(.*) /$1 [R=302]
133133
RewriteRule ^/loop-redir/(.*)$ /loop-redir/x-$1 [R=302]
134134

135+
# The first rule issues a client-side redirect to something
136+
# that _doesn't_ look like a git repo. The second rule is a
137+
# server-side rewrite, so that it turns out the odd-looking
138+
# thing _is_ a git repo. The "[PT]" tells Apache to match
139+
# the usual ScriptAlias rules for /smart.
140+
RewriteRule ^/insane-redir/(.*)$ /intern-redir/$1/foo [R=301]
141+
RewriteRule ^/intern-redir/(.*)/foo$ /smart/$1 [PT]
142+
135143
# Apache 2.2 does not understand <RequireAll>, so we use RewriteCond.
136144
# And as RewriteCond does not allow testing for non-matches, we match
137145
# the desired case first (one has abra, two has cadabra), and let it

t/t5551-http-fetch-smart.sh

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -110,6 +110,10 @@ test_expect_success 'redirects re-root further requests' '
110110
git clone $HTTPD_URL/smart-redir-limited/repo.git repo-redir-limited
111111
'
112112

113+
test_expect_success 're-rooting dies on insane schemes' '
114+
test_must_fail git clone $HTTPD_URL/insane-redir/repo.git insane
115+
'
116+
113117
test_expect_success 'clone from password-protected repository' '
114118
echo two >expect &&
115119
set_askpass user@host pass@host &&

t/t5812-proto-disable-http.sh

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -18,6 +18,7 @@ test_proto "smart http" http "$HTTPD_URL/smart/repo.git"
1818

1919
test_expect_success 'curl redirects respect whitelist' '
2020
test_must_fail env GIT_ALLOW_PROTOCOL=http:https \
21+
GIT_SMART_HTTP=0 \
2122
git clone "$HTTPD_URL/ftp-redir/repo.git" 2>stderr &&
2223
{
2324
test_i18ngrep "ftp.*disabled" stderr ||

0 commit comments

Comments
 (0)