I will work on reporting all the budgies-extra bugs to upstream

I just reported the following findings in the budgie-wpreviews component which
is part of budgie-extras:

2.1) /tmp/<user>_window-previews
--------------------------------

This path is used for a directory. In "src/separate_shot.vala" line 43
it is created, errors are ignored. In line 105 screenshots of certain
X11 windows are placed in the directory following the name scheme
"<window-id>.<workspace-name>.png".

In "src/previews_creator.vala" line 74 an attempt to create the
directory the same way is found. In line 241 the directory is iterated
over and each file found there, independently of its name, will be
assembled in a file list. This file list is luckily only used for
removing files of non-existant windows in this program.

In "src/previews_daemon.vala" line 719 there is another attempt to
create the directory the same way as in the other two locations. In line
523 again the directory is iterated over and a list of the contained
filenames is assembled, independently of their names. In line 404 the
filenames are interpreted and split into X11 window IDs and workspace
names again. It seems the code expects all filenames to match the
pattern, if this is not the case then the program will likely crash. The
resulting file list is (luckily) matched against the existing X11 window
IDs in line 421.

Even without exploiting the fixed temporary directory path this
directory has security issues, since it is created world-readable. Any
other users in the system can access the window screenshots that are
created there and thus this is an information leak.

Since all errors trying to create the directory are ignored, another
local user can pre-create this directory world-writable, and the
wpreviews applications will still use the directory which is now under
attacker control. The attacker can place additional PNG image files
there, trying to confuse the victim's GUI experience. A local DoS
against the `previews_daemon` seems also possible by placing
non-conforming files into the directory. Since the `previews_daemon`
only uses files from the directory for which an existing X11 window is
found, the complexity for a local attacker to inject arbitrary PNG files
into the preview logic is raised. It can still be possible by observing
the PNG files created by e.g. the `separate_shot` program and replacing
them with crafted data.

Without the Linux kernel's symlink protection a local attacker can place
a symlink there instead of a directory, causing the programs to operate
in arbitrary other directory locations.

2.2) /tmp/<user>_prvtrigger_*, /tmp/<user>_previoustrigger, /tmp/<user>_nexttrigger
-----------------------------------------------------------------------------------

This long list of trigger files:

    /tmp/<user>_prvtrigger_all
    /tmp/<user>_prvtrigger_current
    /tmp/<user>_prvtrigger_all_hotcorner
    /tmp/<user>_prvtrigger_curr_hotcorner
    /tmp/<user>_previoustrigger
    /tmp/<user>_prvtrigger_all
    /tmp/<user>_nexttrigger

is used both in "src/previews_triggers.vala" line 43 and
"src/previews_daemon.vala" line 664.

The `previews_triggers` program selects one of these trigger paths
depending on command line arguments, various logical evaluations and
depending on whether some of the paths already exist. The selected path
is then simply created with empty content.

In `previews_daemon` these paths are monitored and their existence is
evaluated in a complex fashion to display previews of existing windows.

In conjunction with the issues in 2.1) this can be used to display
attacker controlled images on the victim's screen at arbitrary times,
provided that the victim user is running the `previews_daemon`.

Apart from the security related problems this group of files for
controlling a daemons behaviour seems ill devised. Instead proper IPC
mechanisms should be used.

Please treat this information privately until we hear back from upstream. This means also not submitting anything about this in OBS for the time being.

This is an embargoed bug. This means that this information is not public.

Please do NOT:
- talk to other people about this unless they're involved in fixing the issue
- make this bug public
- submit this into OBS (e.g. fix Leap/Tumbleweed) until this bug becomes
  public. This means that the security team removed the EMBARGOED tag from
  the bug title after we verified that there's already information about
  this bug publicly available. If you find such information yourself and
  the bug is still embargoed please contact us

Your primary responsibility is to apply a fix for this issue.
Here is some guidance on openSUSE package maintenance:
- https://en.opensuse.org/openSUSE:Package_maintenance
- https://en.opensuse.org/openSUSE:Maintenance_update_process

You need to submit AFTER the bug became public, to the current openSUSE
Leap codestreams, and to the devel project of your package.

The security team will then take the following steps:
- We wait for your submission and package them into an incident for QA
  testing. The QA tester might reach out to you if they find issues with
  the update.
- If QA doesn't find any issues, we publish the updates.

You can contact us at:

* IRC: irc.suse.de #security
* Do NOT use Slack or any non-SUSE hosted messaging services
* Email: security-team@suse.de

*** Bug 1213672 has been marked as a duplicate of this bug. ***

Upstream agrees to follow coordinates disclosure and they aim to release an update by the end of the year. I will update once there is a more concrete date or patches available.

We got this CVE communicated by upstream, the fix will be in release 1.7.1,
but I don't have a publication date yet.

Created attachment 871127 [details]
upstream patch

Upstream plans to publish the release 1.7.1 on the date mentioned in comment
9. Their suggested patch is found in comment 10.

Please *don't* publish anything in the build service before we give green
light. You can privately prepare an update using the given patch but it will
likely be simpler to simply use the upstream release once it is public.

This is now public via the 1.7.1 upstream release: https://github.com/UbuntuBudgie/budgie-extras/releases/tag/v1.7.1. Please package the new version and submit to all maintained OBS codestreams.

This is an autogenerated message for OBS integration:
This bug (1213341) was mentioned in
https://build.opensuse.org/request/show/1133097 Factory / budgie-extras

complete