Re: Gitview Shell Injection Vulnerability

[Stefan Beller <sbeller@google.com>]

+cc the author of gitview

On Tue, Dec 27, 2016 at 12:29 AM, Javantea <jvoss@altsci.com> wrote:
> I have found a shell injection vulnerability in contrib/gitview/gitview.
>
> Gitview Shell Injection Vulnerability
>
> Versions affected: 8cb711c8a5-1d1bdafd64 (<=2.11.0)
>
> Gitview executes shell commands using string concatenation with user supplied data, filenames and branch names. Running Gitview and interacting with the user interface with a malicious filename or branch name in the current repository results in malicious commands being executed as the current user.
>
> AnnotateWindow.add_file_data(self, filename, commit_sha1, line_num):
>     fp = os.popen("git cat-file blob " + commit_sha1 +":"+filename)
>
> AnnotateWindow.annotate(self, filename, commit_sha1, line_num):
>     fp = os.popen("git ls-tree "+ commit_sha1 + " -- " + filename)
>     fp = os.popen("git blame --incremental -C -C -- " + filename + " " + commit_sha1)
>
> GitView.set_branch(self, args):
>     fp = os.popen("git rev-parse --sq --default HEAD " + list_to_string(args, 1))
>     fp = os.popen("git rev-list  --header --topo-order --parents " + git_rev_list_cmd)
>
> The program also has other uses of os.popen but none use values that the user can manipulate. However, the fix should definitely replace these instances so that the code might one day pass pylint and manual code review easier.
>
> The function os.popen has been replaced by safer functions in the subprocess module. The code can be improved easily because it requires very little change to convert the code to work with arrays of strings instead of strings.
>
> If you have any questions or would like a patch, please let me know.
>

I guess you could send a patch to fix it. It is unclear to me
how the patch submission process for these work, though.
Please see contrib/README to see why it is unclear to me.

> I expect that things that start their life in the contrib/ area
> to graduate out of contrib/ once they mature, either by becoming
> projects on their own, or moving to the toplevel directory.  On
> the other hand, I expect I'll be proposing removal of disused
> and inactive ones from time to time.

Maybe it's time for a spring cleanup and remove some old (dead?)
projects from contrib?

Thanks,
Stefan