GHSA-cqcc-mm6x-vmvw Persistent Cross-site Scripting vulnerability in PrivateBin

• Packagist privatebin/privatebin: >= 0.21, < 1.4.0 → fixed in 1.4.0

In PrivateBin alert(document.domain); ``` 2. Upload it as an attachment to a PrivateBin instance that has attachments enabled and hasn't set the recommended content security policy (in particular, one that has either no content security policy set or that allows `*` or `blob:` as a `script-src`). 3. Open the paste. (In a real attack scenario this would be done by the victim.) 4. The SVG is rendered safely as a preview, and script isn't yet executed. 5. Now (depending on your device) right-click or long tap on the image and open it in a new tab. 6. Now a `blob:` URI opens in a new tab with the image and the modal is shown, therefore the script got executed. Impact We tried to reproduce the vulnerability and in our assessment, we found out the following: 1. Any users who use our recommended _Content Security Policy_ (CSP), even older, less strict ones, are not affected by this vulnerability, if a CSP compatible browser is used. All the browsers we tested with did pass on the CSP to the new tab that is opened when viewing the SVG by itself. As PrivateBin ships with a built-in CSP, we consider this a strong defence in depth against these and related issues. That said, we think the CSP should only be the last layer of defence and as such, we decided to still apply further mitigations for this security issue. 2. Instances that do not have attachments enabled, are not affected. Even when attachments are uploaded using a third-party client, they can't be rendered when the administrator disables them (the HTML element that they would render in isn't present and before 1.4 this caused an error, we now catch the error and only display the paste text) and thus potential exploits in the attachment file do not apply. 3. The inline preview (step 4 above) does _not_ execute the script, because browsers explicitly restrict SVGs if the they are is embedded in an `img` tag to prevent such security issues in images. Thus, SVGs in `img` tags itself can be considered safe. However, when the user opens the SVG in a new tab, this browser security feature is circumvented. That's why the exploit steps above explain to open the SVG in a new tab. That being said, the impact of the vulnerability is reduced by two factors: 1. The attack explicitly requires user-interaction, i.e. the user has to be tricked into opening the preview in a new tab for some reason. This could realistically be achieved with some social engineering: The markdown formatted text part of the paste could include such an instruction as a big, bold title, or the SVG could be very large and have very small text, which the user might want to zoom into, in order to read. 2. Potential exploit code can only run in a new tab. It still has the same origin (as can be seen in the PoC above, because the domain/origin the script is running on, is shown). However, though, sensitive information like the paste content, potential comments or encryption key (in the URL) is not accessible to the attacker as the context is now a blob-URL – and would anyway consist mostly of things the attacker initially created itself. That said, the same origin policy applies and thus, what an attacker could do is read e.g. cookies and local storage data saved in the same origin. As PrivateBin itself does not use any of that, the impact of this vulnerability is limited. However, as PrivateBin is a software for self-hosting, it cannot be excluded that other services run in the same origin (e.g. on the same domain). That's why server administrators may need to evaluate the impact of running arbitrary JavaScript code on their domain/origin where PrivateBin is hosted by themselves. To summarize, this shows a fairly limited impact, given even if the CSP had not caught the issue, the user still needs to interact with the page and the exploit code cannot access or exfiltrate any data of the PrivateBin instance. Note: However, take our assessment only as a basis for your own assessment. As explained, depending on your environment, the actual risk may vary if you are hosting other services on the same domain as PrivateBin. As for the metrics, the impact assessment we have done with CVSS v3.1 results in this: AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N/E:F/RL:U/RC:C/CR:X/IR:X/AR:X/MAV:N/MAC:L/MPR:N/MUI:R/MS:U/MC:X/MI:X/MA:X Real-life impact We found two affected instances in our instance lists (wiki, directory) that did not serve a correct Content Security Policy header, had attachments enabled and thus are vulnerable to this attack. We didn't manage to get into contact with the administrators of these sites, though. In addition to that, we found that multiple instances do seem to either strip our CSP or have it changed to an unsafe setting and have thus expanded our directory service to verify whether our recommend CSP is used or not. (see below) We have no reports that indicate this vulnerability was or is being actively exploited at the time of this report. Patches To fix the problem, we took the following measures (in no particular order): • We apply DOMpurify (a library we already use to sanitize user-submitted HTML via the Markdown format) to the SVG preview, too. It strips script tags and other uncommon security-relevant and potentially malicious tags/properties from the SVG file. So whether you open the SVG in a new tab or not and whether CSP is present and enabled or not does not matter any more, as the displayed SVG is sanitized. • As a further defence in depth mechanism we now send the CSP both as an HTTP header, as well as a meta tag. This protects instance with mis-configured web servers, CDNs, proxy or similar, from stripping or breaking the CSP headers, as they still get the CSP inside of the HTML content itself. Please note though, that the [meta tag approach is not as strong as the HTTP he…