GitLab 老旧版本如何升级？

极狐GitLab 正式对外推出 GitLab 专业升级服务 https://dl.gitlab.cn/cm33bsfv！专业的技术人员为您的 GitLab 老旧版本实例进行专业升级！服务详情可以在官网查看详细解读！

那些因为老旧版本而被攻击的例子

话不多说，直接上图，看一个活生生的例子：因为安全漏洞，GitLab 被攻击！

file

图中的用户使用了 GitLab 社区版（GitLab CE），即使在没有开放外网的情况下也被安全漏洞所攻击，从而导致 GitLab 实例不可用，给企业带来了很大的问题。这种问题不是个例，GitLab 在国内有数百万用户，安装的实例数以十万计，如果用户使用的版本过低、过旧，那么遭受安全攻击的风险就越大，上面的例子就会越来越多！

什么是 GitLab老旧版本？

GitLab 的版本发布机制严格遵循 Semantic Versioning，即：主版本号、次版本号和修订号，也即 Major.Minor.Patch。不同版本的发布频率如下图：

版本号类型	版本说明	发版周期
主版本号（Major）	重大功能更新或不兼容的变更	按年发布
次版本号（Minor）	次要功能更新或兼容的变更	按月发布
修订号（Patch）	功能缺陷或者安全漏洞修复	按需发布

对于安全版本的支持

默认情况下，官方只提供最近两个 Minor Release 的安全漏洞修复。

比如，现在最新的版本为 17.4，在发现安全问题以后，官方会发布安全补丁版本，安全补丁版本只会覆盖 17.2、17.3 以及 17.4。对于 17.2 以前的版本不提供安全补丁版本，用户需要升级到最近或者最新的安全版本来减缓安全风险。

对于版本的官方技术支持策略

默认情况下，官方只提供最近两个 Major Release 的官方技术支持。

比如当前最新的 Major 为 17，那么官方提供的技术支持只覆盖 15、16 以及 17 版本。对于 15 以前的版本，官方已经不再提供技术支持，用户在遇到问题以后，需要升级到最近或者最新的安全版本来减缓安全风险。

一表看懂老旧版本的发布时间：

版本	11.x 及以前	12.x	13.x	14.x	15.x	16.x
年份（发布时间）	2018 年及以前	2019年	2020年	2021年	2022年	2023年

关于每个版本包含的安全漏洞，可以在 GitLab 官方网站进行查询。

个别高危漏洞解读

CVE-2024-45409
- 该漏洞在2024年9月份被披露，能够允许攻击者以任意用户身份登录易受攻击的系统；
- 严重等级严重；
- 影响版本：17.3.3 及之前的版本
CVE-2021-22192
- 该漏洞在 2021年2月份被披露，能够允许未经授权的用户在 GitLab 服务器上执行任意代码
- 严重等级严重；
- 影响的版本：GitLab 13.2 及之前的所有版本；
CVE-2019-15749
- 该漏洞在2019年9月份被披露，这是一个 SSRF 漏洞，允许攻击者通过 GitLab 的某些功能绕过服务器的网络隔离，发送任意 HTTP 请求到内部网络或敏感服务，从而获取到服务器内部的敏感信息或进行其他类型的攻击；
- 严重等级高危；
- 影响版本：GitLab 12.4 及之前的所有版本；
CVE-2018-19571
- 该漏洞在2018年12月份被披露，能够允许攻击者读取服务器上的任意文件，从而导致敏感信息泄露。
- 严重等级严重；
- 影响的版本：GitLab 11.4、11.5 及之前的版本

因此，对于老旧版本，存在安全漏洞、缺乏企业技术支持等问题，这些问题带来的后果是很严重的！

老旧版本不升级，有哪些严重后果？

先说结论：任何产品的安全漏洞，一旦被攻击者利用，会带来直接 + 间接的损失。直接损失包括攻击者索要的赎金、监管部门的罚款等；间接损失包括客户的流失、企业名誉的受损等。最终的结果一定是企业经济和声誉的双重损失。这些损失的深层次原因有：

敏感数据遭窃取的高危风险

版本越老旧（比如12、13，甚至12 以下），存在的安全问题就越多，因为时间越长，被挖掘的安全漏洞就越多。有一些高危漏洞是与身份识别相关的，用户可能绕过既有的认证授权机制，直接获取实例的访问权限，这种情况下，攻击者要干的第一件事情肯定是获取与用户相关的机密信息，因为各个国家对于用户个人信息管理都有很严格的法律法规，窃取这些信息之后，企业很大概率就得“支付数据赎金”，而这种数据一旦泄露，客户的信任也随之流失，对于企业来讲可以说是“客财两失”，遭遇灭顶之灾！

篡改代码，构建软件供应链攻击

软件供应链安全攻击事件这些年频发，而且发展态势也从利用已知漏洞进行攻击演变为主动在上游“埋入”攻击点，一旦攻击形成，就会造成严重后果，比如近些年听过的 NPM 投毒事件、Log4j 事件等。对于 GitLab 安全漏洞来讲，如果没有及时升级，相关漏洞可被攻击者利用，如果攻击者绕过认证系统，冒充企业内部用户对托管的代码进行篡改，在产品交付给客户以后，攻击者开始利用提前埋入的漏洞进行攻击，那后果将不可设想。设想一下，如果是一个数据库企业，给成百上千的客户提供了被埋入漏洞的数据库，漏洞发生爆炸后，这个爆炸半径何其巨大！