fix gitlab version errors#21489
Conversation
We definitely get issues like this coming up relatively often. Thanks for submitting this to us, I appreciate you taking the time here. |
I'm guilty of creating the issue in modules, happens to the best (and worst) of us |
smcintyre-r7
left a comment
smcintyre-r7
left a comment
There was a problem hiding this comment.
Changes look good. I just ran into the one issue.
| end | ||
|
|
||
| version = gitlab_version_help_commit(normalize_uri(target_uri.path)) | ||
| return convert_to_rex_version_range(version) if version |
There was a problem hiding this comment.
I'm getting a crash right here when the hash isn't in the map. We won't always have all the hashes in the map, so it'd be helpful if we could catch the error and handle it appropriately.
msf auxiliary(scanner/http/gitlab_version) > run
[!] The GITLAB_CSS_PATTERN was found in the response body but the hash found: b78b47d220ed679cc6edeca9043fd7b2742bc435978bd31676c59653a0a12392 does not have a corresponding version in the GITLAB_CSS_MAP
[-] Auxiliary failed: ArgumentError Malformed version number string 35d349e97ce
[-] Call stack:
[-] /home/smcintyre/.rvm/rubies/ruby-3.3.8/lib/ruby/site_ruby/3.3.0/rubygems/version.rb:210:in `initialize'
[-] /home/smcintyre/Projects/metasploit-framework.pr/lib/rex/version.rb:10:in `initialize'
[-] /home/smcintyre/.rvm/rubies/ruby-3.3.8/lib/ruby/site_ruby/3.3.0/rubygems/version.rb:199:in `new'
[-] /home/smcintyre/.rvm/rubies/ruby-3.3.8/lib/ruby/site_ruby/3.3.0/rubygems/version.rb:199:in `new'
[-] /home/smcintyre/Projects/metasploit-framework.pr/lib/msf/core/exploit/remote/http/gitlab/version.rb:436:in `convert_to_rex_version_range'
[-] /home/smcintyre/Projects/metasploit-framework.pr/lib/msf/core/exploit/remote/http/gitlab/version.rb:457:in `gitlab_version'
[-] /home/smcintyre/Projects/metasploit-framework.pr/modules/auxiliary/scanner/http/gitlab_version.rb:23:in `run_host'
[-] /home/smcintyre/Projects/metasploit-framework.pr/lib/msf/core/auxiliary/scanner.rb:130:in `block (2 levels) in run'
[-] /home/smcintyre/Projects/metasploit-framework.pr/lib/msf/core/thread_manager.rb:105:in `block in spawn'
[*] Auxiliary module execution completed
msf auxiliary(scanner/http/gitlab_version) >
FWIW my version is 19.0.0 and the hash is b78b47d220ed679cc6edeca9043fd7b2742bc435978bd31676c59653a0a12392 if you want to add it.
There was a problem hiding this comment.
Fixed it, not pushing yet though. going to work on a way to build out this css_map. we're about 200 releases behind so this needs to be automated.
There was a problem hiding this comment.
msf auxiliary(scanner/http/gitlab_version) > rerun
[*] Reloading module...
[!] The GITLAB_CSS_PATTERN was found in the response body but the hash found: b78b47d220ed679cc6edeca9043fd7b2742bc435978bd31676c59653a0a12392 does not have a corresponding version in the GITLAB_CSS_MAP
[!] Unable to process version 5ac3a0e92e7 from help page (possible commit hash)
[-] Unable to find Gitlab version for 127.0.0.1.
github-project-automation
Bot
moved this from Todo
to Waiting on Contributor
in Metasploit Kanban
|
bringing back to draft while I try out and update the 425 missing versions from here |
2 participants
While using MSF Pro's autodiscovery feature, it ran
auxiliary/scanner/http/gitlab_versionagainst some non-gitlab instances. The module attempted to JSON parse an HTTP HTML response during the API version portion. There were 2 bugs here:This PR fixes both by adding some
rescueblocks.Old and busted
Fixed
Verification
msfconsoleuse auxiliary/scanner/http/gitlab_versionset rhosts(for an IP that isn't running gitlab)run