Comments 114
начиная с версии 8.5 и до 4.4
Не сразу распарсил эту фразу. Проще так: уязвимы версии < 4.4, либо >= 8.5.
В 4.4 уязвимость была исправлена, но в 8.5 снова появилась.
Также, исправлен недочёт в защите от анализа задержки между нажатием клавиш (например, клавишу F пользователь нажимает чуть быстрее, чем Q, потому что до Q тянуться дальше). Несмотря на эту защиту, добавленную в 9.5 (OpenSSH имитирует периодическое нажатие клавиш, чтобы запутать внешнего наблюдателя), наблюдатель всё равно мог отличить фейковые нажатия от реальных.
Кроме того, эта отправка фейковых нажатий, как оказалась, сама по себе ломала работу более старого механизма безопасности. Это тоже исправили.
например, клавишу F пользователь нажимает чуть быстрее, чем Q, потому что до Q тянуться дальше
Это если пользователь участвует в соревнованиях по набору пароля на скорость. А если он задумчиво набирает пароль по одной буковке, то связь чуть более чем никакая.
Буквально набираю все свои пароли на мышечной памяти, поэтому актуально.
то есть пароли не меняете?
Ещё можно печатать не глядя на клавиатуру. Тогда, даже если менять пароли ежедневно, всё равно сможешь набирать их не глядя, и с той скоростью, которую обеспечивает мышечная память (ну то есть с какой скоростью набираешь ту или иную букву на клавиатуре).
А зачем менять надежный пароль, который используется в одном месте и использование которого другими пользователями не зафиксировано?
использование которого другими пользователями не зафиксировано?
"— Я ввёл его в Гугле, — продолжал Сисадмин, — и убедился, что в Сети такого сочетания нет.
— Теперь есть." (с)
Очень часто, даже пароль, который много где используется - менять не надо. У обычного человека очень много аккаунтов везде, где он был хоть раз. А вот критически важных - по пальцам пересчитать. Пароль на форуме собаководов, пароль в зоомагазине, пароль на сайте калифорнийских школьниц и пароль в аптеке - можно держать одинаковым. Никому он нахрен не нужен. А вот часто меняя пароль, его можно и забыть (с куда более высокой вероятностью, чем атака ЦРУ на ваш аккаунт в зоомагазине), а это будет уже потерей. Терпимой, но потерей.
Очень часто, даже пароль, который много где используется - менять не надо.
Я Вам более того скажу: особо продвинутые меняют не пароль, а логин.
пароль в зоомагазине, <...> пароль в аптеке
У жены неизвестным образом временно увели акк винлаба.
Списали все бонусы. Доступ был восстановлен обычной смс. Винлаб, когда увидел место списания бонусов (другой город), восстановил их, молодцы.
И надо отметить, что я не могу приучить жену пользоваться нормальными паролями. У нее конечно не 1234, но и не 100 бит, как бы мне хотелось.
Не такие уж и безобидные эти пароли
Скорее всего имелись ввиду аккаунты, которые не жалко потерять. Аккаунт с баллами, на которые имеются виды, очевидно, жалко.
А поскольку каждый первый магазин, который дает возможность создания аккаунтов для покупателя, пытается стать кредитной организацией (я им деньги, они мне - баллы, бонусы, кэшбек - обязательства), то аккаунты, которые не жалко потерять, остаются на сайте калифорнийских школьниц. Да и то, я не уверен, что хочу, чтобы кто-то знал каких именно школьниц...
Когда-то давным давно я зарегистрировался на каком-то местечковом сайте habr.com (тогда ещё habrahabr.ru), с каким-то простым паролем. И у меня умудрились взломать пароль, но аккаунт был оперативно заблокирован и после обращения в поддержку восстановлен с нормальным паролем. После этого всегда пароли делаю приличные, мало ли как жизнь сложится.
Ну вот смотрите - вы рассказываете эту историю, как нечто интересное, необыное, курьезное. Это - исключительный случай, но ваша мысль, что "Вообще и такое случается. Редко, но случается". Согласен. Причем, в вашем случае убытка вообще никакого не было (т.к. баллы восстановили). Но где-то иногда какие-то убытки могут быть, согласен.
Но ведь и таблетка от болезни - тоже горькая. Везде использовать двухфакторку, U2F всякие - это наверняка защитит от угона аккаунта. Но жизнь ведь попортит. Стоит денег, надо таскать с собой, можно потерять, могут украсть. Это не решение проблемы а обмен одной проблемы на другую (иногда выгодный).
По мере того, как отдельный аккаунт становится каким-то прокачанным и ценным - можно его перевести из категории "мусорных" в "ценные" и защищать. Но вряд ли там будет баллов столько, что прямо будет страшно потерять.
Куча аккаунтов с рандомными логинами на мусорное мыло и с выдуманными ПД. Ну и пароль к ним 123qweASD! Такой точно не страшно. Вот на что надеются компании, когда требуют регистрироваться на любой запрос сложнее просмотра рекламы? На мои реальные ПД?
на что надеются компании, когда требуют регистрироваться на любой запрос сложнее просмотра рекламы? На мои реальные ПД?
Ну, во-первых, на лохов это работает, а во-вторых, если речь идёт об интернет-магазине, то придётся как минимум адрес реальный давать.
то придётся как минимум адрес реальный давать.
Зачем? Выбрать ПВЗ достаточно.
Выбрать ПВЗ достаточно.
И как они там определят, что стоящий перед ними поц — это именно тот, кому надо выдать именно эту бандуру? По паспорту? Но тогда Вы должны дать имя из паспорта. Или у Вас пачка не Ваших паспортов в кармане?
По длинному номеру заказа + уникальный код (меняется ежедневно или вообще одноразовый).
С одной стороны, логично, но с другой стороны — это до первого взлома базы.
И что будет после взлома базы? Узнают номера старых заказов?
Узнают номера старых заказов?
Коды для выдачи некоторого количества новых, конечно же.
Какие-то мелкие у вас преступники. Воровать кучку ширпотреба из ПВЗ под камерами так себе идея. Еще и ломать для этого корпорации. Проще тогда уж с ножом прийти. Там обычно одна девочка только сидит. Посадят на столько же, взять можно просто все, реализовать проще.
Ок, предположим, что некоторое количество кодов генерится заранее и лежит в той же базе, известен номер следующего заказа и известно в какой ПВЗ он будет доставлен. Теперь нам нужно угадать момент, когда заказ уже привезут в ПВЗ но покупатель его еще не забрал (а еще может быть такое, что покупатель уже успел до этого сделать и получить заказ и цифры для текущего заказа сменились). Предположим, нам повезло и угадали (уже слишком много "предположим"). И с высокой вероятностью получим предоплаченную ненужную хрень за 300-500р или кучу не оплаченных еще шмоток. И после этого, когда придет законный покупатель, поднимется дикая вонь и просто перегенерят коды + фото с камеры из ПВЗ уйдет в полицию.
И как они там определят, что стоящий перед ними поц — это именно тот, кому надо выдать именно эту бандуру?
Сраный штрих/кур-кот из телефона решает.
-Откуда он в телефоне берётся?
-Можно и приложение маркетплейса/ов поставить, но я старовер (ничего лишнего кроме музыки) - в браузере ЛК открываем, и, вуаля бля, предъявляем искомое выдающему.
Сраный штрих/кур-кот из телефона решает.
Понятно, бабушки без телефона дружно идут в лес вместе с носителями "Нокий".
Бабушки без телефона могут записать последовательность циферек на бумажку после того как заказ доставят в ПВЗ.
Понятно, бабушки без телефона дружно идут в лес
Ну какой же вы, право, зануда (в лучшем смысле этого слова).
Все бабУшки, которых в ПВЗ обычно много вижу - оснащены смартами различной степени ушатанности . А код выдачи вполне может быть выслан и получен и на 3310, и даже на эрик т28/ме45.
Я обычно согласен с вашим скептическим настроем по поводу различных аспектов жизни на 1/7 части суши (и сашими), но здесь сработал эффект низкой базы, как и с дбо для физиков, относительно быстрым и недорогим (пока) инетом.
Дело в том, что я уже много лет не был на той части суши (если не счиать похорон отца) — а на противоположной части суши ходить куда-то считается для лохов, здесь ПВЗ, я бы сказал, встречаются реже, чем пункты проката копий на динозавра (хотя всякие амазоны ыксперементируют).
Вот только мыло надо не мусорное, а вполне осознанное: sber@mydomain.ru, sdek@mydomain.ru и пр.
Что бы когда уплывёт - точно знать, кто слил
Но ведь и таблетка от болезни - тоже горькая. Везде использовать двухфакторку, U2F всякие - это наверняка защитит от угона аккаунта. Но жизнь ведь попортит.
Как Вы быстро от одной крайности ( один пароль, 123qweASD, на всех некритичных сайтах) до другой (2ФА) добрались. Промежуточных вариантов нет?
По мере того, как отдельный аккаунт становится каким-то прокачанным и ценным - можно его перевести из категории "мусорных" в "ценные" и защищать. Но вряд ли там будет баллов столько, что прямо будет страшно потерять.
То есть надо еще и периодически проверять, не ушла ли мусорность акка, вдруг он стал ценным? А может акция какая была и на акк насыпали столько бонусов, что уже жалко будет их потерять?
Может без крайностей? Не надо 2ФА (скорее всего сам сайт аптеки это не поддержит), но и не надо простых одинаковых паролей.
Я говорю про эту ситуацию с позиции того, какие меры защиты требуют разработчики. Если разработчики дают возможности для сложных мер, но не требуют их - прекрасно! Тогда пользователь сам решит, какие промежуточные варианты ему лично подходят. То есть, если мы хотим предоставить юзеру весь диапазон "строгости", то у этого диапазона будет ведь и край - будет юзер, для которого 123qwe вполне нормально (так вот он считает).
Если же разработчики оставили один вариант "защита, кручем чем в банке" (и довольны собой, какие они классные) - то никаких компромиссов для пользователя уже нет.
Все прогрессивное человечество (сначала я, а потом и NIST присоединился) считает принудительную смену паролей вредной: https://pages.nist.gov/800-63-FAQ/#q-b05
Менять пароль надо по-вдохновению и велению души. Если же к смене пароля принуждают, то либо новый пароль не сильно поможет (в конце добавится циферка "1", например. Так себе криптостойкость), либо она вообще поломает пароль (вместо сложного но постоянного, юзер выберет минимально подходящий типа MyPass000, MyPass001)
вместо сложного но постоянного, юзер выберет минимально подходящий типа MyPass000, MyPass001
...и потом всё равно забудет, потому что у каждого второго сайта свои представления о том, как должен выглядеть стойкий пароль.
Да, мне тоже это не нравится. Есть условный пароль для маловажных сайтов из 8 символов - гуд. Но надо десять, ну ок, добиваем в конце "11" и норм. А через 2-3 месяца заходишь, пишешь свой пароль - не подходит. Восстанавливаешь, надо придумать пароль - пишешь свой. Надо еще два символа - пишешь "11"....
...и это невероятно бесит! Кто-то не принимает символы (;,'@$..), кто-то требует строго 4/5/6 цифр, кому-то просто букв и цифр мало, кто-то требует не менее 14 символов... в итоге на "проходные" ресурсы регаюсь с паролем типа "Zuek1925", по необходимости добавляя всякие дефисы и амперсанды.
Буквально набираю все свои пароли на мышечной памяти
То есть Вы осознаёте, что набираете пароль, да? Ну так осознавайте ещё и то, что Вашей спешкой может воспользоваься атакующий, и специально набирайте пароль не торопясь — чтобы обломать ему всю малину.
То есть Вы осознаёте, что набираете пароль, да? Ну так осознавайте ещё и то, что Вашей спешкой может воспользоваься атакующий, и специально набирайте пароль не торопясь — чтобы обломать ему всю малину.
Я осознаю, что набираю пароль. Но, если я задумаюсь какой именно пароль я набираю, и начну его набирать не торопясь спеша, по одному символу- ппц. Я его никогда не наберу - я его не помню. Что-то там про сороконожку, которая задумалась с какой ноги начинать движение и фсё - подохла на месте от голода и обезвоживания.
Я вначале подумал, что Ваш пароль – это история про сороконожку.
Хорошая идея - надо взять на заметку:))
сОРОК ТЫСЯЧ ОБЕЗЬЯН жеж!
Разумеется, на любую ситуацию можно придумать сферический контрпример в вакууме.
Например, бухгалтер Марьиванна, сосредоточенно сопя набирающая пароль от SSH двумя пальчиками.
Возможно, такая Марьиванна есть. Даже наверняка где-то есть. Но обычно люди, имеющие дело с SSH, вводят пароли быстро и вслепую.
При чём тут Марь Иванна? Я про "сейчас я буду набирать пароль, я помню про такую атаку, поэтому оттормаживаюсь и специально набираю его медленно".
обычно люди, имеющие дело с SSH, вводят пароли быстро и вслепую.
Обычно люди имеющие дело с ssh вводят пароль максимум один раз. А потом логинится по ключу.
PS: Лучше вводить пароль 0 раз, но не всегда получается.
но не всегда получается.
В таком случае можно ввести один раз и сразу его сменить.
А как же sudo?
Делаем два юзера. Под одним просто ходим обычно. Ему sudo нельзя. Второй "суперюзер" с беспарольным sudo. Под ним ходим только когда надо.
В целом можно даже завести третьего юзера которому разрешено sudo без пароля для всех типичных действий и только для них. Дебаг там всякий.
Угроза от которой может защитить пароль от sudo в таком конфиге непонятна. Под "суперюзером" запускать curl https://bestsite.com | bash не стоит. Но вроде это понятно. Да и под обычным не стоит лучше.
pam_ssh_agent_auth
Но речь ведь может идти не только про пароль SSH. Иногда нужно вводить пароль на удалённой машине. Было бы неплохо, если бы существовал способ указать SSH-клиенту, что будет вводиться пароль, и нужно поменять поведение: дождаться Enter (или, может быть, иной комбинации клавиш) и передать набранные символы одним блоком (может с дополнительными незначащими данными, которые помешают определить длину пароля).
Обычно люди, имеющие дело с ссш, не вводят пароли, а пользуются ключами.
...а потом обречённо смотрят, как космонавты из маски-шоу заходят на все их системы.
На ключи можно тоже поставить пароли. Более того, ключи можно хранить в криптоконтейнере или на аппаратном аппарате.
Не можно, а даже нужно =)
тогда будет... "...а потом обречённо смотрят, ОСТАВШИМСЯ ГЛАЗОМ, как космонавты..." и далее по тексту.
Да без проблем, на своих сервисах можете вобще аутентификацию отключить, раз за оставшийся глаз так страшно. Вам же скрывать нечего, верно?
а потом обречённо смотрят, ОСТАВШИМСЯ ГЛАЗОМ
Зоя Космодемьянская смотрит на Вас как-то презрительно.
Зою ломали дилетанты и это было больше местью за диверсию, чем реальным допросом. Здесь же, если я правильно понял вводные, задача стоит по другому: Возможен взлом яйцеголовыми хакерами & визит космонавтов. А это ОЧЕНЬ высокий уровень угрозы. И моя ставка здесь в том, что человека сломать проще, чем компьютер.
99% пользователей эти угрозы не страшны. Я действительно не имею таких секретов, которые стоит ТАК защищать. НО если вдруг проект требует высокого уровня защиты, то ситуация, когда от одного секрета в руках одного человека зависит безопасность всего проекта просто неприемлемо. В идеале система должна иметь как минимум ложный пароль, после введения которого данные превращаются в тыкву.
На ключи можно тоже поставить пароли.
Г-н Оккам напоминает, что не следует вводить лишние сущности без надобности. Иными словами, раз всё равно пароль — тогда зачем ключ?
Ну как минимум:
Пароль на ключ вводится строго локально и нигде более не участвует, кроме расшифровки ключа.
Вход по ключам более секурный чем по паролю.
Пароль на ключ вводится строго локально и нигде более не участвует, кроме расшифровки ключа.
О чём собственно и пишет статья: если куда-то спешить, то атакующий действительно по паузам между пакетами может сделать выводы о пароле. Но в этом случае действует старое доброе "— Доктор, когда я делаю так, мне больно. — Ну так не делайте так!"
Вход по ключам более секурный чем по паролю.
Теоретически — да, а практически — для меня нет особых отличий, если мой ключ может быть подобран за 10^100 лет, а пароль — "всего" за 10^5 лет.
может сделать выводы о пароле
О каком пароле если мы сейчас о ключе?
а пароль — "всего" за 10^5 лет.
Я тоже люблю пароли на 100500 символов, но это редкость.
А Вы что, после неверной попытки входа паузу не ставите?
Лично у меня вообще f2b срабатывает после первой попытки неудачного логина. А что?
А что?
А то, что даже условный пароль на 6 символов (я надеюсь, Вы хэши солите?) при блокировке попыток быстро не подобрать.
после первой попытки неудачного логина
То есть Вы никогда-никогда по буковкам не промахиваетесь?
при блокировке попыток быстро не подобрать
Это если она есть эта блокировка. Далеко не все этим заморачиваются. А еще можно каждую попытку делать с нового ip (пару раз у меня и такой щитшторм был, 4 с лишним часа долбились с логинами/паролями по ssh, хотя у меня вход только по ключу, и парольный сразу отбивается).
То есть Вы никогда-никогда по буковкам не промахиваетесь?
Вы таки не поверите, но парольные менеджеры изобрели много лет назад.
Далеко не все этим заморачиваются.
Ну так и выдывигайте претензии далеко не всем?
парольные менеджеры изобрели много лет назад.
...И тут обсуждение заходит на второй круг.
Я лично вообще не очень понимаю, о чем вы пытаетесь мне намекнуть.
Дальше то что?
Дальше-то всё: если пароль правильный, то Вы вошли!
Ссылки на мессаги в треде как-то хреново у меня работают, я не на то ответил.
Вы про космонавтов или про что?
Я про то, что недостаток всех схем, в которых требуется нечто, что Вы имеете, заключается в том, что это "нечто" можно у Вас изъять (очевидно или неочевидно), после чего творить любые непосредства от Вашего имени.
Если есть угроза типа "придут космонавты/пришельцы/итп и устроят взлом ректальным криптоанализом", то и меры нужно принимать соответствующие. Автоудаляемый криптоконтейнер на удаленном сервере, термитная смесь в технике, и т.п. Это все уже обжевано тысячу раз.
А в типовых случаях на это нечто ставится пароль, и все с этого нечто стирается после N попыток ввода (или это нечто блокируется намертво).
Перед тем, как пользоваться - ознакомьтесь с инструкцией, и все будет хорошо.
OpenSSH в OpenBSD проблеме не подвержен, так как в данной системе с 2001 года применяется механизм защиты, блокирующий подобные классы атак.
Уязвимость не затрагивает OpenBSD, так как в нём вместо syslog() из обработчика сигнала SIGALRM вызывается функция syslog_r(), специально созданная для асинхронного запуска.
Вот это хорошая часть новости.
Если жить в лесу, то тебя не убьет озверевший школьник с дробовиком )
Ну еще много других неприятностей не случится.
Но в сортир пожалуйста на улицу )
Возможно забыл повесить табличку "ищите аналогии", а возможно вы слишком тонкий трольь )
Там была табличка "случаи — они разные бывают!"
Хорошо бы в заголовок вынести про 32 бита
Последний раз 32 битным линуксом пользовался во времена пентиум 4 лет 20 назад, с 4го дебиана уже был амд64.
В оригинале ничего про то, что только 32 бит. Откуда инфа вообще (кроме того что PoC запустили)?
we believe that this signal handler race condition is exploitable on amd64
https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt
Я в теме не очень шарю - так и не смог понять - это уязвимость позволяющая повысить привелегии - будучи авторизованным как user выполнить код от рута. Или вообще выполнить код от рута, даже не будучи авторизованным?
Знаю людей которые ставят 32 битные ОС, из-за ограниченного ОЗУ.
Почему то нет в статье самого полезного - как теперь обновить только ssh на сервера ubuntu20-24 и аналогичных выпусках дебиан...
Через apt/aptitude, очевидно. Релиз пакетов для, как минимум, убунты 22-24 был еще вчера, а focal/bionic не подвержены.
$ sudo apt update && sudo apt install --only-upgrade openssh-server && sudo systemctl restart ssh
Случайно, конечно. Тут атака явно видно что теоретическая. Люди копали, нашли подозрительное место и на 32х битной системе, на локалхосте за 6 часов устроили эксплоит. Как оно будет работать удалённо - ещё никто не проверял, но статью опубликовать захотелось, чтобы получить медальку.
Одним из признаков попыток совершения атаки является появление в логе большого числа записей "Timeout before authentication".
Большое число это сколько?
На одном vps обнаружил уязвимую версию. Ubuntu 22.04.2 LTS.
Посмотрел логи, в общем уже месяц как минимум "Timeout before authentication" присутствует. Всего 4 недели хранятся логи, раньше не посмотреть.
В четырех недельных логах фиксируется от 98 до 300 событий "Timeout before authentication".
https://www.splunk.com/en_us/blog/security/cve-2024-6387-regresshion-vulnerability.html тут, например, обращают внимание на "возросшую частоту" появления таких событий
почему никто не пишет как проверить? я чтоли тут главный программист?
выполняем такую комманду ssh -V
смотрим результат OpenSSH_8.4p1
смотрим формулу: 4.4p1 <= OpenSSH < 8.5p1 — скорее всего, с ними всё нормально
всё опасность миновала...
Я правильно понимаю, что для Ubuntu и большинства систем с systemctl достаточно
sudo sed -r 's/^[[:space:]]*#[[:space:]]*LoginGraceTime[[:space:]]*[0-9]+[mhd]*/LoginGraceTime 15s/' -i /etc/ssh/sshd_config && sudo systemctl restart sshdНу и в остальных системах 7-8 то же самое? И это уже поможет даже если ssh старый, а если и новый, то не повредит?
А, ну и fail2ban установить, если кто ещё не
Мне одному странно, что на данный момент нет обновлений реп у debian ?
А шо Microsoft Windows молчит? - или там все гуд даже с уязвимой версией open-ssh - ?
В OpenSSH найдена критическая уязвимость, позволяющая удалённо выполнить код с правами root на серверах с Glibc