Уязвимост в OpenSSH, свързана с начина, по който библиотеката musl обработва грешки при проверка на пароли, може да позволи неоторизиран достъп до определени потребителски акаунти. Проблемът засяга конфигурации на Alpine Linux и други Linux дистрибуции, базирани на musl, а атаката може да бъде осъществена чрез въвеждане на прекалено дълга парола.

Уязвимостта, наречена „sshole“, е открита от изследователя по сигурността Озгюн Кюлтекін (Ozgun Kultekin). По думите му проблемът съществува от 2016 г. и произтича от взаимодействието между OpenSSH и функцията crypt() в библиотеката musl. Той е публикувал технически подробности за откритието на специално създаден сайт.

Засегнати са SSH сървъри, работещи върху Linux системи с musl, сред които Alpine Linux, OpenWrt, Buildroot и Yocto. Уязвимостта не се проявява при всяка инсталация, а само при определени настройки за удостоверяване.

Причината е свързана с начина, по който Linux обработва акаунти, за които в /etc/shadow е зададен символът * вместо валиден хеш на парола. Тази конфигурация трябва да блокира удостоверяването чрез парола за съответния акаунт.

През 2016 г. OpenSSH е променил механизма си за проверка на пароли, за да отстрани уязвимостта CVE-2016-6210, която е позволявала разкриване на валидни потребителски имена чрез измерване на времето за отговор. За да уеднакви поведението при проверка на съществуващи и несъществуващи или блокирани акаунти, софтуерът започнал да извършва операция по хеширане дори когато акаунтът няма използваем хеш на парола.

Проблемът възниква заради поведението на crypt() в musl. Функцията връща *, когато хеширането не може да бъде извършено, включително при подадена парола, която надхвърля ограничението от 256 байта. Така върнатата стойност може да съвпадне със символа *, записан като паролен хеш за блокирания акаунт. В резултат OpenSSH може погрешно да приеме проверката за успешна и да допусне достъп.

Атаката не позволява заобикаляне на паролите на акаунти, които имат валидни паролни хешове. За успешна експлоатация трябва едновременно да са изпълнени няколко условия:

• OpenSSH да работи върху Linux дистрибуция, използваща musl;
• PAM удостоверяването да е изключено – настройка по подразбиране в пакета openssh-server на Alpine Linux;
• SSH удостоверяването с парола да е разрешено;
• поне един акаунт да има символа * като паролен хеш;
• друг акаунт в системата да разполага с валиден паролен хеш.

Особено внимание заслужават официалните облачни образи на Alpine Linux за AWS и Azure. Според изследователя те съдържат засегнат акаунт alpine, който има привилегии за изпълнение на команди без парола чрез doas. При успешно използване на уязвимостта това може да създаде възможност за повишаване на привилегиите до root.

Системи, използващи glibc, включително Debian, Ubuntu и Fedora, не са засегнати от описания механизъм. Същото важи за конфигурациите, при които се използва PAM удостоверяване.

Интересен детайл около откритието е методът, с който е установен проблемът. Кюлтекін посочва, че е използвал агенти с изкуствен интелект, които са изпълнили приблизително 17 600 теста с различни настройки на OpenSSH, неправилно формирани паролни хешове и пароли с необичайно голяма дължина.

Уязвимостта е отстранена в OpenSSH 10.6p2. Администраторите на Alpine Linux трябва да инсталират актуализациите чрез командата:

apk upgrade openssh

Ако незабавното обновяване не е възможно, временна защитна мярка е изключването на удостоверяването с парола чрез настройката PasswordAuthentication no в конфигурацията на SSH сървъра, последвано от рестартиране на услугата.

Администраторите трябва да проверят и дневниците за признаци на евентуална експлоатация. В Alpine Linux успешните удостоверявания чрез парола могат да бъдат открити с:

grep "Accepted password" /var/log/messages

Ако в дневниците има успешно удостоверяване с парола за акаунта alpine, може да се провери дали той действително е конфигуриран да не допуска такъв тип достъп:

grep '^alpine:' /etc/shadow

Съвпадение между успешно SSH удостоверяване с парола и акаунт, чийто паролен хеш е *, може да е признак за използване на уязвимостта. Подобна следа трябва да бъде разгледана в контекста на останалите записи и събития в системата, а не автоматично да се приема за доказателство за компрометиране.

„sshole“ показва как промяна, въведена с цел защита срещу един тип атака, може да създаде неочакван проблем при взаимодействието между различни софтуерни компоненти. За организациите, които използват Alpine Linux и други системи с musl в сървъри, мрежови устройства или облачна инфраструктура, проверката на версиите на OpenSSH и настройките за удостоверяване е непосредствен приоритет.