Дело ваше, но эта «война буллшитов» всегда заканчивается одинаково — на рынке не остается нормальных продуктов, т.к. все вообще начинают декларировать 100% защиту от всего, интеграцию со всем, встроенную кофе-машину и кнопку «сделай мне зашибись!». Как с антивирусами сейчас.
Если вы будете писать «мы устранили уязвимости в открытом ПО», не удивляйтесь, что от вас отвернутся и те, кто действительно ищет и устраняет уязвимости, и те, кто разрабатывает открытое ПО. Буллшит рекламный не любит никто, и даже если конкуренты уже вовсю обмазываются им — присоединяться, на мой взгляд, не стоит.
С этим я не спорю, это правильное применение статического анализатора и я тоже применяю его для тех же целей. Спорю я с использованием в рекламных материалах слова «vulnerability», которое слишком сильное в данном случае. Плюс еще с тем, что «дефект безопасности» — это хороший термин для CWE. Дефект, на самом деле, не безопасности, а ПО, и ищет анализатор дефекты/недостатки/изъяны/слабости именно в коде, а не в «безопасности».
Я на одной стороне с разработчиками, но считаю, что продавать статический анализатор с лозунгом «stop vulnerabilities», и использовать это очень сильное слово в статьях и пулл-реквестах — хороший способ создать о себе негативное впечатление продавцов воздуха.
Нельзя называть уязвимостью то, что не участвует в атаке. Критерий — наличие PoC, если а PoC нет, это слабое место, недостаток (а не «дефект безопасности», чтобы не значил этот странный термин), что угодно, только не уязвимость.
Я понимаю, что вы хотите сказать, и даже понимаю, зачем именно, но называть любую обнаруженную «weakness» словом «vulnerability» — это буллшит чистой воды, потому что это максимум «potential security issue».
Мужики, у вас отличный продукт без дураков, и хорошая рекламная стратегия (была, по крайней мере) со всеми этими статьями, но не скатывайтесь, прошу вас, в рекламу змеинного масла.
PVS-Studio находит не «уязвимости», а «слабые места в коде, которые могут привести (или не привести) к уязвимости». По настоящему с уязвимостями борятся технологии предотвращения эксплуатации вроде VBS, CFG, RAP, и т.п. Вот слайды с недавнего доклада специалистов из Microsoft о них.
Я не о том, что вы их не ищите, а о том, чтобы маркировать их сильнее в списке ошибок, потому что их потенциальный вред сильнее. Хотя бы не по умолчанию, а в качестве настройки.
Вы пишете слово «vulnerability» на своих КДПВ, хотя речь идет о «weakness». Первое — это то, что на русский язык переводится словом «уязвимость», она же немного слабее «security issue», т.е. «проблема безопасности». Второе — это то, что вы переводите как «дефект», а я — как «слабость» или «недостаток». Словосочетание «дефект безопасности», в которое превратилось «weakness» — оно очень странное, и я действительно путаюсь в нем. «Дефект», мне кажется — намного более сильное слово, чем «слабость» или «недостаток», но я могу ошибаться. «Потенциальная проблема безопасности» — вот что такое «weakness», на мой взгляд.
СиПроВер, пожалуйста, не путайте CWE и CVE, хоть оба списка и ведет одна и таже MITRE, но именно к настоящим проблемам безопасности первый список имеет весьма опосредованное отношение.
Для того, чтобы ошибка в программе стала настоящей проблемой безопасности, она должна быть эксплуатируема, т.е. для нее должно быть найден способ использования в целях, которые ставит перед собой атакующий. И пока такой способ не найден, все эти вышеописанные вещи так и остаются «слабостями», а не проблемами безопасности. Широко известный в узких кругах журнал PoC||GTFO не зря называется именно так. ;)
Если вы действительно хотите помочь пометить серьезные проблемы, связанные с безопасностью, начните предупреждать громче, чем обычно (т.е. с приоритетом 0 вместо 1 и красным цветом) хотя бы о следующих вещах:
use-after-free, в прямых руках это практически гарантированный WWW с последующии грабежом, убийством и надругательством над гусями
проблемах с потоком управления (goto fail)
чтении неинициализированных переменных и областей памяти (Heartbleed/Cloudbleed) и записи за границы массивов (слишком длинный список примеров, чтобы его тут приводить)
Ну мы тут сейчас о синдороме самозванца, а если никто не следит за процессами, и одна задача — заработать денег, успев до кризиса, то ему, мне кажется, негде возникать. Ты и так сам себе менеджер, сам себе постановщик задач, сам себе разработчик и сам себе продажник, куда тут до мыслей про то, что ты ничего не понимаешь и отстал от технологий…
Как мне работается в Эппле — хорошо, пишу код, допускаю ошибки, исправляю их, учусь. ВУЗ заканчивал, кстати, провинциальный (РИИ, филлиал АлтГТУ в г. Рубцовске) с теми же стариками, прологом, паскалем и фокспро. В окружении теперь очень много очень сильных специалистов, поэтому синдром самозванца тоже иногда «подъедает» и меня, но работы столько, что заниматься рефлексией некогда — «время идет, срок уже близенько».
«Если отладка — это процесс удаления багов из кода, то программирование должно быть процессом их туда добавления». Понятно, что всплывет, и может быть даже принесет какие-то убытки, только вот это все не важно, если задача все-таки решена. Ошибки — нормальный компонент рабочего процесса, и чем раньше их получается обнаружить и признать, тем дешевле они обходятся. Да и в прикладном (а уж тем более веб-) программировании допустить какую-то непоправимую ошибку все же несколько сложнее, чем в других областях.
if you think your bugs are bad: I just wasted almost two weeks because our DMA engine and our CPU disagreed about endianness of SDRAM words
Полезный совет. Нет, серьезно, самым действенным способом справиться с синдромом самозванца является, на мой взгляд, написание кода и решение тех задач, которые перед вами ставят. Справляешься с задачами в срок и с нужным качеством — уже красавчик и молодец, а никакой не самозванец, что бы ты сам про себя не думал.
Автор живет в мире космических единорогов, где юникод поддерживается всеми устройствами и вводится в любые поля прямо из воображения.
На самом деле, ввести что-то, кроме 7-битного ASCII до сих пор очень сложно на абсолютном большинстве сайтов, устройств и всего остального, и добавлять с свои пароли юникод означает практически гарантированно остаться без возможности входа на любой хоть немного нестандартной/несовременной системе.
Один раз вам устроили скандал, второй — ваши говорящие головы поизвинялись, а по сути ничего не изменилось и скорее всего не изменится. Прошу прощения, но идите к черту со своими бэкдорами, которые нельзя удалить без замены SoC, доверия к вам и вашим системам больше нет.
Считаю, что заниматься нужно тем, что вам интересно, а не выбирать ЯП по количеству вакансий и уровню хайпа. Есть много интересной работы и на чистом С, и на Эрланге, и на Хаскеле тоже, и она там, зачастую, значительно лучше оплачивается даже со старта, чем фронтэнд на JS.
А первую работу можно сделать себе самому: начните OpenSource-проект или поучаствуйте в существующем, попробуйте себя в GSoC во время обучения, попытайтесь решить какую-то задачу в той области, которая вам интересна, а потом автоматизировать это решение — так вы и знания свои углубите и расширите, и сообществу поможете.
Сообщество, кстати, это очень важно, старайтесь не программировать «в стол», а писать статьи, общаться на тематических форумах и в списках рассылки, отвечать на вопросы новичков там же и на SO, в общем, не замыкайтесь в себе в надежде через N месяцев выдать на гора идеальный продукт, решающий все проблемы.
Слишком подробнее не могу, тем более на данной модели (стараюсь не покупать технику Lenovo как заведомо забэкдоренную), но можно понять общую схему работы из этой и вот этой статей.
Прошу прощения, взял не тот файл, от Y910 AIO. Впрочем, в прошивке ноутбука Y910 ситуация примерно такая же, плюс сильное подозрение вызывает PEI-модуль с интересным именем SecureBackDoorPeim.
В статье не упомянут предустановленный и сопротивляющийся удалению бэкдор Computrace, который из прошивки этого ноута выдрать хоть и можно (ибо Intel BootGuard на нем отключен), но весьма непросто, и переустановка ОС начисто от него не спасает, т.к. для автоматизированной повторной установки бэкдора используется ACPI-таблица WPBT. Скандал прошлогодний Lenovo ничему не научил, видимо.
Выкинуть то можно, только в этом случае видеокарта совсем перестанет работать, скорее всего. Если опции отключения CSM нет, значит прошивка, по мнению производителя не готова работать в UEFI-only режиме. Т.е. она в нем либо не тестировалась совсем, либо не может работать по разным причинам (рантайм-сервисы сломали и не смогли починить, например). Лучшее, что тут можно сделать — заменить плату на более новую либо пользоваться легаси-режимом дальше (ОС все равно потом переинициализирует как нужно).
Если вы будете писать «мы устранили уязвимости в открытом ПО», не удивляйтесь, что от вас отвернутся и те, кто действительно ищет и устраняет уязвимости, и те, кто разрабатывает открытое ПО. Буллшит рекламный не любит никто, и даже если конкуренты уже вовсю обмазываются им — присоединяться, на мой взгляд, не стоит.
Я на одной стороне с разработчиками, но считаю, что продавать статический анализатор с лозунгом «stop vulnerabilities», и использовать это очень сильное слово в статьях и пулл-реквестах — хороший способ создать о себе негативное впечатление продавцов воздуха.
Я понимаю, что вы хотите сказать, и даже понимаю, зачем именно, но называть любую обнаруженную «weakness» словом «vulnerability» — это буллшит чистой воды, потому что это максимум «potential security issue».
Мужики, у вас отличный продукт без дураков, и хорошая рекламная стратегия (была, по крайней мере) со всеми этими статьями, но не скатывайтесь, прошу вас, в рекламу змеинного масла.
PVS-Studio находит не «уязвимости», а «слабые места в коде, которые могут привести (или не привести) к уязвимости». По настоящему с уязвимостями борятся технологии предотвращения эксплуатации вроде VBS, CFG, RAP, и т.п. Вот слайды с недавнего доклада специалистов из Microsoft о них.
Для того, чтобы ошибка в программе стала настоящей проблемой безопасности, она должна быть эксплуатируема, т.е. для нее должно быть найден способ использования в целях, которые ставит перед собой атакующий. И пока такой способ не найден, все эти вышеописанные вещи так и остаются «слабостями», а не проблемами безопасности. Широко известный в узких кругах журнал PoC||GTFO не зря называется именно так. ;)
Если вы действительно хотите помочь пометить серьезные проблемы, связанные с безопасностью, начните предупреждать громче, чем обычно (т.е. с приоритетом 0 вместо 1 и красным цветом) хотя бы о следующих вещах:
Как мне работается в Эппле — хорошо, пишу код, допускаю ошибки, исправляю их, учусь. ВУЗ заканчивал, кстати, провинциальный (РИИ, филлиал АлтГТУ в г. Рубцовске) с теми же стариками, прологом, паскалем и фокспро. В окружении теперь очень много очень сильных специалистов, поэтому синдром самозванца тоже иногда «подъедает» и меня, но работы столько, что заниматься рефлексией некогда — «время идет, срок уже близенько».
На самом деле, ввести что-то, кроме 7-битного ASCII до сих пор очень сложно на абсолютном большинстве сайтов, устройств и всего остального, и добавлять с свои пароли юникод означает практически гарантированно остаться без возможности входа на любой хоть немного нестандартной/несовременной системе.
Один раз вам устроили скандал, второй — ваши говорящие головы поизвинялись, а по сути ничего не изменилось и скорее всего не изменится. Прошу прощения, но идите к черту со своими бэкдорами, которые нельзя удалить без замены SoC, доверия к вам и вашим системам больше нет.
А первую работу можно сделать себе самому: начните OpenSource-проект или поучаствуйте в существующем, попробуйте себя в GSoC во время обучения, попытайтесь решить какую-то задачу в той области, которая вам интересна, а потом автоматизировать это решение — так вы и знания свои углубите и расширите, и сообществу поможете.
Сообщество, кстати, это очень важно, старайтесь не программировать «в стол», а писать статьи, общаться на тематических форумах и в списках рассылки, отвечать на вопросы новичков там же и на SO, в общем, не замыкайтесь в себе в надежде через N месяцев выдать на гора идеальный продукт, решающий все проблемы.
Скандал прошлогодний Lenovo ничему не научил, видимо.