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

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

I just reported the following findings to upstream:

1.1) /tmp/shufflerapplettrigger_<user>
--------------------------------------

In "src/shuffler_control.vala" line 1740 first an attempt is made to
delete this path. Then it starts monitoring the path, reacting to its
creation, by automatically selecting (popping up) the "Applet" listbox
GUI entry.

The counterpart to this is found in "applet/src/ShufflerApplet.vala"
line 91, where this file is created to let the settings open.

The worst that can happen here is likely confusing the victims GUI so it
is low severity.

1.2) /tmp/<user>_shufflertriggers/layoutspopup
----------------------------------------------

In "src/toggle_layouts_popup.vala" line 62 first an attempt is made to
create the directory, ignoring any potential errors - considering it to
already exist. Then the "layoutspopup" file is created within the
directory. Depending on program evaluation logic the string
"fromcontrol" is written to the file, otherwise the file remains empty.

In "src/layouts_popup.vala" line 1384 monitoring for this file is setup,
its content is read (it is checked whether it is "fromcontrol") and then
a popup window is either created or destroyed, depending on the current
program state.

Another user in the system can pre-create this directory and then
control the creation and destruction of the popup dialog, thereby
confusing the victim's GUI. By placing a FIFO instead of a regular file
at "layoutspopup", the layouts popup will be subject to denial-of-service
(either by blocking it indefinitely or by feeding it large amounts of
data, leading to an out-of-memory situation).

Without the Linux kernel's symlink protection it can be used to make
`layouts_popup` program read from arbitrary files, or to operate in
arbitrary directories.

1.3) /tmp/<user>_running_layout
-------------------------------

In "src/run_layout.vala" line 203 this file is created to "temporarily
disable possibly set windowrules". In line 379 this path is (needlessly)
constructed again and passed to function `create_busyfile()`, although
this parameter remains unused by the function. In line 478 `stat()` and
`unlink()` are attempted on the file.

In "src/windowshufflerdaemon.vala" line 831 an existence check for this
file is made. If it exists then the `run_rule` program will not be
executed for any windows.

This paths allows a local attacker to prevent the victim's `run_rule`
ever to be executed.

1.4) /tmp/<user>_gridtrigger
----------------------------

In "src/togglegui.vala" line 33 an existence check is made for this path
and depending on the outcome it is either created as an empty file, or
deleted.

In "src/windowshufflerdaemon.vala" line 992 in function `actonfile()`
there is a reaction to the creation and deletion of this path. Depending
on this the `gridguiruns` boolean is set to true or false respectively.
If it is set to `false` then a window will be destroyed in 1148.

In "src/gridwindow.vala" line 637 a monitor is setup for this file and
depending on it being created or being deleted the `gridwindow` is being
displayed or destroyed.

This path basically allows a local attacker to make the "grid window"
managed by the `gridwindow` program appear, thereby confusing the
victim's GUI. The other way around `windowshufflerdaemon` can be
caused to destroy its "preview window" if this state file is under a
local attacker's control.

1.5) /tmp/shuffler-warning.png
------------------------------

In "src/windowshufflerdaemon.vala" line 1017 in function
`create_warningbg()` this path is used to write a programmatically
created PNG image to. In function `show_awarning()` in line 338 the
program `sizeexceeds_warning` is executed which in turn in
"src/sizeexceeds_warning.vala" line 68 uses this path to display the
generated PNG image on the desktop.

A local attacker can attempt to place arbitrary PNG data in this path
and have it displayed on the victim's desktop.

Since this path is really only used to pass data from
`windowshufflerdaemon` to `sizeeexceeds_warning`, a proper unpredictable
temporary file should be used for this. This would also fix the deletion
of this file, which currently doesn't seem to be taken care of.

1.6) /tmp/<user>_istestingtask
------------------------------

This path is potentially created in "src/layouts_popup.vala" line 492.
The file receives data from the GUI interface. In "src/run_layout.vala"
line 407 this path is picked up again and its content interpreted in
`extractlayout_fromfile()`.

Since this file's content is evaluated and used for further program
logic there is a chance for a local attacker to massively break the
`run_layout` program's logic or maybe even achieve code execution. The
Linux kernel's protected_regular sysctl setting comes to the rescue
here, though. The `open()` with `O_CREAT` will fail. It can then
still present a denial-of-service vector, though.

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

(In reply to Matthias Gerstner from comment #5)
> 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

Yep - all standard procedure - keep me updated
On holiday until 25th Oct but will accept SRs if needed in meantime

Callum

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 871128 [details]
upstream patch

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

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 (1213342) was mentioned in
https://build.opensuse.org/request/show/1133097 Factory / budgie-extras

complete