Мне кажется, что подобными запросами должен заниматься не суд, это должны быть какие-то досудебные процедуры (собственно — сбор доказательств). А потом уже, имея официальный ответ или какие-то другие улики (кто и за что блокировал) подавать иск в суд с конкретной претензией конкретному органу.
иск петербургского ООО «Инвестори» к Роскомнадзору о взыскании 5 млн руб. убытков из-за ошибочной блокировки сайта во время нормативных действий ведомства против мессенджера Telegram.
То есть взыскивающей стороне нужно:
с одной стороны надо доказать что блокировка именно Tg, а не, например, вашего сайта или соседнего сайта на shared-хостинге
с другой стороны надо доказать, что блокировка была инициирована именно Роскомнадзором (тут: "ЦБ — седьмой по счету государственный орган, который получит право вносить сайты в реестр запрещенной информации").
То есть надо точно знать кто и за что производил блокировку, что бы знать с кого спрашивать. А в текущих реалиях, как мне кажется, это крайне сложно.
Эмулируемые Android-приложения на Sailfish получают внизу стандартную кнопку назад. Нативные Sailfish-приложения обходятся без нее: используются swipe или навигацию между последовательными страницами. Интересно насколько удобно для пользователя чистое Qt приложением, если вообще не используется Silica.
Продолжение следует.
Если есть возможность, выложите (на github например), минимальный скелет такого приложения (с разными контроллами, наполненными тестовыми данными), что бы иметь возможность его повертеть в руках.
Автор мог бы пояснить чем именно «слабость» MD5 делает «Шифрование ключа по умолчанию в OpenSSH хуже его отсутствия»?
По тексту автор утверждает, что есть хороший шанс восстановить пароль шифрования в открытом виде:
И, поскольку это одна из выученных на память комбинаций, велика вероятность, что пользователь уже применял ее где-либо еще. Возможно, она даже совпадает с пользовательским паролем от устройства. Угадать его вполне реально (слишком ненадежная у него формирующая функция), и если пароль станет известен, можно проверить его наверняка по публичному ключу.
Что приведет к тому, что будет скомпрометирован не только ключ SSH, о и другие аккаунты, которые имеют тот же пароль.
Да, как и приведенный в пример в статье CVE-2015-2433: утечка только раскрывает адрес win32k.sys. Но именно эта уязвимость стала одним из звеньев в 0-day цепочке по локальному повышению привилегий.
Если рассматривать более конкретно, то раскрыв адрес объекта в куче процесс косвенно раскрывает расположение самой кучи в своем адресном пространстве, что работает против ASLR.
Да, оба процесса пользовательские. Криминально раскрывать адреса привилегированного процесса (работающего от лица пользователя SYSTEM) непривилегированному, который может работать и от гостя. Локальное повышение привилегий (особенно при условии запуска с отсутствием прав администратора, например — в песочнице) через уязвимый системный сервис не редкость.
А что именно? Про случай из собственной практики? Про него, собственно, рассказать больше и нечего: привилегированный системный сервис хранил коллекцию объектов, выделенных по new (динамическая память). Это коллекция сериализовывалась в GUI-процесс, запущенный от лица пользователя, вошедшего в систему. А в качестве идентификатора объекта в коллекции (GUI может давать некоторые команды на манипулирование объектами в коллекции) использовался непосредственный адрес объекта. Что, собственно, раскрывало привилегированному GUI адреса кучи привилегированного сервиса. В качестве фикса идентификатором был выбран возрастающий 64-х разрядный счетчик, который инкрементировался при создании каждого нового объекта для коллекции.
Да, думаю автор первый (слишком примитивный) пример взял из головы, а не из собственной практики:
Утечки через неинициализированную локальную переменную на практике не очень распространены: с одной стороны современные компиляторы часто обнаруживают и предупреждают о таких проблемах, с другой стороны подобные утечки являются функциональными ошибками, которые могут быть обнаружены во время разработки или тестирования.
Было бы интересно почитать отдельную статью с деталями реализации технических мер: что передается, по каким каналам, как верифицируется.
Да и про остальные технические особенности системы было бы интересно узнать.
Ага, теперь понял про что речь.
Интересный случай, но деталей про одноразовые/аварийные коды не знаю. Но, получается, СМС от банка с детализацией операции является более надежным вторым фактором (при условии отсутствия компрометации телефона, конечно). Соотвественно, если на перевод вдруг запрашивается одноразовые/аварийные код — хороший повод задуматься о том, что что-то не так.
Если код приходит по СМС, то вместе с кодом банк высылает реквизиты операции, в которых будет указан реальный (а не отображаемый браузером) счет и наименование получателя (см. пример выше). Их и нужно перепроверить перед вводом одноразового кода.
Мне кажется, что подобными запросами должен заниматься не суд, это должны быть какие-то досудебные процедуры (собственно — сбор доказательств). А потом уже, имея официальный ответ или какие-то другие улики (кто и за что блокировал) подавать иск в суд с конкретной претензией конкретному органу.
С моей дилетантской точки зрения все сложнее:
То есть взыскивающей стороне нужно:
То есть надо точно знать кто и за что производил блокировку, что бы знать с кого спрашивать. А в текущих реалиях, как мне кажется, это крайне сложно.
Спасибо, интересный опыт
Что используете в качестве мессенджера?
Ага, как и линки с советами от чистого сердца:
А что в ней пиратского-то?
Ответил человек из Яндекса)) Интересно, они с техническими вопросами все в Гугл ходят?
Эмулируемые Android-приложения на Sailfish получают внизу стандартную кнопку назад. Нативные Sailfish-приложения обходятся без нее: используются swipe или навигацию между последовательными страницами. Интересно насколько удобно для пользователя чистое Qt приложением, если вообще не используется Silica.
Если есть возможность, выложите (на github например), минимальный скелет такого приложения (с разными контроллами, наполненными тестовыми данными), что бы иметь возможность его повертеть в руках.
Интересно было бы взглянуть как это выглядит на Sailfish. Может добавите gif-демо такого приложения в статью?
По тексту автор утверждает, что есть хороший шанс восстановить пароль шифрования в открытом виде:
Что приведет к тому, что будет скомпрометирован не только ключ SSH, о и другие аккаунты, которые имеют тот же пароль.
.
Да, как и приведенный в пример в статье CVE-2015-2433: утечка только раскрывает адрес win32k.sys. Но именно эта уязвимость стала одним из звеньев в 0-day цепочке по локальному повышению привилегий.
Если рассматривать более конкретно, то раскрыв адрес объекта в куче процесс косвенно раскрывает расположение самой кучи в своем адресном пространстве, что работает против ASLR.
Да, оба процесса пользовательские. Криминально раскрывать адреса привилегированного процесса (работающего от лица пользователя SYSTEM) непривилегированному, который может работать и от гостя. Локальное повышение привилегий (особенно при условии запуска с отсутствием прав администратора, например — в песочнице) через уязвимый системный сервис не редкость.
Ядра до Windows Vista (2003, XP, …) собирались практически без оптимизации. Возможно подобная позорная ошибка была именно в ядрах старых ОС.
А что именно? Про случай из собственной практики? Про него, собственно, рассказать больше и нечего: привилегированный системный сервис хранил коллекцию объектов, выделенных по new (динамическая память). Это коллекция сериализовывалась в GUI-процесс, запущенный от лица пользователя, вошедшего в систему. А в качестве идентификатора объекта в коллекции (GUI может давать некоторые команды на манипулирование объектами в коллекции) использовался непосредственный адрес объекта. Что, собственно, раскрывало привилегированному GUI адреса кучи привилегированного сервиса. В качестве фикса идентификатором был выбран возрастающий 64-х разрядный счетчик, который инкрементировался при создании каждого нового объекта для коллекции.
Да, думаю автор первый (слишком примитивный) пример взял из головы, а не из собственной практики:
Было бы интересно почитать отдельную статью с деталями реализации технических мер: что передается, по каким каналам, как верифицируется.
Да и про остальные технические особенности системы было бы интересно узнать.
Ага, теперь понял про что речь.
Интересный случай, но деталей про одноразовые/аварийные коды не знаю. Но, получается, СМС от банка с детализацией операции является более надежным вторым фактором (при условии отсутствия компрометации телефона, конечно). Соотвественно, если на перевод вдруг запрашивается одноразовые/аварийные код — хороший повод задуматься о том, что что-то не так.
Если код приходит по СМС, то вместе с кодом банк высылает реквизиты операции, в которых будет указан реальный (а не отображаемый браузером) счет и наименование получателя (см. пример выше). Их и нужно перепроверить перед вводом одноразового кода.
Это не совсем так. Например, Сбербанк присылает СМС с реквизитами перевода и просьбой внимательно проверить их.
Нагугленный пример:
Понимаю, что не многие реально проверяют, но радует что банк (думаю, что не только Сбер) предоставляет такую возможность.