Gitlab

起因 最近一台服务器出现服务器资源 cpu、内存过高的情况，通过对进程的分析，发现是 gitlab 容器进程，怀疑是 gitlab 被入侵运行了挖矿病毒，通过对 gitlab 日志的分析，可以得出入侵者是利用了 gitlab 的 CVE-2021-22205 的漏洞，对 gitlab 进行了攻击。 CVE-2021-22205 介绍 CVE-2021-22205是一个严重的严重性漏洞(CVSS 10.0)，它是由第三方文件解析器Exif-Tool对图像文件进行不当验证的结果，导致远程命令执行漏洞，可能导致您的GitLab实例被攻击。 以下版本受到漏洞影响: 11.9.x - 13.8.7 13.9.0 - 13.9.5 13.10.0 - 13.10.2 解决 gitlab 发布了 GitLab 13.10.3、13.9.6 和 13.8.8 版本来解决这个漏洞。请尽快升级。 如果无法即使更新和使用热更新补丁解决，可以通过将exiftool脚本替换为cat -。这个解决方案将防止从上传的图像中剥离所有的exif数据。 将 /opt/gitlab/embedded/bin/exiftool 脚本内容替换为 1 2 3 #!/bin/bash cat - 这种方法不是长久之计，每次重启容器时都要手动修改文件，还是尽快更新版本。 原因 根据gitlab的官方漏洞issues来看，当访问接口/uploads/user上传图像文件时，GitLab Workhorse会将扩展名为jpg、jpeg、tiff文件传递给ExifTool。用于删除其中不合法的标签。具体的标签在workhorse/internal/upload/exif/exif.go中的startProcessing方法中有定义，为白名单处理。 而ExifTool在解析文件的时候会忽略文件的扩展名，尝试根据文件的内容来确定文件类型，其中支持的类型有DjVu。 关键在于ExifTool在解析DjVu注释的ParseAnt函数中存在漏洞，所以我们就可以通过构造DjVu文件并插入恶意注释内容将其改为jpg后缀上传，因为gitlab并未在这个过程中验证文件内容是否是允许的格式，最后让ExifTool以DjVu形式来解析文件，造成了ExifTool代码执行漏洞。 该漏洞存在于ExifTool的7.44版本以上，在12.4版本中修复。Gitlab v13.10.2使用的ExifTool版本为11.70。并且接口/uploads/user可通过获取的X-CSRF-Token和未登录Session后来进行未授权访问。最终造成了GitLab未授权的远程代码执行漏洞。 其它 gitlab 提供了对 gitlab 安全的一些最佳实践: https://about.gitlab.com/blog/2020/05/20/gitlab-instance-security-best-practices/ 参考 https://hackerone.com/reports/1154542 https://www.anquanke.com/post/id/266606 https://mp.weixin.qq.com/s?__biz=Mzg3MDAzMDQxNw==&mid=2247491418&idx=1&sn=853be1256de894c3c579a07738c11590 https://about.gitlab.com/blog/2021/11/04/action-needed-in-response-to-cve2021-22205/ https://forum.gitlab.com/t/cve-2021-22205-how-to-determine-if-a-self-managed-instance-has-been-impacted/60918?_gl=11y48o1u_gaODE5OTE4NTMuMTY2MjgxODQ3OQ.._ga_ENFH3X7M5Y*MTY2MjgxODQ5MC4xLjAuMTY2MjgxOTE4Ny4wLjAuMA.. https://forum.gitlab.com/t/cve-2021-22205-how-to-determine-if-a-self-managed-instance-has-been-impacted/60918/2?_gl=11y48o1u_gaODE5OTE4NTMuMTY2MjgxODQ3OQ.._ga_ENFH3X7M5Y*MTY2MjgxODQ5MC4xLjAuMTY2MjgxOTE4Ny4wLjAuMA.. https://about.gitlab.com/releases/2021/04/14/security-release-gitlab-13-10-3-released/ https://hackerone....

今天我来讲一讲在 golang 中如何在项目中引用私有仓库吧，在我们的实际生产开发中，往往需要在项目中引用内部代码管理平台上的仓库代码，接下来我来介绍如何在 golang 中使用私有仓库模块。 设置 1 我们的私有代码往往存储在内部的代码管理平台(如 gitlab, gittee 等)上，假设我们的地址是 git.xx.vip. 接下来开始设置一些配置项。 2 设置 GOPRIVATE 变量。 我们先设置 GOPRIVATE 环境变量，GOPRIVATE 会将 GOPRIVATE 变量值所匹配的路径前缀视为私有模块，就不会使用代理和进行校验。设置了 GOPRIVATE 变量后，GONOPROXY 和 GONOSUMDB 环境变量 也会接收同样的值。 3 设置 GOINSECURE 变量 我们的 gitlab 等代码管理平台往往没有使用 https 协议，所以我们需要设置 GOINSECURE 变量，GOINSECURE 变量中的值以逗号分隔，其中的每一个值在 go get 时 不会进行https 协议的校验, 只会采用 http 协议。 4 go get 设置完以上步骤后，可以执行 go get 看看效果，具体命令: go get -v git.xx.vip/swords/xkratos 可以看到相应的库已经顺利拉取成功，并且输出了相应的版本信息 参考 https://go.dev/ref/mod https://go.zhangdeman.cn/archives/62430e03.html https://forum.golangbridge.org/t/using-go-get-to-retrieve-modules-packages-from-a-private-server/17896/6 https://github.com/GoogleCloudPlatform/govanityurls