{"id":121386,"date":"2025-01-17T15:46:06","date_gmt":"2025-01-17T13:46:06","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/uyazvimost-v-pam-u2f-pozvolyayushhaya-obojti-autentifikacziyu-na-baze-apparatnogo-tokena"},"modified":"2025-01-17T15:46:06","modified_gmt":"2025-01-17T13:46:06","slug":"uyazvimost-v-pam-u2f-pozvolyayushhaya-obojti-autentifikacziyu-na-baze-apparatnogo-tokena","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/news\/uyazvimost-v-pam-u2f-pozvolyayushhaya-obojti-autentifikacziyu-na-baze-apparatnogo-tokena","title":{"rendered":"Vulnerability in pam-u2f allowing bypass of hardware token authentication","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Deweloperzy projektu openSUSE zidentyfikowali luk\u0119 (CVE-2025-23013) w module PAM pam-u2f, u\u017cywanym do uwierzytelniania za pomoc\u0105 token\u00f3w YubiKey, Yubico Security Key, YubiHSM oraz innych urz\u0105dze\u0144 FIDO wspieraj\u0105cych protoko\u0142 U2F (Universal 2nd Factor). Luka pozwala u\u017cytkownikowi, kt\u00f3ry ma nieuprzywilejowany dost\u0119p lokalny do systemu, w pewnych konfiguracjach PAM zalogowa\u0107 si\u0119 bez wstawienia sprz\u0119towego tokena. W praktyce modu\u0142 pam-u2f zazwyczaj jest \u0142\u0105czony z dwuetapowym lub bezhas\u0142owym uwierzytelnianiem z u\u017cyciem token\u00f3w (na przyk\u0142ad do potwierdzania uprawnie\u0144 przy u\u017cyciu narz\u0119dzi su i sudo). <\/p>\n
Luka spowodowana jest niew\u0142a\u015bciwym zwracaniem przez funkcj\u0119 pam_sm_authenticate() warto\u015bci PAM_IGNORE. Warto\u015b\u0107 ta jest zwracana w przypadku b\u0142\u0119du wykonania wywo\u0142a\u0144 gethostname(), pam_modutil_drop_priv(), pam_modutil_regain_priv() lub resolve_authfile_path(), a tak\u017ce w przypadku problem\u00f3w z alokacj\u0105 pami\u0119ci w strdup() lub calloc(). Problem polega na tym, \u017ce biblioteka libpam, otrzymuj\u0105c od modu\u0142u PAM wynik z kodem PAM_IGNORE, zwr\u00f3ci wynik ko\u0144cowy PAM_SUCCESS, co oznacza pomy\u015blne zako\u0144czenie uwierzytelniania, je\u015bli w \u0142a\u0144cuchu sprawdzania jaki\u015b inny modu\u0142 PAM zwr\u00f3ci\u0142 pomy\u015blny wynik uwierzytelnienia. <\/p>\n
Podczas korzystania z modu\u0142u pam-u2f w po\u0142\u0105czeniu z pam_unix do dwuetapowego uwierzytelniania, luka pozwala na pomy\u015blne przej\u015bcie uwierzytelnienia w przypadku pomy\u015blnego sprawdzenia has\u0142a, bez potwierdzenia drugiego czynnika. Przy realizacji bezhas\u0142owego uwierzytelniania za pomoc\u0105 sprz\u0119towego tokena pam-u2f mo\u017ce by\u0107 u\u017cywany w po\u0142\u0105czeniu z modu\u0142em PAM pam_faillock, kt\u00f3ry ogranicza liczb\u0119 pr\u00f3b uwierzytelnienia i zwraca PAM_SUCCESS, je\u015bli limit nie zosta\u0142 wyczerpany. <\/p>\n
Przyk\u0142adem ataku jest obej\u015bcie weryfikacji tokena podczas wykonywania przez lokalnego u\u017cytkownika polece\u0144 z uprawnieniami, przy u\u017cyciu narz\u0119dzi sudo i su. Podczas uruchamiania tych polece\u0144 atakuj\u0105cy mo\u017ce stworzy\u0107 mo\u017cliwo\u015b\u0107 zwr\u00f3cenia przez modu\u0142 pam-u2f warto\u015bci PAM_IGNORE, na przyk\u0142ad poprzez wyczerpanie dost\u0119pnej pami\u0119ci. Problem zosta\u0142 naprawiony w wersji pam-u2f 1.3.1. \n \u0179r\u00f3d\u0142o: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"