В моих опытах было так, что если телефон разблокируешь графическим ключом, а отпечаток предъявлял более 5 минут назад, то приложение всё-таки требует отпечаток/PIN.
Ура! Мне написали на почту из Telegram, что уязвимость так себе, слишком много мороки, но ошибку намереваются починить. Статус бага в их баг-трекере изменился на "готовится исправление".
Судя по пулл-реквесту на GitHub, там под капотом ведётся БД файлов, и разные файлы складываются в одну папку с приписыванием (1), (2) и так далее. То же самое можно увидеть и на Windows в папке загрузок Telegram. В этом конкретном месте кода по ошибке данная БД не использовалась, вот и возникла проблема, а в других местах предположительно всё было нормально. Но стоило ли рожать такие сложности вместо хэшей, вопрос конечно интересный!
С вашего позволения тезисно перескажу пост, чтобы более чётко артикулировать свою точку зрения.
Согласно POSIX, функция lockf должна возвращать ошибку, когда система замечает дедлок.
Linux реализует такой детектор дедлоков. И в документации, и в коде написано, что он может давать как false positive-ы, так и false negative-ы.
Я обнаружил случай, строго говоря, ещё одного false positive-а со стороны детектора дедлоков, не упомянутый в документации. Он касался распространённого сценария использования потоков в коде.
Я пожаловался на этот случай мейнтейнерам соответствующего кода.
У меня возникла смелая мысль, что раз детектор обладает такими интересными свойствами, то было бы хорошо по крайней мере поправить man, чтобы сказать: он плохо дружит с тредами.
На правку POSIX не претендую. Он здесь вообще почти не при делах.
Возможно, я плохо искал, но где можно найти информацию о том, куда/кому жаловаться на баги и где/кому задавать вопросы? Или это передаётся из уст в уста, как сейчас? Или нужно логическим путём понять, что жалоба на баг или вопрос -- это как недопатч, и потому если с патчами надо обращаться так-то, то и с репортами/вопросами нужно обращаться аналогично?
Из описания в MAINTAINERS следует:
Descriptions of section entries and preferred order
... B: URI for where to file bugs. A web-page with detailed bug filing info, a direct bug tracker link, or a mailto: URI. C: URI for chat protocol, server and channel where developers usually hang out, for example irc://server/channel.
Но в секции "FILE LOCKING (flock() and fcntl()/lockf())" нет ни B:, ни C:.
Что мне кажется нехорошим в сигналах, так это как они работают по умолчанию. Если какие-то сигналы приложению не нужны, оно должно явно сказать об этом. Если не скажет, то оно будет обрабатывать их не самым очевидным образом. Мне кажется, почти все сигналы по умолчанию было бы очевиднее всего игнорировать, а не падать в корку.
Я не считаю, что передача информации по SMS более надёжна, чем https.
Мой point был такой. Предположим, что злоумышленник получил доступ к аккаунту жертвы на сайте, но не имеет её второго фактора аутентификации — мобильного телефона, потому не может просто переслать себе деньги. Он решает оплатить что-то с помощью карты. Для этой задачи раньше ему нужно было подобрать больше десятичных цифр, чем после изменений в алгоритме. (Особенно с учётом того, что последние цифры являются полупубличной информацией, так что в теории их можно где-то найти.) Комбинаторная сложность в конкретном сценарии уменьшилась.
В комментариях пишут, что стоит, я сам не проверял.
Спасибо большое, вписал в свою статью и в комментах к той статье отписался!
Не выгуглил вашу статью, поэтому написал её по второму кругу: https://habr.com/ru/articles/878176/
Ещё жалоба на это поведение: https://www.banki.ru/services/questions-answers/question/681046/
Тут полностью солидарен!
В моих опытах было так, что если телефон разблокируешь графическим ключом, а отпечаток предъявлял более 5 минут назад, то приложение всё-таки требует отпечаток/PIN.
Ура! Мне написали на почту из Telegram, что уязвимость так себе, слишком много мороки, но ошибку намереваются починить. Статус бага в их баг-трекере изменился на "готовится исправление".
Судя по пулл-реквесту на GitHub, там под капотом ведётся БД файлов, и разные файлы складываются в одну папку с приписыванием (1), (2) и так далее. То же самое можно увидеть и на Windows в папке загрузок Telegram. В этом конкретном месте кода по ошибке данная БД не использовалась, вот и возникла проблема, а в других местах предположительно всё было нормально. Но стоило ли рожать такие сложности вместо хэшей, вопрос конечно интересный!
Отличная идея! Благодарю, переделал. Кажется, стало намного лучше.
С вашего позволения тезисно перескажу пост, чтобы более чётко артикулировать свою точку зрения.
Согласно POSIX, функция lockf должна возвращать ошибку, когда система замечает дедлок.
Linux реализует такой детектор дедлоков. И в документации, и в коде написано, что он может давать как false positive-ы, так и false negative-ы.
Я обнаружил случай, строго говоря, ещё одного false positive-а со стороны детектора дедлоков, не упомянутый в документации. Он касался распространённого сценария использования потоков в коде.
Я пожаловался на этот случай мейнтейнерам соответствующего кода.
У меня возникла смелая мысль, что раз детектор обладает такими интересными свойствами, то было бы хорошо по крайней мере поправить man, чтобы сказать: он плохо дружит с тредами.
На правку POSIX не претендую. Он здесь вообще почти не при делах.
Надеюсь, я ответил на ваш вопрос.
Спасибо за пояснение!
Возможно, я плохо искал, но где можно найти информацию о том, куда/кому жаловаться на баги и где/кому задавать вопросы? Или это передаётся из уст в уста, как сейчас? Или нужно логическим путём понять, что жалоба на баг или вопрос -- это как недопатч, и потому если с патчами надо обращаться так-то, то и с репортами/вопросами нужно обращаться аналогично?
Из описания в MAINTAINERS следует:
Но в секции "FILE LOCKING (flock() and fcntl()/lockf())" нет ни B:, ни C:.
Мой point был такой. Предположим, что злоумышленник получил доступ к аккаунту жертвы на сайте, но не имеет её второго фактора аутентификации — мобильного телефона, потому не может просто переслать себе деньги. Он решает оплатить что-то с помощью карты. Для этой задачи раньше ему нужно было подобрать больше десятичных цифр, чем после изменений в алгоритме. (Особенно с учётом того, что последние цифры являются полупубличной информацией, так что в теории их можно где-то найти.) Комбинаторная сложность в конкретном сценарии уменьшилась.