Fedora has issued an advisory today (May 7): https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/AELSWWBAM2YONRPGLWVDY6UNTLJERJYL/ The issues are fixed upstream in 2.7.0.
Status comment: (none) => Fixed upstream in 2.7.0
We recently have 2.7.0 in Cauldron, done by tv. Assigning to you because you have done the most recent updates to freerdp; despite DavidG being the registered maintainer, but no activity by him on this for more than a year.
Assignee: bugsquad => thierry.vignaud
Ubuntu has issued an advisory for this on June 6: https://ubuntu.com/security/notices/USN-5461-1
openSUSE has issued an advisory for this today (July 11): https://lists.opensuse.org/archives/list/security-announce@lists.opensuse.org/thread/3XAZEK5W555DLYFBAHQKYWZRJ4CADMBX/
Suggested advisory: ======================== The updated packages fix security vulnerabilities: FreeRDP is a free implementation of the Remote Desktop Protocol (RDP). In versions prior to 2.7.0, NT LAN Manager (NTLM) authentication does not properly abort when someone provides and empty password value. This issue affects FreeRDP based RDP Server implementations. RDP clients are not affected. The vulnerability is patched in FreeRDP 2.7.0. There are currently no known workarounds. (CVE-2022-24882) FreeRDP is a free implementation of the Remote Desktop Protocol (RDP). Prior to version 2.7.0, server side authentication against a `SAM` file might be successful for invalid credentials if the server has configured an invalid `SAM` file path. FreeRDP based clients are not affected. RDP server implementations using FreeRDP to authenticate against a `SAM` file are affected. Version 2.7.0 contains a fix for this issue. As a workaround, use custom authentication via `HashCallback` and/or ensure the `SAM` database path configured is valid and the application has file handles left. (CVE-2022-24883) References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-24882 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-24883 https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/AELSWWBAM2YONRPGLWVDY6UNTLJERJYL/ https://ubuntu.com/security/notices/USN-5461-1 https://lists.opensuse.org/archives/list/security-announce@lists.opensuse.org/thread/3XAZEK5W555DLYFBAHQKYWZRJ4CADMBX/ ======================== Updated packages in core/updates_testing: ======================== freerdp-2.2.0-1.2.mga8 lib(64)freerdp2-2.2.0-1.2.mga8 lib(64)freerdp-devel-2.2.0-1.2.mga8 from SRPM: freerdp-2.2.0-1.2.mga8.src.rpm
CC: (none) => nicolas.salgueroAssignee: thierry.vignaud => qa-bugsStatus: NEW => ASSIGNEDStatus comment: Fixed upstream in 2.7.0 => (none)
GNOME client, Plasma using VBox The following 2 packages are going to be installed: - freerdp-2.2.0-1.2.mga8.x86_64 - lib64freerdp2-2.2.0-1.2.mga8.x86_64 88B of additional disk space will be used. xfreerdp /size:1200x750 xfreerdp /f Neither parameter is working to expand the screen. sending feedback
Whiteboard: (none) => feedbackCC: (none) => brtians1
Is this a regression?
nope - guess not. Same issue on prior version and on Xfce. So it works as it did before. removing feedback.
Whiteboard: feedback => (none)
I'm not sure if it's supposed to allow mouse/keyboard interaction with the remote system or just to view the remote desktop. On my rp4 system ... [dave@rp4 ~]$ freerdp-shadow-cli /port:3984 /monitors:0 On my main system ... [dave@x3 ~]$ xfreerdp /v:rp4.hodgins.homeip.net:3984 -u:dave -p:<munged> I can view the rp4 desktop, but with no mouse or keyboard impact on it as I have with vncviewer, likely due to my lack of knowledge. These are not regressions as I have the same with either the testing version or the prior version. Validating the update as I think this is ok.
Keywords: (none) => validated_updateWhiteboard: (none) => MGA8-64-OKCC: (none) => davidwhodgins, sysadmin-bugs
mouse and keys work on my systems. I'm good with validating.
What parameters did you use to enable the mouse/keyboard?
It just worked. I did use xfreerdp /f <ip:port>
I'm using synergy between the two systems as well as sshfs, so it's likely something in my configurations that's interfering. As it's working for Brian and not a regression for me, I agree with the validation. Committing the advisory to svn.
Keywords: (none) => advisory
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2022-0383.html
Resolution: (none) => FIXEDStatus: ASSIGNED => RESOLVED