"iTALC is a useful and powerful didactic tool which lets you view and
control computers in your labs and interact with students in a modern
way. It supports Linux and Windows NT/2000/XP"
 so it looks dated...

This rarely updated SRPM has no maintainer, so the bug must be globally assigned.

Assignee: bugsquad => pkg-bugs
Version: 7 => Cauldron

Ubuntu has issued an advisory for this today (October 20):
https://ubuntu.com/security/notices/USN-4587-1

Suggested advisory:
========================

The updated packages fix security vulnerabilities:

LibVNC before commit 502821828ed00b4a2c4bef90683d0fd88ce495de contains heap out-of-bound write vulnerability in server code of file transfer extension that can result remote code execution. (CVE-2018-15127)

LibVNC before commit a83439b9fbe0f03c48eb94ed05729cb016f8b72f contains multiple heap out-of-bound write vulnerabilities in VNC client code that can result remote code execution. (CVE-2018-20019)

LibVNC before commit 7b1ef0ffc4815cab9a96c7278394152bdc89dc4d contains heap out-of-bound write vulnerability inside structure in VNC client code that can result remote code execution. (CVE-2018-20020)

LibVNC before commit c3115350eb8bb635d0fdb4dbbb0d0541f38ed19c contains a CWE-835: Infinite loop vulnerability in VNC client code. Vulnerability allows attacker to consume excessive amount of resources like CPU and RAM. (CVE-2018-20021)

LibVNC before 2f5b2ad1c6c99b1ac6482c95844a84d66bb52838 contains multiple weaknesses CWE-665: Improper Initialization vulnerability in VNC client code that allows attacker to read stack memory and can be abuse for information disclosure. Combined with another vulnerability, it can be used to leak stack memory layout and in bypassing ASLR. (CVE-2018-20022)

LibVNC before 8b06f835e259652b0ff026898014fc7297ade858 contains CWE-665: Improper Initialization vulnerability in VNC Repeater client code that allows attacker to read stack memory and can be abuse for information disclosure. Combined with another vulnerability, it can be used to leak stack memory layout and in bypassing ASLR. (CVE-2018-20023)

LibVNC before commit 4a21bbd097ef7c44bb000c3bd0907f96a10e4ce7 contains null pointer dereference in VNC client code that can result DoS. (CVE-2018-20024)

LibVNC before 0.9.12 contains multiple heap out-of-bounds write vulnerabilities in libvncclient/rfbproto.c. The fix for CVE-2018-20019 was incomplete. (CVE-2018-20748)

LibVNC before 0.9.12 contains a heap out-of-bounds write vulnerability in libvncserver/rfbserver.c. The fix for CVE-2018-15127 was incomplete. (CVE-2018-20749)

LibVNC through 0.9.12 contains a heap out-of-bounds write vulnerability in libvncserver/rfbserver.c. The fix for CVE-2018-15127 was incomplete. (CVE-2018-20750)

An issue was discovered in LibVNCServer through 0.9.11. rfbProcessClientNormalMessage() in rfbserver.c does 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 commit before d01e1bb4246323ba6fcee3b82ef1faa9b1dac82a contains a memory leak (CWE-655) in VNC server code, which allow an attacker to read stack memory and can be abused for information disclosure. Combined with another vulnerability, it can be used to leak stack memory and bypass ASLR. This attack appear to be exploitable via network connectivity. (CVE-2019-15681)

References:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-15127
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20019
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20020
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20021
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20022
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20023
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20024
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20748
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20749
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20750
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://ubuntu.com/security/notices/USN-4547-1
https://ubuntu.com/security/notices/USN-4587-1
========================

Updated packages in core/updates_testing:
========================
italc-3.0.3-3.1.mga7
italc-client-3.0.3-3.1.mga7
italc-client-autostart-3.0.3-3.1.mga7
italc-master-3.0.3-3.1.mga7

from SRPM:
italc-3.0.3-3.1.mga7.src.rpm

Source RPM: italc-3.0.3-4.mga8.src.rpm => italc-3.0.3-3.mga7.src.rpm
Status: NEW => ASSIGNED
Whiteboard: MGA7TOO => (none)
Assignee: pkg-bugs => qa-bugs
Version: Cauldron => 7
CC: (none) => nicolas.salguero

I have zero experience with this sort of thing, but decided to try it anyway. 

Installed all four italc packages from the M7 repos, with no issues. I did not try to start it, but instead used QARepo to get the above updates. Again, no installation issues.

But, I was unable to run iTALC from the Plasma menu. Going to the command line and using the command "italc," the same command used by the Plasma menu, I see the following message:

"italc: error while loading shared libraries: libItalcCore.so: cannot open shared object file: No such file or directory"

So, it looks like something is missing somewhere. Of course, it could just be that I don't know what I'm doing.

CC: (none) => andrewsfarm

As has been necessary for some other packages where the library modules are
in a sub-directory of /usr/lib64, looks like it's necessary to create ...
# cat /etc/ld.so.conf.d/italc.conf 
/usr/lib64/italc/

Found some instructions at https://www.techrepublic.com/blog/diy-it-guy/diy-set-up-a-pc-instructional-environment-with-italc/

Like any vnc server/client this is best tested on two separate systems, and
it's best to test the release version first to ensure no setup problems before
trying the update.

I'll try to test this one tomorrow.

CC: (none) => davidwhodgins

The library issue sounds like a packaging error.

(In reply to David Walser from comment #6)
> The library issue sounds like a packaging error.

Yes, but not a regression, so it will not hold up the update if the rest checks
out ok.

I still question why we kept this package in Cauldron.  Obviously nobody is even using it.

(In reply to Dave Hodgins from comment #5)
> Like any vnc server/client this is best tested on two separate systems, and
> it's best to test the release version first to ensure no setup problems
> before
> trying the update.
> 
> I'll try to test this one tomorrow.

OK, good. The more I read, the higher above my pay grade and skill set it looks. I only looked into it because it had been sitting here for over two weeks with no response from QA. 

However, I must admit to being uneasy just on general principles about the idea of passing along an update with a known packaging error, even if it isn't a regression.

Status of this QA?

CC: (none) => ouaurelien

I really dislike doing this, but the instructions for italc that I've been able
to find don't match with how it seems to be setup and do not make sense to me.
I'm giving up trying to get it to work, and am approving the update based solely
on the update installing cleanly over the prior version.

That makes two of us. Perhaps someone who knows how to run this can someday determine if there is a missing package (Comment 4) but it is beyond me.

Since I had a clean update of the previous version, and it looks like that's the best we are going to do, I'm giving this the OK and validating. Advisory in Comment 3.

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

Advisory pushed to SVN.

Keywords: (none) => advisory

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

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

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