Thank you Zombie for the notice.
---
I have looked for duplicates, found none.
This package has no registered maintainer. Assigning to DavidG as you did something with it fairly recently.

Source RPM: vino => vino-3.22.0-3.mga7.src.rpm
Component: RPM Packages => Security
Assignee: bugsquad => geiger.david68210
QA Contact: (none) => security

Actual link:
https://www.debian.org/lts/security/2019/dla-2014

These are libvncserver issues....

CVE-2014-6053: Bug 14155
CVE-2018-7225: Bug 22847
CVE-2019-15681: new

However, vino doesn't appear to be built against the system library, so that should be fixed if possible.

Version: 7 => Cauldron
Whiteboard: (none) => MGA7TOO
Summary: vino security update CVE-2014-6053 CVE-2018-7225 CVE-2019-15681 => vino new security issues CVE-2014-6053, CVE-2018-7225, CVE-2019-15681

CVE-2019-15681 filed as Bug 25788.

Summary: vino new security issues CVE-2014-6053, CVE-2018-7225, CVE-2019-15681 => vino new security issues CVE-2014-6053, CVE-2018-7225, CVE-2019-15681 due to bundled libvncserver

CVE-2019-15690 would also affect this (see Bug 25918).

SUSE has issued an advisory for CVE-2019-15681 in vino on April 8:
http://lists.suse.com/pipermail/sle-security-updates/2020-April/006688.html

CC: (none) => luigiwalser

Done for both Cauldron and mga7!

(In reply to David Walser from comment #4)
> CVE-2019-15690 would also affect this (see Bug 25918).

Actually that affected libvncclient code, but vino only bundles libvncserver, so vino is not affected by that one.

Advisory:
========================

Updated vino packages fix security vulnerabilities:

The rfbProcessClientNormalMessage function in libvncserver/rfbserver.c in
LibVNCServer did not properly handle attempts to send a large amount of
ClientCutText data, which allowed remote attackers to cause a denial of service
(memory consumption or daemon crash) via a crafted message that was processed
by using a single unchecked malloc (CVE-2014-6053).

An issue was discovered in LibVNCServer. rfbProcessClientNormalMessage() in
rfbserver.c did not sanitize msg.cct.length, leading to access to uninitialized
and potentially sensitive data or possibly unspecified other impact (e.g., an
integer overflow) via specially crafted VNC packets (CVE-2018-7225).

LibVNC contained a memory leak in VNC server code, which allowed an attacker to
read stack memory and could be abused for information disclosure. Combined with
another vulnerability, it could be used to leak stack memory and bypass ASLR.
This attack appeared to be exploitable via network connectivity
(CVE-2019-15681).

The bundled libvncserver code in vino has been patched to fix these issues.

References:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6053
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-7225
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-15681
https://www.debian.org/lts/security/2019/dla-2014
========================

Updated packages in core/updates_testing:
========================
vino-3.22.0-3.1.mga7

from vino-3.22.0-3.1.mga7.src.rpm

Version: Cauldron => 7
Whiteboard: MGA7TOO => (none)
Assignee: geiger.david68210 => qa-bugs
CC: (none) => geiger.david68210

MGA7-64 Plasma on Lenovo B50
No installation issues.
Found some info in bug 8782, but first hurdle: the command vino-preferences is not in our package.
Googled and found http://www.softpanorama.org/Xwindows/VNC/Vino/activating_vino_from_command_line.shtml
but this also refers to that command.
Further quoting from it: "Vino is the default VNC server in Gnome which provides the capability to view Gnome desktop via VNC client."
I have no Gnome on thisor any other machine, and I won't touch it ever, not even with a poole (tried it once and no more)
It installed cleanly, that's all I can say on the update.

CC: (none) => herman.viaene

According to https://askubuntu.com/questions/416353/where-is-vino-preferences-gone-in-xubuntu-13-10-sharing-desktop-in-xubuntu-1
vino-preferences has been placed in GNOME desktop settings.
Using the dconf editor in Mate the settings can be accessed in this path:
org / gnome / desktop / remote-access
That gives you:
org.gnome.Vino with various settings.

systemd does not seem to know vino-server but it can be launched like so:
$ sudo /usr/libexec/vino-server

Personally I do not feel comfortable with any of this so this is FYI only.

CC: (none) => tarazed25

Completely out of my element here, so I don't know anything about how to test this, or how to address the questions brought up in Comment 9 and Comment 10. 

However, I just validated Bug 26587, concerning libvncserver1.

Does that affect this bug at all? The suggested advisory says that the bundled vncserver code has been patched. Do the changes in libvncserver1 from Bug 26587 need to be added here, too?

Keywords: (none) => feedback
CC: (none) => andrewsfarm

No, Comment 7 applies.

Keywords: feedback => (none)

Agreeing with comment 11 here.  Out of my depth.

All that can be said is that vino-preferences can be accessed via dconf-editor and that the vino-server can be launched and listens on port 5900 but how you tickle it is beyond my understanding.  Where and what is the vino client in all this?

On the server side:
$ netstat -nl | grep 5900
tcp        0      0 0.0.0.0:5900            0.0.0.0:*               LISTEN     
tcp6       0      0 :::5900                 :::*                    LISTEN     

So that is fine.  vino is waiting for somebody to send it a message via :5900 and it then needs to find someone to give it to.  How is that defined?

Verified that the remote port was accessible via telnet.  Also ran the vino server on the remote host and tried a VNC connection with remmina on the local machine and hit "connection refused".

So we have two clean installs, and one tester who was able to work with part of it. TMB uploaded the advisory, which says a lot about his confidence in it.

Since nothing has happened here in 24 days, I'm contemplating letting it go. Herman has washed his hands of it, so Len, what do you think?

Yes, it does not look like QA is going to get anywhere with this one so we might as well let it go.
Thanks TJ.

Thanks, Len. OKing and Validating.

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs
Whiteboard: (none) => MGA7-64-OK

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2020-0242.html

Status: NEW => RESOLVED
Resolution: (none) => FIXED