Date: Tue, 30 May 2017 13:21:27 +0000 (UTC) From: Torsten Zuehlsdorff <tz@FreeBSD.org> To: ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org Subject: svn commit: r442062 - head/security/vuxml Message-ID: <201705301321.v4UDLRAP009898@repo.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: tz Date: Tue May 30 13:21:27 2017 New Revision: 442062 URL: https://svnweb.freebsd.org/changeset/ports/442062 Log: Modify GitLab entries: - wrap long lines - add missing modfied Modified: head/security/vuxml/vuln.xml Modified: head/security/vuxml/vuln.xml ============================================================================== --- head/security/vuxml/vuln.xml Tue May 30 13:20:13 2017 (r442061) +++ head/security/vuxml/vuln.xml Tue May 30 13:21:27 2017 (r442062) @@ -680,25 +680,57 @@ Notes: <body xmlns="http://www.w3.org/1999/xhtml">; <p>GitLab reports:</p> <blockquote cite="https://about.gitlab.com/2017/05/08/gitlab-9-dot-1-dot-3-security-release/">; - <h1>Cross-Site Scripting (XSS) vulnerability in project import file names for gitlab_project import types</h1> - <p>Timo Schmid from ERNW reported a persistent Cross-Site Scripting vulnerability in the new project import view for gitlab_project import types. This XSS vulnerability was caused by the use of Hamlit filters inside HAML views without manually escaping HTML. Unlike content outside of a filter, content inside Hamlit filters (:css, :javascript, :preserve, :plain) is not automatically escaped.</p> + <h1>Cross-Site Scripting (XSS) vulnerability in project import file names + for gitlab_project import types</h1> + <p>Timo Schmid from ERNW reported a persistent Cross-Site Scripting + vulnerability in the new project import view for gitlab_project import + types. This XSS vulnerability was caused by the use of Hamlit filters inside + HAML views without manually escaping HTML. Unlike content outside of a + filter, content inside Hamlit filters (:css, :javascript, :preserve, :plain) + is not automatically escaped.</p> <h1>Cross-Site Scripting (XSS) vulnerability in git submodule support</h1> - <p>Jobert Abma from HackerOne reported a persitent XSS vulnerability in the GitLab repository files view that could be exploited by injecting malicious script into a git submodule.</p> - <h1>Cross-Site Scripting (XSS) vulnerability in repository "new branch" view</h1> - <p>A GitLab user reported a persistent XSS vulnerability in the repository new branch view that allowed malicious branch names or git references to execute arbitrary Javascript.</p> + <p>Jobert Abma from HackerOne reported a persitent XSS vulnerability in the + GitLab repository files view that could be exploited by injecting malicious + script into a git submodule.</p> + <h1>Cross-Site Scripting (XSS) vulnerability in repository "new branch" + view</h1> + <p>A GitLab user reported a persistent XSS vulnerability in the repository + new branch view that allowed malicious branch names or git references to + execute arbitrary Javascript.</p> <h1>Cross-Site Scripting (XSS) vulnerability in mirror errors display</h1> - <p>While investigating Timo Schmid's previously reported XSS vulnerability in import filenames another persistent XSS vulnerability was discovered in the GitLab Enterprise Edition's (EE) mirror view. This vulnerability was also caused by the misuse of Hamlit filters.</p> + <p>While investigating Timo Schmid's previously reported XSS vulnerability + in import filenames another persistent XSS vulnerability was discovered in + the GitLab Enterprise Edition's (EE) mirror view. This vulnerability was + also caused by the misuse of Hamlit filters.</p> <h1>Potential XSS vulnerability in DropLab</h1> - <p>An internal code audit disclosed a vulnerability in DropLab's templating that, while not currently exploitable, could become exploitable depending on how the templates were used in the future.</p> - <h1>Tab Nabbing vulnerabilities in mardown link filter, Asciidoc files, and other markup files</h1> - <p>edio via HackerOne reported two tab nabbing vulnerabilities. The first tab nabbing vulnerability was caused by improper hostname filtering when identifying user-supplied external links. GitLab did not properly filter usernames from the URL. An attacker could construct a specially crafted link including a username to bypass GitLab's external link filter. This allowed an attacker to post links in Markdown that did not include the appropriate "noreferrer noopener" options, allowing tab nabbing attacks.</p> - <p>The second vulnerability was in the AsciiDoctor markup library. AsciiDoctor was not properly including the "noreferrer noopener" options with external links. An internal investigation discovered other markup libraries that were also vulnerable.</p> + <p>An internal code audit disclosed a vulnerability in DropLab's templating + that, while not currently exploitable, could become exploitable depending on + how the templates were used in the future.</p> + <h1>Tab Nabbing vulnerabilities in mardown link filter, Asciidoc files, and + other markup files</h1> + <p>edio via HackerOne reported two tab nabbing vulnerabilities. The first + tab nabbing vulnerability was caused by improper hostname filtering when + identifying user-supplied external links. GitLab did not properly filter + usernames from the URL. An attacker could construct a specially crafted link + including a username to bypass GitLab's external link filter. This allowed + an attacker to post links in Markdown that did not include the appropriate + "noreferrer noopener" options, allowing tab nabbing attacks.</p> + <p>The second vulnerability was in the AsciiDoctor markup + library. AsciiDoctor was not properly including the "noreferrer noopener" + options with external links. An internal investigation discovered other + markup libraries that were also vulnerable.</p> <h1>Unauthorized disclosure of wiki pages in search</h1> - <p>M. Hasbini reported a flaw in the project search feature that allowed authenticated users to disclose the contents of private wiki pages inside public projects.</p> + <p>M. Hasbini reported a flaw in the project search feature that allowed + authenticated users to disclose the contents of private wiki pages inside + public projects.</p> <h1>External users can view internal snippets</h1> - <p>Christian Kühn discovered a vulnerability in GitLab snippets that allowed an external user to view the contents of internal snippets.</p> - <h1>Subgroup visibility for private subgroups under a public parent group</h1> - <p>Matt Harrison discovered a vulnerability with subgroups that allowed private subgroup names to be disclosed when they belong to a parent group that is public.</p> + <p>Christian Kühn discovered a vulnerability in GitLab snippets that allowed + an external user to view the contents of internal snippets.</p> + <h1>Subgroup visibility for private subgroups under a public parent + group</h1> + <p>Matt Harrison discovered a vulnerability with subgroups that allowed + private subgroup names to be disclosed when they belong to a parent group + that is public.</p> </blockquote> </body> </description> @@ -708,6 +740,7 @@ Notes: <dates> <discovery>2017-05-08</discovery> <entry>2017-05-18</entry> + <modified>2017-05-30</modified> </dates> </vuln> @@ -726,23 +759,41 @@ Notes: <p>GitLab reports:</p> <blockquote cite="https://about.gitlab.com/2017/03/20/gitlab-8-dot-17-dot-4-security-release/">; <h1>Information Disclosure in Issue and Merge Request Trackers</h1> - <p>During an internal code review a critical vulnerability in the GitLab Issue and Merge Request trackers was discovered. This vulnerability could allow a user with access to assign ownership of an issue or merge request to another user to disclose that user's private token, email token, email address, and encrypted OTP secret. Reporter-level access to a GitLab project is required to exploit this flaw.</p> + <p>During an internal code review a critical vulnerability in the GitLab + Issue and Merge Request trackers was discovered. This vulnerability could + allow a user with access to assign ownership of an issue or merge request to + another user to disclose that user's private token, email token, email + address, and encrypted OTP secret. Reporter-level access to a GitLab project + is required to exploit this flaw.</p> <h1>SSRF when importing a project from a Repo by URL</h1> - <p>GitLab instances that have enabled project imports using "Repo by URL" were vulnerable to Server-Side Request Forgery attacks. By specifying a project import URL of localhost an attacker could target services that are bound to the local interface of the server. These services often do not require authentication. Depending on the service an attacker might be able craft an attack using the project import request URL.</p> + <p>GitLab instances that have enabled project imports using "Repo by URL" + were vulnerable to Server-Side Request Forgery attacks. By specifying a + project import URL of localhost an attacker could target services that are + bound to the local interface of the server. These services often do not + require authentication. Depending on the service an attacker might be able + craft an attack using the project import request URL.</p> <h1>Links in Environments tab vulnerable to tabnabbing</h1> - <p>edio via HackerOne reported that user-configured Environment links include target=_blank but do not also include rel: noopener noreferrer. Anyone clicking on these links may therefore be subjected to tabnabbing attacks where a link back to the requesting page is maintained and can be manipulated by the target server.</p> - <h1>Accounts with email set to "Do not show on profile" have addresses exposed in public atom feed</h1> - <p>Several GitLab users reported that even with "Do not show on profile" configured for their email addresses those addresses were still being leaked in Atom feeds if they commented on a public project.</p> + <p>edio via HackerOne reported that user-configured Environment links + include target=_blank but do not also include rel: noopener + noreferrer. Anyone clicking on these links may therefore be subjected to + tabnabbing attacks where a link back to the requesting page is maintained + and can be manipulated by the target server.</p> + <h1>Accounts with email set to "Do not show on profile" have addresses + exposed in public atom feed</h1> + <p>Several GitLab users reported that even with "Do not show on profile" + configured for their email addresses those addresses were still being leaked + in Atom feeds if they commented on a public project.</p> </blockquote> </body> </description> <references> - <url>https://about.gitlab.com/2017/03/20/gitlab-8-dot-17-dot-4-security-release/</url>; <cvename>CVE-2017-0882</cvename> + <url>https://about.gitlab.com/2017/03/20/gitlab-8-dot-17-dot-4-security-release/</url>; </references> <dates> <discovery>2017-03-20</discovery> <entry>2017-05-18</entry> + <modified>2017-05-30</modified> </dates> </vuln> @@ -8947,6 +8998,7 @@ Notes: <dates> <discovery>2016-11-02</discovery> <entry>2016-11-09</entry> + <modified>2017-05-18</modified> </dates> </vuln>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201705301321.v4UDLRAP009898>