Bugzilla – Bug 1197930
VUL-0: CVE-2022-21948: paste: XSS on the image upload function
Last modified: 2023-01-02 08:50:24 UTC
I would like to request a CVE for the paste https://github.com/openSUSE/paste An attacker could upload a crafted SVG file and trigger a javascript execution. a PoC cann be found here: https://paste.opensuse.org/images/25863829.svg The source code used in the PoC: ``` <?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("xss"); </script> </svg> ``` Please note that, because of missing security flags in the tokens, the script is able to access the user access token. Therefore an attack could weaponize this script to gain access to other resources protected behind the same OpenID/IDP.
Actually the upstream of paste lives here: https://github.com/openSUSE/paste. The Stikked was forked into paste. The issue was introduced by SUSE, probably in the commit https://github.com/openSUSE/paste/commit/cfc881f91bf34c2b96878945dbca394c93361f2e, so Stikked isn't affected by this issue, just the paste code offered by openSUSE official git. IMO, that's kind of the same relationship between ImageMagick and GraphicsMagick. We can see in the git log, that SUSE employees still pushing changes to the git repository and we still have this service up and running in our infrastructure, connected to our IDP. so I guess we can find the "maintainers" and we should definitely assign a CVE for that, otherwise at least disable the service and drop the package from github? We definitely have an internal instance, running by infra. Strange that now, http://paste.suse.de/ leads me to our internal CA. How should we proceed?
it used to have its own "roadmap" of features https://michal.hrusecky.net/2010/08/opensuse-paste-update/
As it is a hosted app by us, CVE assignment guidance is mixed. and it might not get a CVE. it seems unlikely it is used by others too. It still needs to be fixed.
> As it is a hosted app by us, CVE assignment guidance is mixed. and it might not > get a CVE. Why shouldn't it get a CVE? An attacker could paste a link to the XSS page in any openSUSE platform and retrieve the session token that could be use in any other tool behind the same openID. For example, Adding the captured session token I was able to login in the forums.opensuse.org. In my evaluation, it would be a critical vulnerability based on CVSS scoring system https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N/E:F/RL:U/RC:C I don't think we can measure where any of our open source projects hosted on github are being used, right?
Please use CVE-2022-21948 for this
Hi Jonas, would you like to take over this finding and write a patch for that? We currently have no maintainer for this repo [0], and most of the people who previously collaborated on it [1] are no longer part of SUSE. I know your contribution [1] was a small change, but maybe you're willing to help here. [0] https://github.com/openSUSE/paste [1] https://github.com/openSUSE/paste/graphs/contributors [2] https://github.com/openSUSE/paste/commit/3e013c22eb640b4e00e80bb979dd3c7cf19e5af7
I spoke with Jonas, and he's not able to take care of it. Do you know anyone with PHP skills that could be helpful here?
I opened https://github.com/openSUSE/paste/issues/15 in hope that this sees some activity. Internal CRD: 2023-01-02 or earlier
This is __not__ hosted by SUSE, it is hosted by miska, who as far as I know doesn't work for SUSE anymore. I wouldn't hold my breath for this getting fixed either, it's probably much more likely it will be taken down without a replacement. The issue for replacing it has been open on https://progress.opensuse.org/issues/15276 for over 6 years at this point
It is in the openSUSE orga and we use it within SUSE. I'll file a request to get it taken down
paste.opensuse.org now uses a different codebase
thanks, then we close this for us and just track it upstream