Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Repositories which require authentication can be cloned with bogus login data #324

Closed
gitblit opened this issue Aug 12, 2015 · 10 comments
Closed

Repositories which require authentication can be cloned with bogus login data #324

gitblit opened this issue Aug 12, 2015 · 10 comments
Assignees
@gitblit
Labels
🐱 Defect Priority-Critical Status-Fixed
Milestone
0.7.0

Comments

@gitblit
Copy link
Collaborator

gitblit commented Aug 12, 2015

Originally reported on Google Code with ID 28

What steps will reproduce the problem?
1. Set a repository to "authenticated clone, view & push"
2. Clone the repository locally (I use TortoiseGit) using the URL shown in the summary
page in gitblit
3. Enter bogus login information

What is the expected output? What do you see instead?
I expected an authentication error but the repository was cloned successfully.

What version of the product are you using? On what operating system?
gitblit in Jetty 8.0.3. (also tried in Jetty 6.1.1) in Windows Server 2008 R2 using
plain http access

Reported by rob2d2 on 2011-10-23 00:58:27
@gitblit
Copy link
Collaborator Author

gitblit commented Aug 12, 2015 

Uh oh.  I will take a look at this very soon - maybe today.

Reported by James.Moger on 2011-10-23 13:46:55

  • Status changed: Accepted
  • Labels added: Priority-Critical, Milestone-0.7.0
  • Labels removed: Priority-Medium

@gitblit gitblit self-assigned this Aug 12, 2015
@gitblit
Copy link
Collaborator Author

gitblit commented Aug 12, 2015

Reported by James.Moger on 2011-10-23 13:47:11

@gitblit
Copy link
Collaborator Author

gitblit commented Aug 12, 2015 

My test setup is a little different than your setup....

* I always test on Jetty 7 (GO build) and occasionally Tomcat 6 (and Tomcat 7 in master).
* Gitblit 0.6.0 is servlet-api 2.5, not servlet-api 3.0 (Jetty 8).  The next release
is servlet-api 3.0 ready (Tomcat 6/Tomcat7/Jetty 8).
* I don't have TortoiseGit, but I don't *think* that should be an issue since the reported
error is server-side.

My preliminary result is that I can not reproduce your finding with 0.6.0 or the current
master branch.  I have tried cloning a repository at each restriction level with a
unit test.  It did surprise me to see that an empty repository is created locally,
though even though the clone failed.

Things you could do to help me diagnose the issue further:

1. Don't test on Jetty 8 since that is servlet 3.0 and may change/break authentication
(like trying to run Gitblit 0.6.0 on Tomcat 7).

2. Set "web.debugMode=true" in web.xml - this will add some logging to the AccessRestrictionFilter
class.  Confirm the received credentials in the log.  The log will say something like
when you try to clone:

INFO  ARF: ticgit.git/info/refs?service=git-upload-pack (401)
INFO  AUTH: Challenge Basic realm="Gitblit"
INFO  AUTH: invalid credentials (bogus:bogus)
INFO  ARF: ticgit.git/info/refs?service=git-upload-pack (401)
INFO  AUTH: Challenge Basic realm="Gitblit"

3. If TortoiseGit still succeeds and the credentials are the bogus ones, confirm that
the cloned repository actually has commits in it and is not just empty.

If all those are true, then perhaps TortoiseGit is falling back to the "dumb" http
protocol in which case I will have to review that some more because I did not think
that I was serving the "dumb" style.

Reported by James.Moger on 2011-10-23 14:58:22

@gitblit
Copy link
Collaborator Author

gitblit commented Aug 12, 2015 

I did not yet change back to an old Jetty version (but as I said, I used Jetty 6 at
first and had the same behaviour).
The repositories I cloned are not empty, the debug logs look like this:

INFO   | jvm 1    | 2011/10/23 18:06:59 | INFO  ARF: kake.git/info/refs?service=git-upload-pack
(401)
INFO   | jvm 1    | 2011/10/23 18:06:59 | INFO  AUTH: Challenge Basic realm="Gitblit"
INFO   | jvm 1    | 2011/10/23 18:07:05 | INFO  ARF: kake.git/info/refs?service=git-upload-pack
(401)
INFO   | jvm 1    | 2011/10/23 18:07:05 | INFO  AUTH: Challenge Basic realm="Gitblit"
INFO   | jvm 1    | 2011/10/23 18:07:05 | INFO  AUTH: invalid credentials (bla:blub)
INFO   | jvm 1    | 2011/10/23 18:07:05 | INFO  ARF: kake.git/info/refs?service=git-upload-pack
(401)
INFO   | jvm 1    | 2011/10/23 18:07:05 | INFO  AUTH: Challenge Basic realm="Gitblit"
INFO   | jvm 1    | 2011/10/23 18:07:05 | INFO  ARF: kake.git/info/refs (100) unauthenticated
INFO   | jvm 1    | 2011/10/23 18:07:06 | INFO  ARF: kake.git/HEAD (100) unauthenticated
INFO   | jvm 1    | 2011/10/23 18:07:06 | INFO  ARF: kake.git/objects/e5/8cb482d051fe0d269468d76e556f23cfb84fab
(100) unauthenticated
INFO   | jvm 1    | 2011/10/23 18:07:06 | INFO  ARF: kake.git/objects/da/12904f9adf481ffcf1fd695e76df748542770f
(100) unauthenticated
INFO   | jvm 1    | 2011/10/23 18:07:06 | INFO  ARF: kake.git/objects/67/f869a6b5fff28b25eb5368adff0a67ad67393c
(100) unauthenticated
INFO   | jvm 1    | 2011/10/23 18:07:06 | INFO  ARF: kake.git/objects/18/d70f02cb8eeded3bb20b75f0cd29bb66157990
(100) unauthenticated
INFO   | jvm 1    | 2011/10/23 18:07:06 | INFO  ARF: kake.git/objects/ff/58cd936270ea2d151448f5f1cfb5a887213682
(100) unauthenticated

But it's still cloned successfully.

Reported by rob2d2 on 2011-10-23 16:11:27

@gitblit
Copy link
Collaborator Author

gitblit commented Aug 12, 2015 

Ok.  Please repeat with the GO version and post your findings to help me determine where
the problem lies.

Reported by James.Moger on 2011-10-23 16:26:59

@gitblit
Copy link
Collaborator Author

gitblit commented Aug 12, 2015 

Same thing happens. I copied in one of my repositories, enabled http and started gibtlit
go locally. Then I cloned successfully from localhost using bogus login data. On Win7
with a 64bit Java7u1.
I can send you the whole thing including the repository if it helps.

Reported by rob2d2 on 2011-10-23 16:57:31

@gitblit
Copy link
Collaborator Author

gitblit commented Aug 12, 2015 

That might be very diagnostic.  Try zipping and attaching to this issue - if its not
too large.  I'll install TortoiseGit to see if I can replicate here.

Reported by James.Moger on 2011-10-23 17:49:57

@gitblit
Copy link
Collaborator Author

gitblit commented Aug 12, 2015 

Oh shit.  I just replicated this with TortoiseGit.  This is obviously a nasty security
hole in my restriction filter implementation.  EGit/JGit doesn't trigger this.  Last
I checked, CGit doesn't trigger this either... but maybe it does now.  I'll check that
too.  It looks like TortoiseGit just keeps chugging along trying to make every URL
request instead of (really) stopping after authentication failure.  Actually, what
happens is that it prompts for credentials on the first challenge, but then disregards
all subsequent challenges and makes url requests which Gitblit happily processes, even
though it should not.

Thanks for reporting this.  I'll have this fixed today or tomorrow on Master.  I was
planning on a new release (big changes) by end of the week... this will be an *important*
addition.

Reported by James.Moger on 2011-10-23 18:28:00

@gitblit
Copy link
Collaborator Author

gitblit commented Aug 12, 2015 

Ah, okidoki, glad I could help, really like the software.

Reported by rob2d2 on 2011-10-23 21:20:38

@gitblit
Copy link
Collaborator Author

gitblit commented Aug 12, 2015 

Fix deployed in v0.7.0.

Reported by James.Moger on 2011-11-11 23:16:24

  • Status changed: Fixed

@gitblit gitblit closed this as completed Aug 12, 2015
@flaix flaix modified the milestone: 0.7.0 Dec 13, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@gitblit gitblit

Labels
🐱 Defect Priority-Critical Status-Fixed
Projects
None yet
Milestone
0.7.0
Development

No branches or pull requests
2 participants
@gitblit @flaix