{"id":120192,"date":"2024-10-15T19:09:13","date_gmt":"2024-10-15T17:09:13","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/v-openssh-kod-autentifikaczii-vynesen-v-otdelnyj-proczess-sshd-auth"},"modified":"2024-10-15T19:09:13","modified_gmt":"2024-10-15T17:09:13","slug":"v-openssh-kod-autentifikaczii-vynesen-v-otdelnyj-proczess-sshd-auth","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/news\/v-openssh-kod-autentifikaczii-vynesen-v-otdelnyj-proczess-sshd-auth","title":{"rendered":"In OpenSSH, the authentication code has been moved to a separate process, sshd-auth","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
The OpenSSH developers have continued to split sshd into several separate executable files. In the first phase of the separation implemented in May, functions related to session handling were moved from sshd to a separate process, sshd-session, while sshd retained only the functionality necessary to accept new network connections and launch sshd-session for each new session. Yesterday, a change was made to the OpenSSH codebase that added another process\u2014sshd-auth\u2014into which the code responsible for authentication was transferred from sshd-session. <\/p>\n
The sshd-auth process is launched from sshd-session and allows further isolation of authentication-related data in the address space of a separate process, preventing access to this data in memory during attacks on the code used for handling connection stages prior to authentication completion. Additionally, this change slightly reduces memory consumption since the authentication-related code now resides in memory only during the authentication process and is then unloaded upon completion of the sshd-auth process. <\/p>\n
Similar to sshd, ssh-session, and ssh-agent, the sshd-auth process has implemented a random reallocation of the executable file during each operating system boot. This random reallocation makes the function offsets in executables and libraries hard to predict, complicating the creation of exploits that use return-oriented programming (ROP). In ROP, the attacker does not attempt to place their own code in memory but operates with existing chunks of machine instructions that end with a return instruction (usually the function endings). The exploit's operation involves constructing a chain of calls to such blocks (\"gadgets\") to achieve the desired functionality. \n Source: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"