OpenNET

OpenNET

пикабушник
Русскоязычный интернет-проект, посвящённый открытым и свободным компьютерным технологиям. Поддержать https://ClickLink.app/Donate
поставил 1 плюс и 1 минус
отредактировал 5 постов
проголосовал за 4 редактирования
сообщества:
8699 рейтинг 132 подписчика 13 комментариев 91 пост 61 в горячем
39

Mozilla приостановила работу сервиса Firefox Send из-за вредоносной активности

Mozilla приостановила работу сервиса Firefox Send из-за вредоносной активности Mozilla, Firefox

Компания Mozilla временно приостановила работу сервиса обмена файлами Firefox Send из-за его вовлечения в распространение вредоносного ПО и жалоб на отсутствие средств для отправки abuse-уведомлений о ненадлежащем использовании сервиса (присутствовала только общая форма обратной связи). Работу планируется восстановить после реализации возможности отправки жалоб на размещение вредоносного или проблемного содержимого, а также налаживания службы для оперативного реагирования на подобные сообщения. Также планируется отключить возможности анонимной отправки файлов - при размещении файла в сервисе станет обязательной регистрация учётной записи через сервис Firefox Account.


Напомним, что Firefox Send позволял загрузить в хранилище на серверах Mozilla файл, размером до 1 Гб в анонимном режиме и 2.5 Гб при создании зарегистрированной учётной записи. На стороне браузера файл шифровался и передавался на сервер уже в зашифрованном виде. После загрузки файла пользователю предоставлялась ссылка, которая генерировалась на стороне клиента и включала идентификатор и ключ для расшифровки. При помощи предоставленной ссылки получатель мог загрузить файл и расшифровать на своей стороне. Отправитель имел возможность определить число загрузок, после исчерпания которых файл удалялся из хранилища Mozilla, а также время жизни файла (от одного часа до 7 дней).


В последнее время Firefox Send оказался востребован злоумышленниками как канал для распространения вредоносного ПО, хранения компонентов, используемых при проведении различных атак, и передачи данных, перехваченных в результате работы вредоносных программ или компрометации пользовательских систем. Популярности сервиса среди злоумышленников способствовала поддержка в Firefox Send шифрования данных и защиты содержимого паролем, а также возможность автоудаления файла после определённого числа загрузок или истечения времени жизни, которая затрудняла расследование вредоносной активности и позволяла обходить системы обнаружения атак. Кроме того, ссылки на домен send.firefox.com в письмах как правило рассматривались как заслуживающие доверие и не блокировались антиспам фильтрами.

Показать полностью
89

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

Волна взломов суперкомпьютеров для майнинга криптовалюты Malware, Monero, Майнинг

В нескольких крупных вычислительных кластерах, находящихся в суперкомпьютерных центрах Великобритании, Германии, Швейцарии и Испании, выявлены следы взломов инфраструктуры и установки вредоносного ПО для скрытого майнинга криптовалюты Monero (XMR). Детальный разбор инцидентов пока недоступен, но по предварительным данным системы были скомпрометированы в результате кражи учётных данных с систем исследователей, имеющих доступ на запуск заданий в кластерах (последнее время многие кластеры предоставляют доступ сторонним исследователям, изучающим коронавирус SARS-CoV-2 и проводящим моделирование процессов, связанных с инфекцией COVID-19). После получения доступа к кластеру в одном из случаев атакующие эксплуатировали уязвимость CVE-2019-15666 в ядре Linux для получения root-доступа и установки руткита.


Выделяется два инцидента, в ходе которых атакующие воспользовались учётными данными, захваченными у пользователей из Краковского университета (Польша), Шанхайского университета транспорта (Китай) и Китайской научной сети. Учётные данные были захвачены к участников международных исследовательских программ и использовались для подключения к кластерам по SSH. Как именно были захвачены учётные данные пока не ясно, но на некоторых системах (не на всех) жертв утечки паролей были выявлены подменённые исполняемые файлы SSH.


В итоге, атакующие смогли получить доступ к находящемуся в Великобритании (Эдинбургский университет) кластеру Archer, занимающему 334 место в Top500 крупнейших суперкомпьютеров. Следом похожие проникновения были выявлены в кластерах bwUniCluster 2.0 (Технологический институт Карлсруэ, Германия), ForHLR II (Технологический институт Карлсруэ, Германия), bwForCluster JUSTUS (Ульмский университет, Германия), bwForCluster BinAC (Тюбингенский университет, Германия) и Hawk (Штутгартский университет, Германия). Позднее была подтверждена информация об инцидентах с безопасностью кластеров в Национальном суперкомпьютером центре Швейцарии (CSCS), Юлихском исследовательском центре (31 место в top500), Мюнхенском университете (Германия) и Компьютерном центре имени Лейбница (9, 85 и 86 места в Top500). Кроме того, от сотрудников получена пока официально не подтверждённая информация о компрометации инфраструктуры Центра высокопроизводительных вычислений в Барселоне (Испания).


Анализ изменений показал, что на скомпрометированные серверы загружались два вредоносных исполняемых файла, для которых был установлен флаг suid root: "/etc/fonts/.fonts" и "/etc/fonts/.low". Первый представляет собой загрузчик для запуска shell-команд с привилегиями root, а второй - чистильщик логов для удаления следов активности злоумышленников. Для скрытия вредоносных компонентов использовались различные техники, включая установку руткита Diamorphine, загружаемого в форме модуля для ядра Linux. В одном случае процесс майнинга запускался только в ночное время, чтобы не привлекать внимание.


После взлома хост мог использоваться для выполнения различных задач, таких как майнинг криптовалюты Monero (XMR), запуск прокси (для взаимодействия с другими хостами, выполняющими майнинг, и сервером координирующим майнинг), запуск SOCKS-прокси на базе microSOCKS (для приёма внешних соединений по SSH) и проброс SSH (первичная точка проникновения при помощи скомпрометированной учётной записи, на которой настраивался транслятор адресов для проброса во внутреннюю сеть). При подсоединении к взломанным узлам атакующие использовали хосты с SOCKS-прокси и, как правило, подключались через Tor или другие взломанные системы.

Показать полностью
-6

Павел Дуров объявил о прекращении разработки блокчейн-платформы TON

Павел Дуров объявил о прекращении разработки блокчейн-платформы TON Биткоины, Ton, Павел Дуров

Павел Дуров сообщил о завершении проекта по разработке блокчейн-платформы TON и криптовалюты Gram из-за невозможности работы в условиях запретительных мер, введённых комиссией по ценным бумагам и биржам США (SEC). Участие компании Telegram в разработке TON полностью прекращено. Так как код TON является открытым, ожидается появление независимых сетей на базе TON, но, по словам Дурова, к ним стоит относиться с осторожностью, они никак не связаны с Telegram и ни один из членов команды Telegram не принимает в них участие. Дуров не рекомендует доверять свои деньги и данные подобным проектам, особенно если они манипулируют его именем и брендом Telegram.


Несколько дней назад заинтересованными пользователями был сформирован проект Free TON, поставивший перед собой цель продолжения разработки открытой платформы TON, поддержания инфраструктуры и создания сервисов на его основе. Проект будет развиваться сообществом Free TON Community, к которому присоединились компании TON Labs, Dokia Capital и Bitscale Capital, а также криптовалютные биржи Kuna и CEX.IO. Участникам проекта будут бесплатно раздаваться токены TON Crystal (криптовалюта Gram использоваться не будет): 85% токенов будет роздано за привлечение пользователями новых участников, 10% розданы разработчикам и 5% валидаторам.


Напомним, что на создание блокчейн-платформы TON было привлечено более 1.7 млрд долларов инвестиций, но Комиссия по ценным бумагам США посчитала продажу цифровых токенов Gram незаконным, так как все единицы криптовалюты Gram были эмитированы разом и распределены между инвесторами и стабилизационным фондом, а не формируются в ходе майнинга. Комиссия утверждает, что при подобной организации на Gram распространяется имеющееся законодательство о ценных бумагах, а эмиссия Gram требовала обязательной регистрации в соответствующих регулирующих органах. Было указано, что Telegram стремился получить выгоду от публичного размещения без соблюдения установленных правил по раскрытию информации, направленных на защиту инвесторов - ценные бумаги не перестают быть таковыми, только потому, что они преподносятся под видом криптовалюты или цифровых токенов.


Из вложенных инвесторами средств на разработку платформы уже потрачено 28%, но компания Telegram готова вернуть американским инвесторам 72% от вложенной суммы. Инвесторам из других стран, кроме возврата 72%, предложен варианта предоставления средств в кредит с возвратом 110% в следующем году. Некоторые инвесторы намерены сформировать пул для подачи судебного иска против Дурова, так как, по их мнению, не все возможности по урегулированию ситуации были использованы.


При этом TON является лишь технологической платформой для развёртывания криптовалюты Gram, но не ограничивается ею и может применяться для создания других сервисов и криптовалют, которые могут быть кардинально быстрее Bitcoin и Ethereum по скорости подтверждения транзакций (миллионы транзакций в секунду вместо десятков). TON может рассматриваться как распределённый суперсервер, предназначенный для размещения и предоставления различных сервисов на базе блокчейна и умных контрактов. Умные контракты создаются на разработанном для TON языке Fift и выполняются в блокчейне при помощи специальной виртуальной машины TVM.


Из клиентов формируется P2P-сеть, используемая для доступа к TON Blockchain и работы произвольных распределённых сервисов, в том числе не связанных с блокчейном. Описания интерфейса сервиса и точки входа публикуются в блокчейне, а предоставляющие сервисы узлы определяются через распределённую хэш-таблицу. Среди компонентов TON можно отметить TON Blockchain, P2P-сеть, распределённое хранилище файлов, прокси-анонимайзер, распределённую хэш-таблицу, платформу для создания произвольных сервисов (подобие сайтов и web-приложений), систему доменных имён, платформу микроплатежей и TON External Secure ID (Telegram Passport).

Показать полностью
62

Большинство антивирусов оказались подвержены атаке через символические ссылки

Большинство антивирусов оказались подвержены атаке через символические ссылки Антивирус, Mac Os, Windows, Linux, Длиннопост

Исследователи из компании RACK911 Labs обратили внимание на то, что почти все антивирусные пакеты для Windows, Linux и macOS были уязвимы для атак, манипулирующих состоянием гонки (race conditions) во время удаления файлов, в которых обнаружено вредоносное ПО.


Для проведения атаки необходимо загрузить файл, который антивирус распознает как вредоносный (например, можно использовать тестовую сигнатуру), а через определённое время, после выявления вредоносного файла антивирусом, но непосредственно перед вызовом функции для его удаления, подменить каталог с файлом символической ссылкой. В Windows для достижения того же эффекта выполняется подмена каталога при помощи точки соединения (directory junction). Проблема в том, почти все антивирусы должным образом не выполняли проверку символических ссылок и, считая что удаляют вредоносный файл, удаляли файл в каталоге на который указывает символическая ссылка.


В Linux и macOS показано как таким способом непривилегированный пользователь может удалить /etc/passwd или любой другой системный файл, а в Windows DDL-библиотеку самого антивируса для блокирования его работы (в Windows атака ограничена только удалением файлов, которые в текущим момент не используются другими приложениями). Например, атакующий может создать каталог "exploit" и загрузить в него файл EpSecApiLib.dll с тестовой сигнатурой вируса, после чего перед удалением заменить каталог "exploit" на ссылку "C:\Program Files (x86)\McAfee\Endpoint Security\Endpoint Security Platform", что приведёт к удалению библиотеки EpSecApiLib.dll из каталога антивируса. В Linux и macos аналогичный приём можно проделать с подменой каталога на ссылку "/etc".


#!/bin/sh

rm -rf /home/user/exploit ; mkdir /home/user/exploit/

wget -q https://www.clicklink.app/download/eicar.com.txt -O /home/user/exploit/passwd

while inotifywait -m “/home/user/exploit/passwd” | grep -m 5 “OPEN”

do

rm -rf /home/user/exploit ; ln -s /etc /home/user/exploit

done


Более того, во многих антивирусах для Linux и macOS было выявлено использование предсказуемых имён файлов при работе с временным файлами в каталоге /tmp и /private/tmp, что могло использоваться для повышения привилегий до пользователя root.


К настоящему времени проблемы уже устранены большинством поставщиков, но примечательно, что первые уведомления о проблеме были направлены производителям ещё осенью 2018 года. Несмотря на то, что не все производители выпустили обновления, им было дано на исправление как минимум 6 месяцев, и RACK911 Labs считает, что теперь вправе раскрыть сведения об уязвимостях. Отмечается, что компания RACK911 Labs давно занимается работой по выявлению уязвимостей, но она не предполагала, что с коллегами из антивирусной индустрии будет так трудно работать из-за затягивания выпуска обновлений и игнорирования необходимости срочного устранения проблем с безопасностью.


Продукты, подверженные проблеме (свободный антивирусный пакет ClamAV в списке отсутствует):


Linux

BitDefender GravityZone

Comodo Endpoint Security

Eset File Server Security

F-Secure Linux Security

Kaspersy Endpoint Security

McAfee Endpoint Security

Sophos Anti-Virus for Linux


Windows

Avast Free Anti-Virus

Avira Free Anti-Virus

BitDefender GravityZone

Comodo Endpoint Security

F-Secure Computer Protection

FireEye Endpoint Security

Intercept X (Sophos)

Kaspersky Endpoint Security

Malwarebytes for Windows

McAfee Endpoint Security

Panda Dome

Webroot Secure Anywhere


macOS

AVG

BitDefender Total Security

Eset Cyber Security

Kaspersky Internet Security

McAfee Total Protection

Microsoft Defender (BETA)

Norton Security

Sophos Home

Webroot Secure Anywhere

Показать полностью
41

Инициатива по сближению разработки openSUSE Leap и SUSE Linux Enterprise

Инициатива по сближению разработки openSUSE Leap и SUSE Linux Enterprise Opensuse, Suse

Джеральд Пфайфер (Gerald Pfeifer), технический директор компании SUSE и председатель надзорного комитета openSUSE, предложил сообществу рассмотреть инициативу по сближению процессов разработки и сборки дистрибутивов openSUSE Leap и SUSE Linux Enterprise. В настоящее время выпуски openSUSE Leap формируются на основе базового набора пакетов дистрибутива SUSE Linux Enterprise, но пакеты для openSUSE собираются отдельно из пакетов с исходными текстами. Суть предложения в унификации работы по сборке обоих дистрибутивов и использовании в openSUSE Leap готовых бинарных пакетов из SUSE Linux Enterprise.


На первом этапе предлагается осуществить слияние пересекающихся кодовых баз openSUSE Leap 15.2 и SUSE Linux Enterprise 15 SP2 по возможности без потери функциональности и стабильности обоих дистрибутивов. На втором этапе параллельно с классическим выпуском openSUSE Leap 15.2 предлагается подготовить отдельную редакцию на основе исполняемых файлов из SUSE Linux Enterprise и выпустить промежуточный релиз в октябре 2020 года. На третьем этапе в июле 2021 года планируется сформировать выпуск openSUSE Leap 15.3, по умолчанию использовав в нём исполняемые файлы из SUSE Linux Enterprise.


Использование одних и тех же пакетов упростят миграцию от одного дистрибутива к другому, сэкономят ресурсы на сборку и тестирование, даст возможность избавиться от усложнений в spec-файлах (все различия, определённые на уровне spec-файлов будут унифицированы) и сделает более простой отправку и обработку сообщений об ошибках (позволят отойти от диагностики разных сборок пакетов). openSUSE Leap будет преподноситься компанией SUSE как платформа разработки для сообщества и сторонних партнёров. Для пользователей openSUSE изменение выгодно возможностью использовать стабильный код промышленного дистрибутива и хорошо протестированные пакеты. Обновления, охватывающие пресекающиеся пакеты, также будут общими и хорошо протестированными командой контроля качества SUSE.


Площадкой для разработки новых пакетов, передаваемых в openSUSE Leap и SLE, останется репозиторий openSUSE Tumbleweed. Процесс передачи изменений в базовые пакеты не изменится (по сути вместо сборки из src-пакетов SUSE будут использоваться готовые бинарные пакеты). Все совместно используемые пакеты как и раньше будут доступны в Open Build Service для модификации и создания форков. При необходимости поддержания в openSUSE и SLE разной функциональности общих приложений, дополнительную функциональность можно будет выносить в специфичные для openSUSE пакеты (по аналогии с разделением элементов брендинга) или добиваться включения нужной функциональности в SUSE Linux Enterprise. Пакеты для архитектур RISC-V и ARMv7, не поддерживаемых в SUSE Linux Enterprise, предлагается собирать отдельно.

Показать полностью
56

Массовый отзыв сертификатов Let's Encrypt

Массовый отзыв сертификатов Let's Encrypt Letsencrypt, Https

Некоммерческий удостоверяющий центр Let's Encrypt, контролируемый сообществом и предоставляющий сертификаты безвозмездно всем желающим, предупредил о предстоящем отзыве многих ранее выданных TLS/SSL сертификатов. Из 116 млн ныне действующих сертификатов Let's Encrypt будет отозвано чуть больше 3 млн (2.6%), из которых примерно 1 млн являются дубликатами, привязанными к одному домену (ошибка в основном затронула очень часто обновляемые сертификаты, поэтому так много дубликатов). Отзыв запланирован на 4 марта (точное время пока не определено, но отзыв будет произведён не раньше 3 ночи MSK).


Необходимость отзыва обусловлена выявленной 29 февраля ошибкой. Проблема проявляется с 25 июля 2019 года и затрагивает систему проверки CAA-записей в DNS. Запись CAA (RFC-6844, Certificate Authority Authorization) позволяет владельцу домена явно определить удостоверяющий центр, через который можно генерировать сертификаты для указанного домена. Если удостоверяющий центр не перечислен в записях CAA, то он обязан блокировать выдачу сертификатов для данного домена и информировать владельца домена о попытках компрометации. В большинстве случаев сертификат запрашивается сразу после прохождения проверки CAA, но результат проверки считается действительным ещё 30 дней. Правила также предписывают выполнять повторную проверку не позднее, чем за 8 часов до выдачи нового сертификата (т.е. если при запросе нового сертификата с момента прошлой проверки прошло 8 часов, требуется повторная проверка).


Ошибка проявляется, если запрос сертификата охватывает сразу несколько доменных имён, для каждого из которых требуется проверка записи CAA. Суть ошибки в том, что в момент повторной проверки вместо валидации всех доменов, осуществлялась повторная проверка только одного домена из списка (если в запросе было N доменов, вместо N разных проверок, один домен проверялся N раз). Для остальных доменов повторная проверка не выполнялась и при принятии решения использовались данные первой проверки (т.е. использовались данные, давностью до 30 дней). Как следствие, в течение 30 дней после первой проверки Let’s Encrypt мог выдать сертификат, даже если значение CAA-записи было изменено и Let’s Encrypt был убран из списка допустимых удостоверяющих центров.


Подверженным проблеме пользователям отправлено уведомление по email, если при получении сертификата были заполнены контактные данные. Проверить свои сертификаты можно загрузив список серийных номеров отозванных сертификатов или воспользовавшись online-сервисом (размещён на IP-адресе, заблокированном в РФ Роскомнадзором). Узнать серийный номер сертификата для интересующего домена можно при помощи команды:


openssl s_client -connect clicklink.app:443 -showcerts </dev/null 2>/dev/null \

| openssl x509 -text -noout | grep -A 1 Serial\ Number | tr -d :

Показать полностью
13

Зафиксированы две атаки по двойной трате средств в криптовалюте Bitcoin Gold

Зафиксированы две атаки по двойной трате средств в криптовалюте Bitcoin Gold Биткоины, Блокчейн

Разработчики криптовалюты Bitcoin Gold (не путать с Bitcoin), занимающей 24 место в рейтинге криптовалют и имеющей размер капитализации 208 млн долларов, сообщили о выявлении двух атак по двойной трате средств (double spend attack). Для осуществления двойной траты средств атакующему потребовалось получить доступ к вычислительной мощности, составляющей как минимум 51% от всей имеющейся в сети Bitcoin Gold мощности расчёта хэшей.


Атаки на Bitcoin Gold были совершены 23 и 24 января и привели к успешному вторичному начислению 1900 и 5267 BTG на бирже, что по сегодняшнему курсу составляет примерно 85430 долларов. Удалось ли атакующим извлечь данные средства из биржи неизвестно (предполагается, что системы мониторинга подозрительных транзакций должны были блокировать вывод средств). Для предотвращения подобных атак в будущем в течение первого квартала 2020 года в Bitcoin Gold планируют внедрить новый алгоритм на основе децентрализованного достижения консенсуса.


При нынешнем состоянии блокчейна Bitcoin Gold теоретически рассчитанная стоимость проведения подобной атаки оценивается сервисом crypto51 в 785 долларов (для сравнения расчётная стоимость подобной атаки на Bitcoin составляет 704 тысячи долларов). По предварительным данным вычислительная мощность для проведения атаки была приобретена в сервисе NiceHash и затраты на каждую атаку составили приблизительно 1700 долларов при аренде мощностей на NiceHash.


Суть атаки по двойной трате средств сводится к тому, что после отправки средств для обмена атакующий дожидается когда для первой транзакции с переводом накопится достаточно подтверждающих блоков и биржа посчитает перевод совершённым. Затем атакующий, пользуясь наличием преобладающей вычислительной мощности, передаёт в сеть альтернативную ветку блокчейна с конфликтующей транзакцией и бо́льшим числом подтверждённых блоков. Так как при конфликте веток основной признаётся более длинная ветка, подготовленная атакующим альтернативная ветка принималась сетью как основная (т.е. биржа отправляет средства, но перевод ей не фиксируется и по состоянию актуального блокчейна исходные средства остаются у атакующего).

22

LTS-версии Qt будут доступны только под коммерческой лицензией

LTS-версии Qt будут доступны только под коммерческой лицензией Qt, Debian, Suse

Компания Qt Company объявила об изменении модели лицензирования фреймворка Qt, которое может оказать существенное влияние на сообщества и дистрибутивы, использующие Qt. Начиная с версии 5.15 LTS-ветки Qt будут поддерживаться до формирования очередного значительного выпуска, т.е. примерно полгода (обновления для LTS-веток выпускаются три года). Предполагается, что подобный шаг ускорит внедрение новых веток и позволит увеличить число компаний, пользующихся коммерческой лицензии на Qt, стоимость которой составляет $5508 в год на одного разработчика (для стартапов и малых предприятий - $499 в год).


Разработчики дистрибутивов, имеющих длительные сроки поддержки (RHEL, Debian, Ubuntu, Linux Mint, SUSE) будут вынуждены либо поставлять устаревшие официально не поддерживаемые выпуски, самостоятельно портируя исправления ошибок и уязвимостей, либо постоянно обновляться на новые значительные версии Qt, что маловероятно, так как может потянуть за собой непредвиденные проблемы в поставляемых в дистрибутиве Qt-приложениях. Возможно сообществом сообща будет организована поддержка собственных LTS-веток Qt, не зависящих от Qt Company.


Частично ужесточение лицензионной политики смягчает то, что компания Qt Company пообещала проводить все исправления через публичный репозиторий, в котором производится разработка Qt. Патчи будут добавляться в dev-ветку и переноситься в ветки с актуальными стабильными релизами, что упростит их извлечение для переноса в дистрибутивы. LTS-ветки, в которые исправления будут портироваться компанией Qt Company, будут ограничены.


К сожалению, изменения политики в отношении Qt не ограничиваются сменой лицензии, и для загрузки бинарных сборок Qt начиная с февраля потребуется регистрация учётной записи в сервисе Qt Account. Данный шаг объясняется желанием упростить распространение сборок и обеспечением интеграции с каталогом-магазином Qt Marketplace. Доступ к системе отслеживания ошибок Jira, интерфейсу рецензирования и форумам также потребует наличие учётной записи в Qt Account. Модель разработки и управления проектом остаются прежними.

Показать полностью
60

Релиз ядра Linux 5.5

Релиз ядра Linux 5.5 Linux, Kernel, Open Source

После двух месяцев разработки Линус Торвальдс представил релиз ядра Linux 5.5. Среди наиболее заметных изменений: возможность назначения сетевым интерфейсам альтернативных имён, интеграция криптографических функций из библиотеки Zinc, возможность зеркалирования на более чем 2 диска в Btrfs RAID1, механизм отслеживания состояния Live-патчей, фреймворк unit-тестирования kunit, повышение производительности беспроводного стека mac80211, возможность доступа к корневому разделу через протокол SMB, верификация типов в BPF.


В новую версию принято 15505 исправлений от 1982 разработчиков, размер патча - 44 Мб (изменения затронули 11781 файлов, добавлено 609208 строк кода, удалено 292520 строк). Около 44% всех представленных в 5.5 изменений связаны с драйверами устройств, примерно 18% изменений имеют отношение к обновлению кода специфичного для аппаратных архитектур, 12% связано с сетевым стеком, 4% - файловыми системами и 3% c внутренними подсистемами ядра.


Подробнее в Яндекс.Дзен

Показать полностью
10

7 уязвимостей в системе управления контентом Plone

7 уязвимостей в системе управления контентом Plone Python, Xss, Cms

Для свободной системе управления контентом Plone, написанной на языке Python с использованием сервера приложений Zope, опубликованы патчи с устранением 7 уязвимостей (CVE-идентификаторы пока не присвоены). Проблемы затрагивают все актуальные выпуски Plone, включая сформированный несколько дней назад выпуск 5.2.1. Проблемы планируется устранить в будущих выпусках Plone 4.3.20, 5.1.7 и 5.2.2, до публикации которых предлагается использовать hotfix.


Уязвимости (детали пока не раскрываются):


Повышение привилегий через манипуляцию с Rest API (проявляется только при включении plone.restapi);


Подстановка SQL-кода из-за недостаточного экранирования SQL-конструкций в DTML и объектах для соединения с СУБД (проблема специфична для Zope и проявляется в других приложениях на его основе);


Возможность перезаписи контента через манипуляции с методом PUT без наличия прав на запись;


Открытый редирект в форме входа;


Возможность передачи вредоносных внешних ссылок в обход проверки isURLInPortal;


Несрабатывание проверки надёжности пароля в некоторых случаях;


Межсайтовый скриптонг (XSS) через подстановку кода в поле с заголовком.

Отличная работа, все прочитано!