Length checking for the EGFX dynamic virtual channel is inadequate,
allowing for heap overflows to be forced by a malicious client before
authentication.
- add addr_is_ipv4 helper function
- add addr_is_ipv6 helper function
- add get_socket_family helper function
- g_tcp_connect:
- #define for MAX_PORT_STR length
- create *addr_arg char that is used in getaddrinfo so we can do any last-minute changes directly
- add chars host and service which are primarily used for debug logging of attempted connection points
- calls get_socket_family to discover family of socket
- add switch case logic for AF_INET6/4:
- v4: just calls addr_is_ipv6 so we don't fail on a hostname input
- v6: drop addrconfig flag and add AI_ALL so we can try to map ipv4 destinations against ipv6 socket to support varied configurations we could see
- if an ipv4 address comes in against an ipv6 socket, we map it to try and connect anyways
- getaddrinfo now calls addr_arg so it picks up changes that an ipv6-case may have done
- before calling connect, use getnameinfo to get logging values for the actual host ip/port we are about to attempt a connect on - I found this useful when debugging so thought it had value to keep
- change if (res > -1) to if (res == 0): the bsd man pages for getaddrinfo only promise that it returns 0 on success, so it seems sensible to me to cover the event that an error code could be positive, which freebsd has some positive EAI_* errors based on this: https://github.com/freebsd/freebsd-src/blob/main/lib/libc/net/gai_strerror.c
- remove connect_loopback entirely: this had several bits of logic handling ipv6 and ipv4 mixing already and ended up being redundant because of the restructuring of g_tcp_connect, which covers direct ip address char* inputs now
- add comment about OSX to IPv6 function for clarity
The Kerberos module and pam_userpass modules are now unused:
1) On all supported systems, PAM provides a far superior way to
integrate Kerberos support.
2) The pam_userpass module (https://github.com/openwall/pam_userpass)
(which is a lovely idea) is no longer maintained.
57609d4aa7 introduced an issue where
the numCapabilities field in the DR_CORE_CAPABILITY_REQ PDU
was incorrect unless --enable-smartcard was specified.
This commit also improves the logic around handling clients who
advertise a smartcard even if we do not support it.
This has been prompted by the following deprecation messages:
> Node.js 20 actions are deprecated. The following actions are running on Node.js 20 and may not work as expected: actions/cache@v4, actions/checkout@v4.
The smartcard code contains a number of security vulnerabilities and
does not work at the moment.
The code has been left in the source tree, but moved behind an
'--enable-smartcard' configure flag which is clearly marked as not
for production use.
For GFX, we currently resize the client with a deactivation-reactivation
sequence. This is unnecessary, as the GFX RESET_GRAPHICS command does
all the work for us, and avoids the need to teardown and reestablish the
GFX channel.
The move away from the X11 display number has introduced a couple of regressions
1) XDG_SESSION_TYPE is not detected properly.
pam_systemd.so contains code to map a PAM_TTY of ':n' to an 'x11'
session type. This mapping is no longer done. We could re-introduce
this code for X11, but there is no such code to detect a wayland
display type. We try to fix this in a forward-looking way by setting
XDG_SESSION_TYPE explicity before starting the PAM session.
2) utmp is not being updated correctly.
The code for setting ut_id in the utmp[x] structure was setting the
same value for all X11 displays, thus preventing utmp from being able
to see more than one xrdp user
Also, an include is needed for sesman/eicp_process.c on some systems to
get access to strlcpy()
As far as possible, use of the X11 display number is kept to
X11-specific routines. This is to make it easier to restructure
the code to add non-X11 display support.
matt335672