GitLab部分漏洞分析
GDK运行+调试环境搭建 GDK全称GitLab Development Kit,是GitLab官方为了方便开发者为GitLab开源项目贡献开源代码而开发的一键式GitLab运行+调试部署工具,在需要对GitLab漏洞进行调试和分析的情况下,除去使用GitLab的Docker镜像也可以利用GDK来搭建环境,地址为https://gitlab.com/gitlab-org/gitlab-development-kit。 如果需要分析的是GitLab最新的代码,则使用GDK官方文档里的安装步骤就可以一步到位。但如果利用GDK进行漏洞复现与分析,往往需要使用到老版本的GitLab代码,此时如果使用最新的GDK部署的话,则会不可避免的出现很多依赖相关的问题(如Ruby版本要求不一致,一些Ruby依赖包不符合版本要求等),在整个部署的时候会遇到很多坑。下面大概说一下一个较为可行的部署流程,以及我在部署过程中的一些问题。 此处以v15.1.0-ee版本的部署为例。首先Clone一下GDK: 1 git clone https://gitlab.com/gitlab-org/gitlab-development-kit.git gdk GDK版本调整和初始化 接下来需要查看GitLab版本的发布时间,将GDK也Checkout到对应版本发布日期附近的提交处,这样可以保证GDK使用的Ruby版本和GitLab一致,避免后续安装过程中因为Ruby大版本不一致导致的各种依赖问题。 查看提交记录可以发现v15.1.0-ee的发布时间为2022年6月21日,所以我将GDK调整至2022年7月26日的提交处:77019f1204a3bbcb44bac37bfd0da4059aa130e9。只要保证GDK的Ruby依赖版本不要和GitLab的相差过大即可。 切换版本之后,与官方文档中手动部署的步骤一致,使用make bootstrap初始化GDK,安装GDK相关的依赖。在这篇文章中提到了使用一键脚本部署后再Checkout GitLab到对应版本的方式,经过测试我发现如果版本相差过大,依赖问题依然会存在,并且可能存在数据库结构不一样的问题,因此此处更好的解决方案是手动Clone GitLab仓库,自行Checkout之后再开始部署GDK,如下。 1 2 3 4 5 git clone https://gitlab.com/gitlab-org/gitlab.git gdk/gitlab cd gdk/gitlab git checkout v15.1.0-ee cd .. gdk install 在gdk install的过程中可能会出现各种各样奇奇怪怪的问题,我主要把问题归结于以下两类: 由于GDK调整了到早期版本,有些Bug还没修,通过Google和GDK的Issues大部分可以找到解决方案; 一些Native Extension的编译问题,如OpenSSL、gpgme等等;(gpgme问题出现的频率最高,主要表现为gpgme编译失败,解决方案是不通过bundler安装gpgme而是使用gem install gpgme -- --use-system-libraries手动安装) Ruby版本不同导致的依赖问题,如有些软件包的老版本不再被新版Ruby支持,又或是一些新版本的软件包不被老版本的Ruby支持。(这里因为前面已经通过Checkout把GDK和GitLab的依赖版本调整到尽可能一致了,所以这里不会有太大的问题) 一些配置的修改 gdk install成功跑完之后,就相当于脚本安装结束了。接下来修改gitlab/config/gitlab.yml配置文件,修改监听的IP地址,以及关闭Webpack的开发模式,可以减少一点占用: 1 2 3 4 5 6 7 8 gitlab: host: 0.0.0.0 port: 3000 https: false webpack: dev_server: enabled: false 修改完了配置文件,需要重新编译一下前端资源: ...