Security Advisory #UP1-1

[andre-d]

Today one of our developers noticed that it was possible to execute user-provided JavaScript within the application's origin by uploading an SVG and having a user press the "View In Browser" button. We do not have reason to believe this was exploited in the wild, however, as a precaution we are notifying our users and third party application users.

It is possible to use such a vulnerability to both execute JavaScript code on the up1 origin as well as potentially leak the IP address or browser info of the visitor in question to a third party by image embeds, XHR requests, etc. If you have clicked "View In Browser" on any SVG files (by MIME type, not by file name) from untrusted sources and have local storage enabled we suggest that you consider your deletion keys for any files you had saved to be compromised along with a list of any files you have uploaded by ident. The keys to decrypt the individual idents available in local storage were not stored in local storage and we do not suspect them as being available to leak via this vulnerability. If you do not have local storage enabled this vulnerability could not reveal much as the client does not store state beyond the deletion keys by ident, however, by the nature of same origin policies in browsers you should consider this advisory as best as possible.

We have resolved this issue by treating the "View In Browser" of an SVG as text. Additionally, we have required that all files being embedded or with a "View In Browser" button claim to be of a specific white-listed MIME type. We do this to avoid file formats like M3U playlists which would possibly leak IP addresses when viewing the embedded audio element in browsers such as Safari. We are depending on the security of modern browsers to not allow these unsafe types to be provided with an incorrect MIME type. We believe keeping a blacklist for specific untrustworthy MIME types to be insecure by the nature of the variety of formats browsers may support now or in the future and therefore have gone with the whitelist approach.

If you spot any MIME types or file formats we have missed please feel free to submit an issue and we will add them to the whitelist, the whitelist is an unfortunate consequence of the required security due to the nature of client side encrypted hosts embedding documents directly.

If you are an application hoster we recommend you update to version v0.3.1 immediately.

[joepie91]

Was a CVE assigned for this?

[andre-d]

No CVE was assigned to this vulnerability.

On Aug 28, 2016 6:08 AM, "Sven Slootweg" notifications@github.com wrote:

Was a CVE assigned for this?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#48 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AArlsgDqN7WXnBFaf66qr9ihLyA13vSZks5qkV4ygaJpZM4HRJGy
.

[k3d3]

Since this is over 4 years old, I'm going to close this ticket.