Уязвимости неуязвимого Linux

    Cреди обычных пользователей и даже ИТ-сотрудников распространено убеждение в повышенной безопасности ОС семейства Linux по сравнению с «дырявой виндой» и «попсовой макосью». Однако, как показало наше исследование, открытость исходников не избавляет Linux от ошибок и уязвимостей, которые несут риски, связанные с безопасностью. В этом посте мы рассмотрим, почему Linux стал привлекательной мишенью для злоумышленников, а также обсудим основные угрозы и риски, связанные с этой операционной системой. 

    Фото: Trend Micro
    Фото: Trend Micro

    По данным Linux Foundation, ещё в 2017 году под управлением Linux работали 90% клиентских ресурсов у всех облачных провайдеров, причём в девяти из десяти случаев и сам облачный провайдер использовал в качестве основной ОС именно Linux. Но облаками дело не ограничивается: 82% всех выпущенных в мире смартфонов также используют Linux, а среди суперкомпьютеров доля Linux составляет 99%. 

    По мере того, как предприятия и организации переносят данные в облака, где царит Linux, вектор интереса злоумышленников смещается на слабые места этого семейства операционных систем: уязвимости, неправильные настройки и пробелы в безопасности, а также вредоносное ПО. 

    Уязвимости

    Одним из самых распространённых методов проникновения в систему — использование уязвимостей. Отсутствие процедур управления и отслеживания уязвимостей, не говоря уже об отсутствии выстроенных процессов установки исправлений, может привести к тому, что системы окажутся беззащитными после обнаружения очередной уязвимости и публикации эксплойта для неё. Часто эксплойт публикуют уже через несколько часов после её обнаружения. Для Linux эта проблема более критична, поскольку открытый исходный код позволяет быстро найти проблемную функцию и написать код для эксплуатации ошибки.

    Количество критических уязвимостей в различных дистрибутивах за 2015-2020 год. Источник: Trend Micro
    Количество критических уязвимостей в различных дистрибутивах за 2015-2020 год. Источник: Trend Micro

    Важно отметить, что значительное количество уязвимостей в сервисе или платформе не обязательно означает, что эти уязвимости обязательно несут существенный риск.


    Каждый производитель дистрибутива Linux выполняет свою процедуру обработки уязвимостей. В то время как исправления от вендоров приходят в разное время, заплатки upstream, будь то оригинальный пакет или исходный код утилиты, появляются первыми. Вендоры Linux отвечают за исправление уязвимостей в таких компонентах, как ядро, утилиты и пакеты. В 2019 году Red Hat исправил более 1000 CVE в своём дистрибутиве Red Hat Enterprise Linux (RHEL), согласно их отчёту Product Security Risk Report. Это более 70% от общего числа уязвимостей, исправленных во всех продуктах.

    Количество важных и критических рекомендаций по безопасности для различных дистрибутивов Linux за 2015-2020 годы. Источник: Trend Micro
    Количество важных и критических рекомендаций по безопасности для различных дистрибутивов Linux за 2015-2020 годы. Источник: Trend Micro

    Уязвимости приложений, работающих под управлением Linux, были причиной нескольких серьёзных инцидентов. Например, нашумевшая утечка данных в Equifax произошла в результате эксплуатации уязвимости CVE-2017-5638 в Apache Struts. Тогда хакеры проникли в корпоративную сеть бюро кредитных историй Equifax 13 мая 2017 года, но подозрительную активность служба безопасности заметила только в конце июля. Киберпреступники провели внутри сети 76 дней, успев за это время скачать из 51 базы данных личную информацию 148 млн американцев — это 56% взрослого населения США. Помимо американских граждан в утечку попали сведения 15 млн клиентов Equifax в Великобритании и около 20 тыс. граждан Канады. Общие расходы Equifax в результате этого инцидента за два следующих года составили более 1,35 млрд долларов США и включают расходы на укрепление систем безопасности, поддержку клиентов, оплату юридических услуг, а также выплаты по судебным искам.

    Уязвимости публичных приложений входят в состав фреймворка MITRE ATT&CK (ID T1190), а также перечислены в топ-10 уязвимостей OWASP и являются наиболее популярными векторами проникновения в Linux-системы.

    Ошибки конфигурации

    Небезопасные настройки довольно распространены и всегда были критическим вопросом в области безопасности. Первая версия OWASP Top 10 Web Risks от 2004 года, включала в себя «Небезопасное управление конфигурацией» (Insecure Configuration Management); в версии списка 2017 года название изменилось на «Ошибочные настройки безопасности» (Security Misconfiguration).

    Когда предприятия стали массово переходить на облачные технологии для обеспечения операционной и экономической устойчивости во время пандемии COVID-19, неправильная конфигурация стала ещё более серьёзной проблемой: по мере переезда предприятий и организаций в новые экосистемы они непреднамеренно вносили ошибки в конфигурации облачной инфраструктуры, контейнеров и бессерверных сред.

    Ниже перечислены наиболее распространённые проблемы безопасности в конфигурации Linux.

    Слабые пароли в Linux как массовое явление

    Использование паролей по умолчанию или слабых паролей до сих пор удивительно распространено, причём даже самые популярные дистрибутивы не отличаются в лучшую сторону. 

    Например, в дистрибутивах Debian/Ubuntu время жизни пароля по умолчанию составляет 99 999 дней, а если требуется принудительно задать сложность пароля, придётся устанавливать пакет libpam-pwquality или его аналог. 

    Настройки времени жизни пароля по умолчанию в Ubuntu (файл /etc/login.defs). Источник: linuxtechi
    Настройки времени жизни пароля по умолчанию в Ubuntu (файл /etc/login.defs). Источник: linuxtechi

    Известный пример злоупотребления из-за отсутствия аутентификации произошёл в Tesla, когда злоумышленники получили доступ панели управления административной консоли, смогли взломать работающую подсистему Kubernetes и получить AWS-удостоверения Tesla для запуска майнера криптовалюты.

    В ноябре 2020 года ФБР выпустило предупреждение о том, что злоумышленники злоупотребляют неправильно настроенными экземплярами SonarQube, который обнаруживает ошибки и уязвимости в безопасности исходного кода. Из-за того, что некоторые организации не поменяли настройки систем по умолчанию, они были доступны через порт 9000 с использованием учётных данных admin/admin.

    Такая же проблема массово присутствует среди работающих под управлением Linux IoT-устройств, производители которых часто не утруждают себя безопасными настройками паролей. Многие IP-камеры и роутеры также поставляются без паролей или с паролями по умолчанию, которые можно легко найти в общедоступной базе паролей по умолчанию (Default Passwords Database). Причём в некоторых случаях пароли жёстко прошиты и не могут быть изменены. 

    Уязвимые службы в интернете

    Развитие специализированных поисковых систем привело к тому, что уязвимый открытый порт в интернете можно расценивать как приглашение к атаке. Например, используя специализированную поисковую систему Shodan, мы обнаружили более 8 тыс. уязвимых экземпляров Redis, размещённых в публичном облаке без TLS-шифрования и даже без пароля. Позже оказалось, что все они уже использовались кем-то для майнинга криптовалюты

    Открытые файловые ресурсы на Linux-серверах

    Публично доступные FTP-, SMB- и NFS-ресурсы, разрешённый листинг каталогов на веб-серверах под управлением Linux, открытые облачные службы хранения данных Amazon S3 и Azure Blob создают потенциальный риск несанкционированного доступа. С помощью Shodan мы обнаружили более 3 млн уязвимых публичных FTP-серверов.

    Общее количество уязвимых публичных FTP-серверов по состоянию на 5 января 2021 года. Источник: Trend Micro
    Общее количество уязвимых публичных FTP-серверов по состоянию на 5 января 2021 года. Источник: Trend Micro

    Вредоносное ПО

    Под Linux существуют многие разновидности вредоносных программ: вымогатели, криптомайнеры, руткиты, черви, бэкдоры и трояны удалённого доступа (RAT). Преступники успешно используют их для получения финансовой выгоды, шпионажа, саботажа, хактивизма или просто из желания доказать, что системы могут быть скомпрометированы.

    Ниже перечислены наиболее распространённые типы вредоносных программ в экосистеме Linux.

    Вымогатели

    Это, безусловно, самая финансово успешная категория вредоносных программ за последнее время. Учитывая растущую популярность Linux, злоумышленники, управляющие вымогателями, считают эту операционную систему очень перспективной мишенью.

    В качестве примера Linux-вымогателей можно привести RansomEXX/Defray7777, относительно недавно портированный под эту операционную систему. Его применяла кибергруппировка Gold Dupont, атакующая организации из сфер здравоохранения и образование и технологические отрасли. 

    Другой вымогатель — Erebus, впервые замеченный в сентябре 2016 года, — в июне 2017 года Erebus заразил 153 Linux-сервера южнокорейской хостинговой компании NAYANA и вывел из строя 3400 клиентских сайтов. 

    Криптомайнеры

    Относительно новым мотивом для злоумышленников является проникновение и злоупотребление вычислительными ресурсами для добычи криптовалюты. 

    Многие вредоносные криптомайнеры не просто заражают Linux-системы, но и очищают их от присутствия майнеров-конкурентов, а также стремятся захватить как можно более мощные системы с практически неограниченными вычислительными возможностями, такие как контейнеры Docker или Redis.

    Для проникновения в систему майнеры используют распространённые уязвимости. Например, программа coinminer, детектируемая  компанией Trend Micro под названием Coinminer.Linux.MALXMR.SMDSL64, использует уязвимости обхода авторизации SaltStack (CVE-2020-11651) и обхода каталога SaltStack (CVE-2020-11652).

    Вредоносные скрипты

    Командные интерпретаторы присутствуют на всех UNIX-машинах, поэтому злоумышленники активно используют его, тем более что это значительно проще, чем использовать скомпилированные вредоносные программы. 

    Причин популярности вредоносных скриптов для атак на Linux:

    • они легко загружаются в виде текстовых файлов;

    • они имеют небольшой размер;

    • меньше вероятность того, что они будут легко обнаружены;

    • они могут быть созданы «на лету».

    Веб-шеллы и бэкдоры

    Веб-шелл — установленный на веб-сервере скрипт, который выполняет команды преступника и обеспечивает ему прямой доступ к взломанной системе. Например, в августе 2020 года мы столкнулись с Ensiko, веб-оболочкой PHP, нацеленной на Linux, Windows, macOS или любую другую платформу, на которой установлен PHP. Помимо удалённого выполнения кода с помощью Ensiko злоумышленники могут выполнять команды оболочки и повреждать веб-сайты.

    Руткиты

    Руткит — набор вредоносных программ, которые внедряются в Linux-систему, частично или полностью подменяя стандартные системные утилиты, драйверы и библиотеки. Основная цель руткита — скрывать своё присутствие от администраторов и пользователей скомпрометированной системы, обеспечивая злоумышленнику полный или частичный контроль.

    В ходе наших исследований мы сталкивались с несколькими семействами руткитов. Чаще всего это были Umbreon, Drovorub или Diamorphine. 

    Рекомендации

    Предприятия продолжают внедрять Linux, причём использование этой ОС не ограничивается серверными задачами. Крупные предприятия активно устанавливают свободную ОС на десктопы пользователей. Очевидно, что когда киберпреступники заметят эту тенденцию, они будут всё чаще нацеливаться на среду Linux с целью получения финансовой выгоды.

    Вот несколько рекомендаций по обеспечению безопасности систем Linux:

    • внедрите в качестве обязательного принцип «Инфраструктура как код» (Infrastructure as Code, IaC), который гарантирует что системы создаются должным образом, а их конфигурации соответствуют решаемым задачам;

    • используйте принцип наименьших привилегий и модель совместной ответственности;

    • контролируйте целостность операционной системы, чтобы подозрительные изменения не могли произойти незаметно;

    • отслеживайте сетевой периметр, проводите мониторинг всех устройств, систем и сетей;

    • замените пароли по умолчанию на сильные и безопасные, по возможности всегда включайте многофакторную аутентификацию;

    • регулярно устанавливайте обновления и исправления ошибок. 

    Trend Micro
    Компания

    Комментарии 46

      +14

      Я ваш пост минусану. За что? За то, что вы считаете, что отсутствие срока жизни пароля — это узявимость. Я не считаю "вечный" пароль на рабочей станции проблемой.


      И я открыт к дискуссии.

        0
        TrendMicro считают, NIST — нет.
          +6

          В моём представлении локальная машина — это специальный случай.


          А вот пароли по сети — это плохо, да (потому что круг атакующих большой и есть вероятность компрометации пароля при работе с сервером), вне зависимости от срока жизни пароля. Но в посте-то не про это.


          Ни в одном из этих случаев я не вижу смысла в ротации паролей. Либо убирайте пароль вообще, либо ротация не нужна.

            +1
            Я вообще-то согласен :) Из-за на порядки меньшей скорости перебора паролей к локальной машине смысла в ротации ещё меньше, чем для сетевых.
          +1
          Соглашусь с предыдущим оратором, так же и проверка сложности тудаже, лучше начать прививать культурну формирования запоминаемых длинных паролей и доступов по ключу
            0

            Запоминающиеся длинные пароли рассчитаны на посимвольный брутфорс. Но… Если будет культура длинных запоминающихся паролей — брутфорс просто перейдет на подбор по словарю, ибо большая часть людей также будет задавать простые для перебора пароли вида "розовый пони лижет пиццу"/"розовыйпонилижетпиццу", т.е. прилагательное+существительное+глагол+существительное.

              0
              Habrjdsqgjybkb;tngbwwe (Habrовыйпонилижетпиццу) как там ваш словарь?
                0

                А теперь скажи как часто ты в пароле переключаешь язык? Более того, скажи сколько популярных (и не очень) сайтов допустят в пароле русские символы...

                  0
                  причем тут переключение языка? я в скобках просто написал как такой пароль сформирован, сам пароль — левее.
                    0

                    А. Да. Не заметил что и в оригинале habr.
                    Тем не менее прилагательные будут формироваться таким же способом...

                0

                Я раньше на некоторых сайтах использовал пароль GoSDuMSurusyazamanovmusar87771534637 (некоторые символы изменил).

                  0

                  Поздравляю. Но я сказал не о частном случае человека, который смыслит в безопасности пароля, а об общем. Даже сейчас большая часть сайтов не позволяет использовать 123456, что очень затрудняет брутфорс, из-за чего мой всего лишь 10-символьный пароль сложно будет подобрать. Но до сих пор есть люди которые используют аналоги Qwerty123 даже для банков.

                    0
                    Даже сейчас большая часть сайтов не позволяет использовать 123456, что очень затрудняет брутфорс

                    и отваживает клиентов

                    очень блин нервируют сайты где надо 'придумайте пароль не меньше 6 символов, но не больше 10, с цифрами и буквами, знаками припинания, разного регистра и не повторяющийся с предыдущим и менять каждые 3 месяца'… а сайт даже не интернет-магазин, а какойнить личный кабинет для отправки показаний счетчика на воду без ф-ций оплаты
              0

              Это уже вопрос к социальной инженерии, как мне кажется.


              Как ротация паролей может быть уязвимостью, когда люди устают от частой смены и хранят на бумажке.
              Так и один пароль может использоваться в разных местах.


              Нужен какой-то аналитический подход. Ротация по времени выглядит ущербной.

              +9
              Вся статья умножается на 0 списком рекомендаций, который никоим образом не будет отличаться от аналогичных для других ОС.
                +5

                Прдытоживая:


                1. Незакрытые публичные уязвимости
                2. Косяки в настройках
                3. Слабые пароли

                Итого, только первое отличает Linux-based OS от проприетарных. Но и что с этим делать — тоже давно известно.

                  +4
                  регулярно устанавливайте обновления и исправления ошибок.


                  Да откуда вы это черпаете? Защищенная система должна загружаться из заготовленной squashfs c проверкой контрольной суммы при запуске. Причем, разделы /opt /etc /usr монтируются readonly. Плюс грамотно настроенные параметры паники ядра и автоматическая перезагрузка в случае переполнений любого из буферов. Включите параметры загрузки ядра: noibrs noibpb pti=off nospectre_v1 nospectre_v2 l1tf=off nospec_store_bypass_disable no_stf_barrier mds=off (это не полный список, но из того, что вспоминается в первую минуту размышлений). Включите расширение uMatrix на всех браузерах в режим максимальной блокировки (белые списки frame/ajax/media/img/js/css по каждому домену/под-домену отдельно). Отметёт работоспособность 99% эксплойтов/руткитов и прочей нечисти.
                    –4
                    Отметёт работоспособность 99% эксплойтов/руткитов и прочей нечисти.

                    Это если вы админ локалхоста.
                    а теперь представтье что у вас в подчинении сеть на 5000машин с офисными юзерами
                      +1

                      Централизованные системы управления конфигурацией отменили? Никогда-бы не подумал!

                        0
                        Создавать и поддерживать наборы правил для 5000компов? да раз плюнуть!

                        Господа, вы явно не сталкивались с такими задачами в живую.
                        У меня был такой кейс, мы в итоге выводили браузер в изолированную машину доступную только по rdp/ica, а на рабочих машинах интернета не было совсем. и перенастраивали весь софт на работу с локальными версиями серверов и прокси-сервисов, отказываясь от софта который так не умеет. Это очень сложная работа которая НЕ ФАКТ что окупает отказ от обновлений мотивируя тем что 'да всеголишь достаточно .....'
                          0

                          А Microsoft-то и не знает! Так и заморачивается с развитием своего group policy. Дураки, наверное. И разработчики Ansible / chef /puppet /Salt Stack. Надо им срочно рассказать о тщетности бытия!
                          А костыли и велосипеды и я придумывать умею. Только они у меня дальше тестовой, исследовательской песочницы не вылезают. Наборы правил существуют не для отдельных компов, а для групп этих самых компов, пользователей и иже с ними (слово group, в решении от MS). А если у вас так не получается, значит вы с вероятностью 146%™ что-то делаете не так.

                            0
                            Наборы правил существуют не для отдельных компов, а для групп этих самых компов

                            да неужели? вы мне прям глаза раскрыли на функционал AD

                            у меня не-неполучается, у меня был кейс с очень яростной политикой ИБ, где чутьли не под каждого юзера с мудреным корпоративным софтом или сайтом надо было писать список IP разрешенных адресов и протоколов и сочинять правила для IDS

                            Это не выделить группу «менеджеры продукта» и накатить правила на 50 человек. Это каждому из них подойти, переписать список сайтов (типа Visa BIN Viewer и какойто еще МПСовский ужас написанный на вижулбейсике) и под них собрать правила для IDS фаерволла… еще пары систем и блин ДА накатить их через GPO конечноже
                            такие кейсы конечно у нас редки, потому что в ИБ у нас все не в зуб ногой обычно.
                      0

                      Тогда уже не squashfs, а dm-verify. Отключение защиты спектре в свете работающих js-эксплоитов для spectre — это просто верх идиотизма, простите. mlfa (про который вы пишите) имеет смысл на серверах, которые не исполняют недоверенного кода (например, СУБД или ceph), а любая рабочая станция IRL вынужена выполнять всяхую херь с из интернета, и никакой umatrix от этого полностью не спасает.

                        0
                        Отключение защиты спектре в свете работающих js-эксплоитов для spectre

                        я не слежу за темой, но вроде бы в современных браузерах эксплуатировать spectre из js не получится

                          –1
                          Нет. Попробуйте потестить последний Chrome: xlab.tencent.com/special/spectre/spectre_check.html

                          Только когда увидите зелёную надпись, не обольщайтесь. Попробуйте перезапустить тест раз 20. Попробуйте переходить по другим вкладкам браузера во время выполнения теста. Попробуйте запустить тест одновременно на двух-трех вкладках браузера.

                          Пока в JS будет доступен Uint8Array и его аналоги, пока setTimeout будет срабатывать с интервалом меньшим чем хотя бы 2500мс, уязвимостям браузеров не будет границ. Ваши конфиденциальности не спасет даже изолированная работа в виртуальных машинах. Так что, будущее за WebAssembly.
                            +1
                            Только когда увидите зелёную надпись, не обольщайтесь. Попробуйте перезапустить тест раз 20. Попробуйте переходить по другим вкладкам браузера во время выполнения теста. Попробуйте запустить тест одновременно на двух-трех вкладках браузера.

                            попробовал в chromium во всех указанных вариантах, одно и то же — Your browser is NOT VULNERABLE to Spectre
                            в ff вообще сразу зелёная надпись.


                            перепроверил, загружен с «mitigations=off»


                            пока setTimeout будет срабатывать с интервалом меньшим чем хотя бы 2500мс

                            на задержках в 2.5с можно поймать отклонения в сотни тактов процессора?!?

                          0
                          Отключение intel-овского разгильдяйства. Никак оно не защищает от spectre. А если и защищает от какой-то конкретной уязвимости, то открывает ворота для трех новых уязвимостей. Протестируйте на своих конфигурациях сами: github.com/speed47/spectre-meltdown-checker
                          0
                          Включите параметры загрузки ядра: noibrs noibpb pti=off nospectre_v1 nospectre_v2 l1tf=off nospec_store_bypass_disable no_stf_barrier mds=off (это не полный список, но из того, что вспоминается в первую минуту размышлений)

                          в контексте беседы про повышение уровня защиты совет смотрится странно


                          и да, давно уже есть mitigations=off

                          0

                          А на заглавной картинке MacBook...

                            0
                            Но на макбуке запущен GNOME. Какой-то непримечательный терминал, в котором запущен vim с плагинами nerdtree и airline/powerline (только эти удалось рассмотреть). Вероятно, всё это обёрнуто внутри запущенного tmux. Сам Macbook Pro очень древний, еще без TouchBar.
                              0

                              Здесь еще много стоковых фото из данной серии.

                              0
                              вполне может быть Xiaomi MiBook или что то подобное
                              0
                              Как будто на макбуки не ставят линуксов…
                                0

                                Только мейнтейнерам ядра линукса не говорите, а то они сами пишут статьи, какие макбуки офигенные — Linux on the Mac — state of the union.

                                +6
                                Будем надеятся, что качество софта Trend Micro не такое же нулевое как эта статья. Хотя, впрочем, не будем. Не стоит.
                                  0

                                  никто никогда и не говорил что линукс неуязвим, просто он "менее" уязвим чем та же винда (или вспомним историю с безпарольным рутом в макоси).
                                  бесконечно долгий пароль из четырёх нулей у рута собственно тоже не сказать чтобы был проблемой ибо по сети доступ чаще всего возможен только по ключам а при физическом доступе это вообще не играет роли тут нужно фс шифровать (что тоже кстати не панацея)
                                  лично у меня больше бесит что в убунтах (читать популярных дистрах) и макоси запрашивается пароль юзверя а не рута… ну нефига простому пользователю иметь доступ к sudo, в этом плане suse/opensuse куда грамотнее.

                                    0

                                    Простите, на втором графике "Alpine Linux" везде 0? Или это кривой график?

                                      0
                                      Кажется, что большая часть описанного в статье вполне попадает в «общую» категорию, не касающуюся конкретно Linux. Слабые пароли и несекурный конфиг сервисов может быть и на win-серверах. Хотя с общим посылом статьи сложно не согласиться, нужно ответственно относиться к безопасности и серверов и рабочих машин, не полагаясь только на механизмы ОС поставляемые из коробки. Linux — не волшебная таблетка, я бы даже скорее сказал что допустить ошибку в конфигурации рабочей машины на нём куда проще чем в той же винде или макоси, где о простых способах «выстрелить себе в ногу» за среднего пользователя подумал производитель. С другой стороны виндовс и макось часто не могут предоставить должной гибкости и возможностей в настройке рабочей машины для себя и своих нужд, в том числе и с точки зрения безопасности, а ИМХО именно за гибкость и возможности люди и выбирают Linux.

                                      Если бы я писал статью на эту тему, то скорее развил бы мысль в сторону того что немалое число уязвимостей ОС на базе ядра Linux растёт из монолитной структуры самого ядра. Это создаёт некоторые проблемы Linux, которые как правило вообще не будут касаться других ядер ОС.
                                        0
                                        Если бы я писал статью на эту тему, то скорее развил бы мысль в сторону того что немалое число уязвимостей ОС на базе ядра Linux растёт из монолитной структуры самого ядра. Это создаёт некоторые проблемы Linux, которые как правило вообще не будут касаться других ядер ОС.

                                        а чем тут linux отличается от freebsd или windows?

                                        0
                                        поскольку открытый исходный код позволяет быстро найти проблемную функцию и написать код для эксплуатации ошибки.

                                        То есть вы считаете, что хакеры найдут проблемную функцию быстрее, чем разработчики? И тем и другим найти такую функцию одинаково сложно и открытые исходники это не дыра в безопасности, а скорее наоборот, так как людей анализирующих исходники во благо, гораздо больше, чем тех, кто анализирует их во вред, можно конечно поспорить, что хакеры более продвинутые, но это спорно. В общем слово "быстро" В цитате, которую я привел, говорит о том, что автор сам никогда не смотрел в исходники

                                          0

                                          Теперь я понимаю чувства верующих, когда критикую их религию)

                                            0
                                            Нет неуязвимых ОС. В том числе и Linux
                                              0

                                              Я так понял пользователи дают слабые пороли, не обеспечивают безопасность системы, а виноват в этом linux? Linux — просто инструмент. У пользователя с прямыми руками с безопасностью все будет ОК вне зависимости от ОС.

                                                0

                                                Стоит отличать домашний ПК и сервер и уязвимости встречающиеся там и там, у меня из статьи появилось ощущение что автор их умышленно сваливает в кучу, дабы показать какой он молодец что написал статью с хайповым заголовком.
                                                P.S. Ушел гуглить амазоновский линух, что это за зверь?)

                                                  0

                                                  Очень странный пост. Перечислены фактически общие уязвимости для всех операционных систем.
                                                  А вы никогда не задумывались о том, что чем больше уязвимостей найдено, тем лучше? Поясню… В опенсорсе код доступен всем. И специалисты спокойно находят эти уязвимости, рапортуют о них и исправляют их. Найденные дыры сразу же становятся известны всем и сразу фиксятся.
                                                  А что у наших проприетарных друзей? Вы что, серьезно думаете, что у них меньше уязвимостей? Корпорации совершенно невыгодно афишировать уязвимости. Это прямая потеря репутации, а, значит, и денег. И если не возникло никакого публичного скандала с утечкой данных миллионов людей, то они будут тупо молчать в тряпочку, и, может быть, нам повезет, они снизойдут до нас, смертных, и через годик-другой прикроют дыру, если это не будет очень дорого.

                                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                  Самое читаемое