GitLab

An Update on Project Runner Registration Token Exposed Through Issues Quick Actions Vulnerability

2019-03-25T00:00:00+00:00

Background</h2>
On March 20, 2019 we released a critical security release</a> for a vulnerability in quick actions for issues that can expose project runner registration tokens to unauthorized users. This was originally reported to us on March 14 through our public HackerOne program (identified by jobert</a>).</p>

Response & Mitigation</h2>
In order to mitigate this issue, we developed and applied a patch on GitLab.com on March 17th 2019, and expedited the release of a critical security fix to ensure that both ourselves, and our self-managed customers received a timely mitigation.</p>
On March 24th 2019 we reset runner registration tokens for all projects hosted on GitLab.com. If you are a GitLab.com user, and have automation in place that relies on runner registration tokens, please have the tokens reset following instructions from the official documentation (https://docs.gitlab.com/ee/ci/runners/#resetting-the-registration-token-for-a-project). If you do not have automation in place that relies on running registration tokens, no further action is required on your part.</p>
We have performed an initial investigation and found no evidence to suggest that there has been any security compromise to any project as a result of this issue, but we will continue to investigate and explore ways to help better detect such issues moving forward.</p>
In keeping with our company value of transparency we also believe in communicating about such incidents clearly and promptly. We apologize for the impact this issue may have caused to our users. GitLab takes securing your information and your data extremely seriously. We have significantly grown the size of our internal security team in the last six months, with further plans to grow in 2019 and beyond. We will learn from this incident as we continue to improve upon our security posture even further.</p>
If you have any questions, please contact support@gitlab.com.</p>

GitLab 11.9 released with secrets detection and multiple MR approval rules

2019-03-22T00:00:00+00:00

Quickly learn if secrets have been leaked</h3>
Inadvertently committing credentials to a shared repository can have serious consequences, yet it is a simple mistake to make. Once an attacker gets your password or API key, they can take over your account, lock you out, and fraudulently spend money. This can even lead to a domino effect where access to one account grants access to others. With the stakes so high, it’s of paramount importance to learn as quickly as possible if secrets have been leaked.</p>
With this release, we’re introducing secret detection</a> as part of our SAST functionality. Each commit is scanned by a CI/CD job to ensure it doesn’t contain secrets. If the scan detects secrets, the developer is alerted in the merge request, allowing them to take action quickly to invalidate the leaked credentials and generate new ones.</p>

Enforce proper change management</h3>
As an organization grows and becomes more complex, it becomes difficult to keep alignment across different parts of the organization. At the same time, the consequences of merging improper or insecure code also increase when an application has more users and generates more revenue. For many organizations, ensuring proper review process is followed before code is merged is a hard requirement because the risks of not doing so are so great.</p>
With GitLab 11.9, we’re providing greater controls and more structure with Merge request approval rules</a>. Previously, you could specify either an individual or a group for required approval (where any single member of the group can provide approval). Now, multiple rules can be added to a merge request to require individual approvers specifically, or even require a number of approvers from a particular group. Additionally, the Code Owners feature is an integrated part of approval rules, making it easy to track down who should approve.</p>
This allows organizations to implement complex approval flows, all while maintaining the simplicity of GitLab’s single application where issues, code, pipelines, and monitoring data are visible and accessible to inform decisions and speed approval.</p>

ChatOps is now open source</h3>
GitLab ChatOps is a powerful automation tool, allowing you to execute any CI/CD job and receive the status of the job directly from chat apps like Slack and Mattermost. Originally released in GitLab 10.6</a>, ChatOps was part of the GitLab Ultimate tier. As part of our product strategy</a> and commitment to open source</a>, we occasionally move features down in tier and never move them up.</p>
With ChatOps, we felt this was functionality that everyone could benefit from and that the feature itself could benefit from community contributions.</p>
In GitLab 11.9, we’ve open sourced ChatOps</a> so it is available to use in GitLab self-managed Core and GitLab.com Free, and is open for community contributions.</p>

And much more!</h3>
So many great features are available in this release like Auditing for feature flags</a>, Vulnerability remediation merge request</a>, and CI/CD templates for security jobs</a> that you’ll want to read on to learn about them all!</p>
Join us for an upcoming event</a> </p>

Extending free use of CI/CD for GitHub on GitLab.com 2019-03-21T00:00:00+00:00 CI/CD is one of the best parts of GitLab. Our robust feature set and powerful Runner architecture have earned us some strong industry accolades. While we believe using GitLab end-to-end as a single application is the best experience, we also believe in playing well with others</a> so that you can use the tools you want without vendor lock-in. In this spirit, we built CI/CD for external repos</a> and CI/CD for GitHub</a> to allow you to host your code repositories on GitHub.com, GitHub Enterprise, BitBucket, or any git server, while using GitLab CI/CD to build, test, and deploy your code.</p> We decided to extend the deadline for using CI/CD for external repos, including CI/CD for GitHub, until September 22nd, 2019</strong>. You’ll now have an additional six months to enjoy CI/CD for external repos as a Free or Bronze</a> user on GitLab.com. This feature will continue to be part of the Premium tier</a> for GitLab Self-managed.</p> Always free for open source</h2> This extension applies to private repos hosted on GitLab.com. As part of our commitement to open source, public projects get all the features of Gold for free</a>. GitLab CI/CD for GitHub works by automatically mirroring your repos to GitLab.com. As such, if you have a public project on GitHub, it will aslo be public on GitLab so you can always take advantage of GitLab CI/CD for public projects.</p> Why we're extending the offer</h2> In full transparency</a>, there are a few reasons we decided on an extension.</p> The first reason is that we didn’t want to ruin anyone’s day by shutting off functionality without fair warning. We don’t currently have all of the instrumentation in place to give us confidence that we can appropriately notify users, so we'll spend some time in the coming months to build this ability. We want to give ample opportunity for everyone currently enjoying the functionality on GitLab.com Free and Starter to make the choice to upgrade or migrate.</p> The second reason is the changing CI/CD market landscape. With recent developments — like the consolidation of the CI/CD market</a> and the launch of the Continuous Delivery Foundation</a> — we’ve seen greater interest in using GitLab CI/CD with other git hosting options. Extending the timeline will allow more folks to test it out.</p> Finally, we want to take this time to capture additional feedback on how you use this feature so we can improve it. If you are using GitLab CI/CD with any external git repository, like GitHub.com, GitHub Enterprise, BitBucket, or even your own vanilla Git server, we’d love to hear why you keep your code where you do, what you like about GitLab CI/CD, and what we can improve. We have several open channels for feedback so please leave a comment on this post, send us a message on Twitter with the hashtag #GitLabCICD, or log an issue with a bug fix or feature request on our open issue tracker</a>. We hope you enjoy an extra six months of usage and hope to hear from you soon.</p> GitLab Critical Security Release: 11.8.3 and 11.7.7 2019-03-20T00:00:00+00:00 Today we are releasing versions 11.8.3 and 11.7.7 for GitLab Community Edition (CE) and Enterprise Edition (EE).</p> These versions contain important security fixes, and we strongly recommend that all GitLab installations be upgraded to one of these versions immediately.</p> The vulnerability details will be made public on our issue tracker in approximately 30 days.</p> Please read on for more information regarding this release.</p> Project Runner Registration Token Exposed Through Issues Quick Actions</h2> GitLab issues quick actions were vulnerable to an information disclosure issue that disclosed project runner registration tokens to unauthorized users. The issue is now mitigated in the latest release and is assigned CVE-2019-9866</a>.</p> Thanks to @jobert</a> for responsibly reporting this vulnerability to us.</p> Versions Affected</h3> Affects GitLab CE/EE 11.4 and later.</p> Remediation</h3> We strongly recommend</strong> that all installations running an affected version above to be upgraded to the latest version as soon as possible.</p> Upgrade Mattermost to Version 5.6.5 in GitLab 11.7</h2> The Mattermost integration was updated to version 5.6.5 for the GitLab 11.7 package. Included in this Mattermost release are several security fixes.</p> Updating</h2> To update, check out our update page</a>.</p> Lessons from our journey to enable global code search with Elasticsearch on GitLab.com 2019-03-20T00:00:00+00:00 We're working hard to switch our search infrastructure on GitLab.com</a> to take advantage of our Elasticsearch integration</a>, which should allow us to improve global search and enable global code search for our users.</p> Enabling this integration on GitLab.com is important to us because it will unlock better search performance and allow us to improve the relevance of results for our GitLab.com users – something our self-hosted users have been able to take advantage of for a few years now. We've been working on this for a while, and have hit many dead ends and pitfalls which maybe you can learn from too.</p> Our plan</h2> We have two very important things that need to happen: we must reduce the Elasticsearch index size, and we must improve the administration of the Elasticsearch integration.</p> 1. Reduce index size</h2> Currently, the Elasticsearch index utilizes aproximately 66 percent of the space the repos use. This is our biggest blocker, as this is the bare minimum amount of space required – this number goes up when you consider the need for replicas.</p> We've attempted multiple things to get the index size down, but all of them resulted in minimal (or no) changes at all, so due to the complexity of implementing the changes we've decided to ignore them (at least for now).</p> Things we've tried</h3> Force merges</h4> When you delete a document from Elasticsearch, it doesn't actually free up space right away. Instead it does a soft delete, and Elasticsearch will release the space used in the future via an operation called a merge</a>.</p> In gitlab-org/gitlab-ee#7611</a> we investigated the possibility of forcing Elasticsearch to reclaim this space periodically via an operation called a forcemerge</a>. This seemed like a very worthwhile thing to investigate as an Elasticsearch index could theoretically grow up to 50 percent more due to these soft deletions. In the end though, we found out that a forcemerge</code> is a blocking call, and causes extreme performance degradation while it runs – not something you want in a production environment! Sadly we were forced to abandon this, but we did learn a bit more about how to tune Elasticsearch so merges are less painful, which we documented here</a>.</p> New blog posts directly to your inbox </div> Sign up for our bi-monthly newsletter </div> </div> Thanks, you’re signed up! </div> GitLab is coming to your inbox </div> </div> </div>

GitLab

An Update on Project Runner Registration Token Exposed Through Issues Quick Actions Vulnerability

GitLab 11.9 released with secrets detection and multiple MR approval rules

</i> </a> GitLab chart improvements </h3> CORE</div> </a> STARTER</div> </a> PREMIUM</div> </a> ULTIMATE</div> </a> </div> FREE</div> </a> BRONZE</div> </a> SILVER</div> </a> GOLD</div> </a> </div> </div> </div> The following improvements have been made to GitLab charts:</p>

</i> </a> Omnibus improvements </h3> CORE</div> </a> STARTER</div> </a> PREMIUM</div> </a> ULTIMATE</div> </a> </div> FREE</div> </a> BRONZE</div> </a> SILVER</div> </a> GOLD</div> </a> </div> </div> </div> The following improvements have been made to Omnibus in GitLab 11.9:</p>

</i> </a> GitLab chart improvements </h3> CORE</div> </a> STARTER</div> </a> PREMIUM</div> </a> ULTIMATE</div> </a> </div> FREE</div> </a> BRONZE</div> </a> SILVER</div> </a> GOLD</div> </a> </div> </div> </div> The following improvements have been made to GitLab charts:</p>

Extending free use of CI/CD for GitHub on GitLab.com

GitLab Critical Security Release: 11.8.3 and 11.7.7

Remediation</h3> We strongly recommend</strong> that all installations running an affected version above to be upgraded to the latest version as soon as possible.</p>

Lessons from our journey to enable global code search with Elasticsearch on GitLab.com

Things we've tried</h3>

Remediation</h3>
We strongly recommend</strong> that all installations running an affected version above to be upgraded to the latest version as soon as possible.</p>