{"id":53580,"date":"2019-12-05T00:00:00","date_gmt":"2019-12-04T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/uyazvimosti-v-openbsd-pozvolyayushhie-povysit-privilegii-i-obojti-autentifikatsiyu-v-smtpd-ldapd-i-radiusd"},"modified":"2021-02-01T11:40:32","modified_gmt":"2021-02-01T09:40:32","slug":"uyazvimosti-v-openbsd-pozvolyayushhie-povysit-privilegii-i-obojti-autentifikatsiyu-v-smtpd-ldapd-i-radiusd","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/news\/uyazvimosti-v-openbsd-pozvolyayushhie-povysit-privilegii-i-obojti-autentifikatsiyu-v-smtpd-ldapd-i-radiusd","title":{"rendered":"Luki w OpenBSD, kt\u00f3re umo\u017cliwiaj\u0105 podwy\u017cszenie uprawnie\u0144 i omini\u0119cie uwierzytelnienia w smtpd, ldapd i radiusd","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Firma Qualys ujawnili<\/a><\/noindex> cztery vulnerablista<\/a><\/noindex> W OpenBSD istnieje jedna luka, kt\u00f3ra umo\u017cliwia zdalne po\u0142\u0105czenie bez uwierzytelnienia z niekt\u00f3rymi us\u0142ugami sieciowymi, a trzy inne mog\u0105 podnie\u015b\u0107 przywileje w systemie. Raport Qualys podkre\u015bla szybk\u0105 reakcj\u0119 tw\u00f3rc\u00f3w OpenBSD \u2014 wszystkie problemy zosta\u0142y zosta\u0142y usuni\u0119te<\/a><\/noindex> do OpenBSD 6.5<\/a><\/noindex> i OpenBSD 6.6<\/a><\/noindex> naprawione w ci\u0105gu 40 godzin od prywatnego powiadomienia.<\/p>\n

Zdalna luka w zabezpieczeniach spowodowana jest b\u0142\u0119dem w organizacji wywo\u0142ania procedury autoryzacyjnej w bibliotece libc, kt\u00f3ra uruchamia
\nprogramu \/usr\/libexec\/auth\/login_style z przekazywaniem argument\u00f3w w wierszu polece\u0144. Tak\u017ce podczas wywo\u0142ywania login_style przy u\u017cyciu opcjonalnego parametru \u00ab-s service\u00bb mo\u017cliwe jest przekazanie nazwy protoko\u0142u. W przypadku u\u017cycia na pocz\u0105tku nazwy u\u017cytkownika znaku \u00ab-\u00bb, ta nazwa zostanie potraktowana jako opcja przy uruchamianiu login_style. W zwi\u0105zku z tym, je\u015bli jako nazwa u\u017cytkownika w uwierzytelnieniu podamy \u00ab-schallenge\u00bb lub \u00ab-schallenge:passwd\u00bb, login_style potraktuje to jako \u017c\u0105danie u\u017cycia przetwarzacza S\/Klucz<\/a><\/noindex>.<\/p>\n

Problem polega na tym, \u017ce protok\u00f3\u0142 S\/Key w login_style jest obs\u0142ugiwany jedynie formalnie, a w\u0142a\u015bciwie ignorowany przy wydawaniu znaku sukcesu uwierzytelnienia. W ten spos\u00f3b atakuj\u0105cy, podszywaj\u0105c si\u0119 pod u\u017cytkownika \u00ab-schallenge\u00bb, mo\u017ce obej\u015b\u0107 uwierzytelnienie i uzyska\u0107 dost\u0119p bez podawania has\u0142a lub kluczy. Potencjalnie problem ten dotyczy wszystkich us\u0142ug sieciowych, kt\u00f3re u\u017cywaj\u0105 standardowych wywo\u0142a\u0144 libc do przeprowadzania uwierzytelnienia. Na przyk\u0142ad mo\u017cliwo\u015b\u0107 omini\u0119cia uwierzytelnienia zosta\u0142a potwierdzona w smtpd (AUTH PLAIN), ldapd i radiusd.<\/p>\n

W sshd luka ta nie wyst\u0119puje, poniewa\u017c zapewniona jest dodatkowa ochrona poprzez sprawdzenie obecno\u015bci u\u017cytkownika w systemie. Niemniej jednak, sshd mo\u017cna u\u017cy\u0107 do sprawdzenia podatno\u015bci systemu na luk\u0119 \u2014 przy wywo\u0142aniu z nazw\u0105 u\u017cytkownika \u00ab-sresponse:passwd\u00bb po\u0142\u0105czenie zawiesza si\u0119, poniewa\u017c sshd czeka na przekazanie parametr\u00f3w wywo\u0142ania (challenge) od login_passwd, a login_passwd czeka na przekazanie brakuj\u0105cych parametr\u00f3w (nazwa \u00ab-sresponse\u00bb jest traktowana jako opcja). Potencjalnie lokalny atakuj\u0105cy mo\u017ce spr\u00f3bowa\u0107 obej\u015b\u0107 uwierzytelnienie w narz\u0119dziu su, ale przekazanie nazwy \u00ab-sresponse\u00bb prowadzi do awarii procesu z powodu zwracania wska\u017anika zerowego podczas wykonywania funkcji getpwnam_r(\u00ab-schallenge\u00bb, \u2026).<\/p>\n

Inne podatno\u015bci:<\/p>\n