И когда писал тоже?
Как можно "забыть" функции инициализации (RAND_seed и иже с ней)?
Во всех примерах и мануалах — любая работа с ГСЧ начинается с этих функций. А тут их просто "забыли".
Нормально...
Не думаю, что вы что-то найдете в коммитах. Просто никто не мешает специалистам из АНБ позвонить и порекомендовать не заметить некоторые нюансы. Напомнив, о неразглашении факта разговора....
Лично с моей точки зрения, сам факт наличия в одном из самых популярных веб-языков вот таких вот фокусов :
опиралась на некриптостойкий и deprecated вызов RAND_pseudo_bytes.
(кстати, факт имеет место быть, я лично копался в исходниках когда исследовал свою проблему)
А так же — описанного в статье, а так же — отсутствия RAND_seed и RAND_poll выглядят ну очень подозрительно.
Это или просто вопиющая некомпетентность. Или ну очень уж избирательная слепота...
Подскажите номер коммита, я тоже полюбуюсь?
В данном случае, "закладкой" является не код, а отсутствие кода. Нет автоматических вызовов RAND_seed или RAND_poll при запуске скрипта. И вообще эти функции не реализованы. Хотя необходимы и являются важной частью OpenSSL API
Не в области силовой электроники, к тому же обеспечивающей питание такого устройства как холодильник.
И, если бы речь шла только о мелких ошибках — я бы и комментировать не стал. Но, в данном цикле статей грубые (чреватые в лучшем случае выходом из строя самого прибора, а в худшем — пожаром и/или выходом из строя питаемого устройства).
Причем, ошибки начинаются прямо с постановки задачи.
Мощность бытовых холодильников 100-200 Вт.
Запросы будут скромные.
Мощность – 200 Вт,
«Чистый» синус на выходе,
Ну и… хватит.
И ни слова о пусковых токах...
А ведь даже современные А+ имеют пусковую мощность порядка 1кВт, более старые — легко вылетают в диапазон 2-2,5кВт на пуске, причем довольно долго (несколько секунд)
Вообще, двигатели как нагрузка очень плохи, 5-7кратный пусковой ток в течение нескольких секунд это норма, а не исключение. Также, эта нагрузка является нелинейной, как правило — индуктивной. Но не обязательно. Может быть и емкостной (фазосдвигающий кондер на пусковой обмотке). И в том и в другом случае — это скачки тока, сдвиги фаз и реактивность.
Хуже того, сам холодильник имеет встроенную автоматику (те самые пусковые обмотки со своей автоматикой подключения / отключения), которая может довольно причудливым образом взаимодействовать с самопальным "инвертором" если он не имеет запаса мощности (из-за разных постоянных времени, в худшем случае можно словить резонанс)
Честно говоря, я бы посоветовал автору убрать пока весь цикл в черновики.
И выложить обратно с правками хотя-бы после испытаний устройства. Слишком много ошибок.
Учитывая опасность прибора (как в плане электрической опасности, так и пожарной) — мне кажется, что выкладывать настолько "сырые" идеи в паблик — не есть гут.
Мгм… Я думал это очевидно, но видимо надо отдельно уточнять.
Да, подписывание кода нифига не панацея и в этой механике овер-дофига багов.
Но! Речь-то идет об аппаратных закладках!
А это такая штука, что ее достаточно «спалить» любой системой защиты ровно один раз. А дальше уже спецы раскопают, откуда ноги растут.
А спалить на проверке подписей кода — как раз таки легко, в данном случае. То, что «хранится программа, которая может исполнять произвольные команды» — еще совершенно не значит, что мы можем внагляк ее модифицировать как хотим. CPU-то и чипсет нам (пока) не подчиняются, а, значит, проверяют и сверят читаемое, тем более перед запуском.
И если вдруг выяснится, что SSD отдает нам «левак» — будет ой. Причем, «ой» большого международного масштаба. И оно спецслужбам надо?
Закладки надо встраивать так, чтобы их было сложно отследить и еще сложнее доказать. А, простите, модификация потока данных идущего с/на устройство ловится вообще на раз. С точки зрения любой ОС — носители уже давно не являются доверенными источниками и тщательно проверяются, по мере сил конкретной ОС.
Чисто с потолка простейший пример — поставите вы в зеркало «троянский» носитель — и нормальный. И сходу словите расхождение. Последствия — понятны, я думаю?
Вы не путайте… Происхождение софтовых закладок еще никому не удалось доказать. Только подозрения, пусть и обоснованные.
А с железом — все ходы записаны… Кто имел доступ, когда и зачем…
Он бесспорный в том, что такая деятельность будет быстро обнаружена. А обнаружение подобной закладки — это засада почище Сноудена, т.к. чипы покупает не только Россия.
Эм, такие «внутренние цепи» способные «поглотить» нужный сигнал и есть приемник, вообще-то.
И, законы распространения и поглощения радиоволн довольно неплохо изучены.
И, да, размеры антенны очень даже имеют значение, сделать антенну для используемых сейчас частот внутри чипа, да еще и незаметно… Малореально, так скажем.
Мда. Название «Вредные советы» статье подошло бы лучше.
Кто не прыгал из окошка
Вместе с маминым зонтом,
Тот лихим парашютистом
Не считается пока.
Не лететь ему, как птице,
Над взволнованной толпой,
Не лежать ему в больнице
С забинтованной ногой.
Семантическая вёрстка, или семантический HTML-код, — это подход к созданию веб-страниц на языке HTML, основанный на использовании HTML-тегов в соответствии с их семантикой (предназначением)[1], а также предполагающий логичную и последовательную иерархию страницы
Ну вот как-бы иерархию-то тут и ломают… Это если чисто формально подходить.
А если подойти не с формальной точки зрения, а по сути и смыслу семантической верстки — то всё еще хуже.
Ведь для чего вообще в html5 ввели новые тэги? Да как раз таки для создания структуры и иерархии контента! Всё, другого назначения у всяких «article» и «head» нету. С технической точки зрения их функции прекрасно выполняют div'ы
И разрушение структуры путем удаления «head» есть прямое нарушение принципов семантической верстки.
Такого рода закладки сделать малореально и слишком палевно.
Замаскировать радиоприемник с обработчиком сигнала да еще и деструктивными функциями — в массовые продукты…
Бред.
Они-ж сами пользуются этими продуктами.
Мдя. Удаление head и body это, конечно, ну оооочень семантично и просто замечательно повышает читабельность…
Легкочитаемый, выразительный и правильный код важнее производительности.
И следом вообще офигительный пример, со стрелочными функциями, который понять не-автору, если он будет хоть на пару строк длиннее — вообще задница. Потому что алгоритм становится совершенно неявным. Человек — не машина. Понять, что и в какой последовательности будет происходить в этом примере — ни разу не просто. А уже попробовать разобраться дебагом в пошаговом режиме и вовсе невозможно.
Отдельное объявление функций используемых только в одном месте — и вовсе архиглупость, т.к. заставляет «листать» выше-ниже, использование Inline записи в данном случае и лаконичнее и понятнее — т.к. сразу видно что и где происходит.
[12, 5, 8, 130, 44].filter(function (val) { return val >= 10; }).map(function(val){return val * val});
Если вы не можете использовать методы Array.prototype, используйте рекурсию.
Омг… Супер-совет, для 10к элементов, например вообще отлично.
В общем, мне кажется переводчик чё-то попутал, и это был сборник советов как не надо делать.
Нет, конечно изучить и обдумать приведенные советы нужно. Но тут столько спорных моментов, что для новичков эта статья вообще крайне вредна (учитывая ее название «Руководство».
Да еще и массовое использование ES5 и CSS3, тоже штука хорошая — но только с оговорками и полифилами.
P.S. — на мой взгляд, спорными и обсуждаемыми тут являются почти все советы. Просто если на каждый поинт писать возражения — это будет уже статья, а не коммент…
Но, видимо, этот корпус позиционируется в немалой степени как транспортировочный, чтобы его выкинуть и купить такой, какой кому больше нравится.
За такие-то деньги???
Не. Это просто косяк производителя из серии «пипл схавает». Эти аппараты приобретаются не по потребительским качествам или характеристикам — а по совсем другим причинам (сертифицированность для спец-применний и т.п.). Вот разработчики и «забили» на всякие, с их точки зрения «мелочи»
Кстати, во многих случая заменять корпус будет нельзя, как раз таки, если комплекс сертифицирован ФСТЭК для всяких… спец-применений. В этом случае даже мышку и то заменять нельзя. Сертифицируется комплекс целиком, причем каждый экземпляр получает свой паспорт. Тем более БП (БП является мощным источником побочных излучений)
Ну вообще-то, в современной ОС (и на плате с нормальным БИОСом) вы не только не сможете ничего исполнить — но еще и моментально «спалитесь» — ибо код подписывается и подписи обязательно проверяются при загрузке в память.
Но это далеко не тоже самое, что произвольное исполнение команд. И далеко не все шины в принципе его имеют. Чаще всего есть только та или иная разновидность DMA
В любом случае — еще раз сделаю акцент на самом первом моем ответе "мешает тот факт, что вся периферия контролируется чипсетом"
Ключевое слово здесь «мешает». Это не тождественно «делает невозможным», но сводит вероятность практической реализации подобной атаки к значениям близким к нулю.
Потому что:
а) любой подобный бэкдор аппаратно-зависим и будет работать только на совершенно конкретной железке
б) с большой долей вероятности подобный «левый» траффик будет рано или поздно обнаружен, т.к. контроль всех шин и, что важно! таймингов и памяти остается за ЦПУ и чипсетом, и любая самодеятельность периферии рано или поздно вылезет при отладке.
Тот же SATA не имеет прямого доступа к NIC, следовательно — смысла встраивать туда именно бэкдор нет никакого. Работы много — толку мало.
Вот DOS — да, легко. Даже слишком легко. Отловить во входящем на SATA потоке данных команду «убей себя» и исполнить ее — элементарно.
В шум — можно.
Почитайте вот тут, например. Вообще по ссылке — это статья о методах взлома шифров, но в ней как раз и перечисляются основные «побочные каналы» утечки информации. Посчитайте сколько их известно. А потом — смело умножайте на 5 чтобы прикинуть, сколько их известно спецслужбам…
Я уже писал выше — сложно обнаружить «левые» данные добавляемые в легальный сетевой траффик.
Т.е. основные цели для встраивания бэкдора — чипсет и ЦПУ, т.к. они имеют более-менее свободный доступ к памяти и периферии и доступ к сетевым интерфейсам.
А подмешивание дополнительной информации к «легально» передаваемым данным вообще крайне трудно обнаружить. Т.к. для передачи могут использоваться не только данные как таковые, а, например, тайминги между пакетами. Или, скажем, намеренные потери определенных входящих пакетов при распаковке в NIC на PHY уровне и т.д. Вариантов — огромное число.
Основной принцип — передача полезного сигнала под видом шума. Любые помехи в сигнале тоже являются частью сигнала и могут нести полезную информацию, если приемник (ЦРУ в лице любого популярного сетевого сервиса) и передатчик (в лице бэкдора) согласовали правила их обработки.
Как можно "забыть" функции инициализации (RAND_seed и иже с ней)?
Во всех примерах и мануалах — любая работа с ГСЧ начинается с этих функций. А тут их просто "забыли".
Нормально...
Лично с моей точки зрения, сам факт наличия в одном из самых популярных веб-языков вот таких вот фокусов :
(кстати, факт имеет место быть, я лично копался в исходниках когда исследовал свою проблему)
А так же — описанного в статье, а так же — отсутствия RAND_seed и RAND_poll выглядят ну очень подозрительно.
Это или просто вопиющая некомпетентность. Или ну очень уж избирательная слепота...
В данном случае, "закладкой" является не код, а отсутствие кода. Нет автоматических вызовов RAND_seed или RAND_poll при запуске скрипта. И вообще эти функции не реализованы. Хотя необходимы и являются важной частью OpenSSL API
И, если бы речь шла только о мелких ошибках — я бы и комментировать не стал. Но, в данном цикле статей грубые (чреватые в лучшем случае выходом из строя самого прибора, а в худшем — пожаром и/или выходом из строя питаемого устройства).
Причем, ошибки начинаются прямо с постановки задачи.
И ни слова о пусковых токах...
А ведь даже современные А+ имеют пусковую мощность порядка 1кВт, более старые — легко вылетают в диапазон 2-2,5кВт на пуске, причем довольно долго (несколько секунд)
Вообще, двигатели как нагрузка очень плохи, 5-7кратный пусковой ток в течение нескольких секунд это норма, а не исключение. Также, эта нагрузка является нелинейной, как правило — индуктивной. Но не обязательно. Может быть и емкостной (фазосдвигающий кондер на пусковой обмотке). И в том и в другом случае — это скачки тока, сдвиги фаз и реактивность.
Хуже того, сам холодильник имеет встроенную автоматику (те самые пусковые обмотки со своей автоматикой подключения / отключения), которая может довольно причудливым образом взаимодействовать с самопальным "инвертором" если он не имеет запаса мощности (из-за разных постоянных времени, в худшем случае можно словить резонанс)
И выложить обратно с правками хотя-бы после испытаний устройства. Слишком много ошибок.
Учитывая опасность прибора (как в плане электрической опасности, так и пожарной) — мне кажется, что выкладывать настолько "сырые" идеи в паблик — не есть гут.
Да, подписывание кода нифига не панацея и в этой механике овер-дофига багов.
Но! Речь-то идет об аппаратных закладках!
А это такая штука, что ее достаточно «спалить» любой системой защиты ровно один раз. А дальше уже спецы раскопают, откуда ноги растут.
А спалить на проверке подписей кода — как раз таки легко, в данном случае. То, что «хранится программа, которая может исполнять произвольные команды» — еще совершенно не значит, что мы можем внагляк ее модифицировать как хотим. CPU-то и чипсет нам (пока) не подчиняются, а, значит, проверяют и сверят читаемое, тем более перед запуском.
И если вдруг выяснится, что SSD отдает нам «левак» — будет ой. Причем, «ой» большого международного масштаба. И оно спецслужбам надо?
Закладки надо встраивать так, чтобы их было сложно отследить и еще сложнее доказать. А, простите, модификация потока данных идущего с/на устройство ловится вообще на раз. С точки зрения любой ОС — носители уже давно не являются доверенными источниками и тщательно проверяются, по мере сил конкретной ОС.
Чисто с потолка простейший пример — поставите вы в зеркало «троянский» носитель — и нормальный. И сходу словите расхождение. Последствия — понятны, я думаю?
А с железом — все ходы записаны… Кто имел доступ, когда и зачем…
Эм, такие «внутренние цепи» способные «поглотить» нужный сигнал и есть приемник, вообще-то.
И, законы распространения и поглощения радиоволн довольно неплохо изучены.
И, да, размеры антенны очень даже имеют значение, сделать антенну для используемых сейчас частот внутри чипа, да еще и незаметно… Малореально, так скажем.
©Григорий Остер
Ну вот как-бы иерархию-то тут и ломают… Это если чисто формально подходить.
А если подойти не с формальной точки зрения, а по сути и смыслу семантической верстки — то всё еще хуже.
Ведь для чего вообще в html5 ввели новые тэги? Да как раз таки для создания структуры и иерархии контента! Всё, другого назначения у всяких «article» и «head» нету. С технической точки зрения их функции прекрасно выполняют div'ы
И разрушение структуры путем удаления «head» есть прямое нарушение принципов семантической верстки.
Замаскировать радиоприемник с обработчиком сигнала да еще и деструктивными функциями — в массовые продукты…
Бред.
Они-ж сами пользуются этими продуктами.
И следом вообще офигительный пример, со стрелочными функциями, который понять не-автору, если он будет хоть на пару строк длиннее — вообще задница. Потому что алгоритм становится совершенно неявным. Человек — не машина. Понять, что и в какой последовательности будет происходить в этом примере — ни разу не просто. А уже попробовать разобраться дебагом в пошаговом режиме и вовсе невозможно.
Отдельное объявление функций используемых только в одном месте — и вовсе архиглупость, т.к. заставляет «листать» выше-ниже, использование Inline записи в данном случае и лаконичнее и понятнее — т.к. сразу видно что и где происходит.
Омг… Супер-совет, для 10к элементов, например вообще отлично.
В общем, мне кажется переводчик чё-то попутал, и это был сборник советов как не надо делать.
Нет, конечно изучить и обдумать приведенные советы нужно. Но тут столько спорных моментов, что для новичков эта статья вообще крайне вредна (учитывая ее название «Руководство».
Да еще и массовое использование ES5 и CSS3, тоже штука хорошая — но только с оговорками и полифилами.
P.S. — на мой взгляд, спорными и обсуждаемыми тут являются почти все советы. Просто если на каждый поинт писать возражения — это будет уже статья, а не коммент…
За такие-то деньги???
Не. Это просто косяк производителя из серии «пипл схавает». Эти аппараты приобретаются не по потребительским качествам или характеристикам — а по совсем другим причинам (сертифицированность для спец-применний и т.п.). Вот разработчики и «забили» на всякие, с их точки зрения «мелочи»
Кстати, во многих случая заменять корпус будет нельзя, как раз таки, если комплекс сертифицирован ФСТЭК для всяких… спец-применений. В этом случае даже мышку и то заменять нельзя. Сертифицируется комплекс целиком, причем каждый экземпляр получает свой паспорт. Тем более БП (БП является мощным источником побочных излучений)
Но это далеко не тоже самое, что произвольное исполнение команд. И далеко не все шины в принципе его имеют. Чаще всего есть только та или иная разновидность DMA
В любом случае — еще раз сделаю акцент на самом первом моем ответе "мешает тот факт, что вся периферия контролируется чипсетом"
Ключевое слово здесь «мешает». Это не тождественно «делает невозможным», но сводит вероятность практической реализации подобной атаки к значениям близким к нулю.
Потому что:
а) любой подобный бэкдор аппаратно-зависим и будет работать только на совершенно конкретной железке
б) с большой долей вероятности подобный «левый» траффик будет рано или поздно обнаружен, т.к. контроль всех шин и, что важно! таймингов и памяти остается за ЦПУ и чипсетом, и любая самодеятельность периферии рано или поздно вылезет при отладке.
Тот же SATA не имеет прямого доступа к NIC, следовательно — смысла встраивать туда именно бэкдор нет никакого. Работы много — толку мало.
Вот DOS — да, легко. Даже слишком легко. Отловить во входящем на SATA потоке данных команду «убей себя» и исполнить ее — элементарно.
Почитайте вот тут, например. Вообще по ссылке — это статья о методах взлома шифров, но в ней как раз и перечисляются основные «побочные каналы» утечки информации. Посчитайте сколько их известно. А потом — смело умножайте на 5 чтобы прикинуть, сколько их известно спецслужбам…
Т.е. основные цели для встраивания бэкдора — чипсет и ЦПУ, т.к. они имеют более-менее свободный доступ к памяти и периферии и доступ к сетевым интерфейсам.
А подмешивание дополнительной информации к «легально» передаваемым данным вообще крайне трудно обнаружить. Т.к. для передачи могут использоваться не только данные как таковые, а, например, тайминги между пакетами. Или, скажем, намеренные потери определенных входящих пакетов при распаковке в NIC на PHY уровне и т.д. Вариантов — огромное число.
Основной принцип — передача полезного сигнала под видом шума. Любые помехи в сигнале тоже являются частью сигнала и могут нести полезную информацию, если приемник (ЦРУ в лице любого популярного сетевого сервиса) и передатчик (в лице бэкдора) согласовали правила их обработки.