I løbet af efterforskningen af den kritiske sårbarhed i OpenSSH, der blev afsløret i sidste uge, er der opdaget en anden lignende sårbarhed (CVE-2024-6409), som muliggør fjerneksekvering af kode uden autentificering. Den nye sårbarhed er ikke så farlig som den tidligere, da den optræder efter nedtrapning af privilegier i det kørende SSH-serverbarnprocessen. Sårbarheden findes i openssh-pakkerne fra Red Hat Enterprise Linux 9, baseret på den udgivelse af OpenSSH 8.7, der blev offentliggjort i 2021. Problemet berører også pakkerne til Fedora Linux 36 og 37, der er baseret på udgivelserne OpenSSH 8.7 og 8.8.
Sårbarheden minder i sin essens om det tidligere problem og skyldes også en racecondition i SIGALRM-interruptbehandleren, der opstår som følge af udførelsen af funktioner, som ikke er designet til at blive kaldt i asynkrone tilstand fra signalbehandlere. Behandleren aktiveres, når timeout'en, der er fastsat via parameteren LoginGraceTime, indtræffer, og afbryder den aktuelle kodeeksekvering. Brug af funktioner, der ikke er beregnet til asynkron udførelse, i interruptbehandleren, som bruger dynamisk hukommelsesallokering, såsom syslog(), kan føre til beskadigelse af de interne malloc-strukturer, når SIGALRM udløses under udførelsen af en bestemt kode.
Den nye sårbarhed adskiller sig ved, at raceconditionen opstår som følge af kaldet af funktionen cleanup_exit() i signalhandleren grace_alarm_handler(). I OpenSSH's hovedkodebase kan denne funktion bruges i asynkront udført kode, men i pakkerne til RHEL 9 og Fedora er der blevet anvendt et ekstra patch, der tilføjer et kald til funktionen for at generere revisionshændelser i cleanup_exit(), som er designet til brug i signalbehandlere.
Denne patch blev brugt i RHEL 9 og derivative distributioner i pakker baseret på OpenSSH 8.7p1. I de aktuelle udgivelser af Fedora viser problemet sig ikke, da distributionen siden Fedora 38 er skiftet til en nyere version af OpenSSH uden ændringer i cleanup_exit(). I modsætning til den tidligere sårbarhed er en bypass-løsning, der er baseret på brugen af optionen '-e' i sshd, som deaktiverer logoutput via syslog, ikke egnet til at blokere det nye problem. Dog kan parameteren 'LoginGraceTime=0' indstilles i sshd_config for at blokere sårbarheden.
Kilde: opennet.ru
