CVE-2022-24833

PrivateBin is minimalist, open source online pastebin clone where the server has zero knowledge of pasted data. In PrivateBin < v1.4.0 a cross-site scripting (XSS) vulnerability was found. The vulnerability is present in all versions from v0.21 of the project, which was at the time still called ZeroBin. The issue is caused by the fact that SVGs can contain JavaScript. This can allow an attacker to execute code, if the user opens a paste with a specifically crafted SVG attachment, and interacts with the preview image and the instance isn't protected by an appropriate content security policy. Users are advised to either upgrade to version 1.4.0 or to ensure the content security policy of their instance is set correctly.

PrivateBin is minimalist, open source online pastebin clone where the server has zero knowledge of pasted data. In PrivateBin < v1.4.0 a cross-site scripting (XSS) vulnerability was found. The vulnerability is present in all versions from v0.21 of the project, which was at the time still called ZeroBin. The issue is caused by the fact that SVGs can contain JavaScript. This can allow an attacker to execute code, if the user opens a paste with a specifically crafted SVG attachment, and interacts with the preview image and the instance isn't protected by an appropriate content security policy. Users are advised to either upgrade to version 1.4.0 or to ensure the content security policy of their instance is set correctly.

In PrivateBin < v1.4.0 a cross-site scripting (XSS) vulnerability was found. The vulnerability is present since attachments with image preview got introduced in v0.21 of the project, which was at the time still called ZeroBin. The issue is caused by the fact that SVGs can contain JavaScript. This can allow an attacker to execute code, if the user opens a paste with a specifically crafted SVG attachment, and interacts with the preview image and the instance isn't protected by an appropriate content security policy.

As a consequence, we have mitigated the vulnerability in the preview and urge server administrators to either upgrade to a version with the fix or to ensure the content security policy of their instance is set correctly, ideally both. Additionally, we expanded our directory listing tool with a checking mechanism and highly suggest server administrators to check their instance there and, should there be a warning regarding the content security policy adjust the CSP to our suggested one, as it is shown in the configuration preset.

Proof of concept

The vulnerability can be triggered as following:

1. Create the following SVG as a file:

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">

<svg version="1.1" baseProfile="full" xmlns="http://www.w3.org/2000/svg">
 <polygon id="triangle" points="0,0 0,50 50,0" fill="#009900" stroke="#004400"/>
 <script type="text/javascript">
   alert(document.domain);
 </script>
</svg>

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…

PrivateBin is minimalist, open source online pastebin clone where the server has zero knowledge of pasted data. In PrivateBin < v1.4.0 a cross-site scripting (XSS) vulnerability was found. The vulnerability is present in all versions from v0.21 of the project, which was at the time still called ZeroBin. The issue is caused by the fact that SVGs can contain JavaScript. This can allow an attacker to execute code, if the user opens a paste with a specifically crafted SVG attachment, and interacts with the preview image and the instance isn't protected by an appropriate content security policy. Users are advised to either upgrade to version 1.4.0 or to ensure the content security policy of their instance is set correctly.

PrivateBin is minimalist, open source online pastebin clone where the server has zero knowledge of pasted data. In PrivateBin < v1.4.0 a cross-site scripting (XSS) vulnerability was found. The vulnerability is present in all versions from v0.21 of the project, which was at the time still called ZeroBin. The issue is caused by the fact that SVGs can contain JavaScript. This can allow an attacker to execute code, if the user opens a paste with a specifically crafted SVG attachment, and interacts with the preview image and the instance isn't protected by an appropriate content security policy. Users are advised to either upgrade to version 1.4.0 or to ensure the content security policy of their instance is set correctly.

In PrivateBin < v1.4.0 a cross-site scripting (XSS) vulnerability was found. The vulnerability is present since attachments with image preview got introduced in v0.21 of the project, which was at the time still called ZeroBin. The issue is caused by the fact that SVGs can contain JavaScript. This can allow an attacker to execute code, if the user opens a paste with a specifically crafted SVG attachment, and interacts with the preview image and the instance isn't protected by an appropriate content security policy.

As a consequence, we have mitigated the vulnerability in the preview and urge server administrators to either upgrade to a version with the fix or to ensure the content security policy of their instance is set correctly, ideally both. Additionally, we expanded our directory listing tool with a checking mechanism and highly suggest server administrators to check their instance there and, should there be a warning regarding the content security policy adjust the CSP to our suggested one, as it is shown in the configuration preset.

Proof of concept

The vulnerability can be triggered as following:

1. Create the following SVG as a file:

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">

<svg version="1.1" baseProfile="full" xmlns="http://www.w3.org/2000/svg">
 <polygon id="triangle" points="0,0 0,50 50,0" fill="#009900" stroke="#004400"/>
 <script type="text/javascript">
   alert(document.domain);
 </script>
</svg>

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…