• Nick Thomas's avatar
    Set a time limit on git upload-pack requests · f2ad577a
    Nick Thomas authored
    When a client does a git fetch over HTTP, workhorse performs an access
    check based on the HTTP request header, then reads the entire request
    body into a temporary file before handing off to Gitaly to service it.
    However, the client has control over how long it takes to read the
    request body. Since the Gitaly RPC only happens once the request body
    is read, people can set up a connection before their access is revoked
    and use it to gain access to code committed days or weeks later.
    
    To resolve this, we place an overall limit of 10 minutes on receiving
    the `upload-pack` request body. Since this is over HTTP, the client is
    using the `--stateless-rpc` mode, and there is no negotiation between
    client and server. The time limit is chosen fairly arbitrarily, but it
    fits well with the existing 10MiB limit on request body size, implying
    a transfer speed of just 17KiB/sec to be able to fill that buffer and
    get a "request too large" error instead of "request too slow".
    
    Workhorse does not expose the `upload-archive` endpoint directly to the
    user; the client in that case is always gitlab-rails, so there is no
    vulnerability there.
    
    The `receive-pack` endpoint is theoretically vulnerable, but Gitaly
    performs a second access check in the pre-receive hook which defeats
    the attack, so no changes are needed.
    
    The SSH endpoints are similarly vulnerable, but since those RPCs are
    bidirectional, a different approach is needed.
    f2ad577a
upload-pack_test.go 755 Bytes