В WordPress молча устранена серьезная уязвимость

В WordPress молча устранена серьезная уязвимость

В WordPress молча устранена серьезная уязвимость

В опубликованном 26 января корректирующем обновлении WordPress 4.7.2 без лишней огласки была устранена критическая уязвимость, позволяющая удалённому атакующему без аутентификации изменить содержимое любой страницы через манипуляцию с REST API.

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

Проблема проявляется только в выпусках WordPress 4.7 и 4.7.1, более ранние версии не подвержены проблеме, даже при включении плагина REST API. REST API по умолчанию включён начиная с ветки 4.7 и предоставлет альтернативный способ манипуляции с настойками, комментариями и публикациями. Уязвимость была обнаружена 20 января исследователями из компании Sucuri в процессе реализации инициативы по аудиту открытых проектов. Разработчики WordPress оперативно выпустили обновление и при участии сетей доставки контента Incapsula, Cloudflare и SiteLock убедились, что в трафике не встречаются попытки эксплуатации данной уязвимости, после чего решили на несколько дней придержать сообщение о проблеме, пишет opennet.ru.

Уязвимость вызвана особенностью обработки передаваемых через REST API значений, в частности, передаваемые через $_GET и $_POST параметры имели более высокий приоритет в обработке, чем параметры, закодированные внутри пути. Воспользовавшись данной особенностью атакующий мог передать запрос с идентификатором, включающим не только цифры, но и буквы, и обойти таким образом проверки на наличие полномочий для выполнения операции.

Например, вместо штатного запроса "/wp-json/wp/v2/posts/1234" можно отправить "/wp-json/wp/v2/posts/1234?id=5678helloworld", для которого значение парамера "?id=" будет иметь более высокий приоритет, чем идентификатор в пути "/1234". При проверке прав доступа проверяется наличие идентификатора "5678helloworld" и так как он не найден и не привязан к владельцу, передаётся управление в вызов get_post, который должен завершить запрос не найдя страницу. Но перед вызовом функции get_post осуществляется приведение переменной к целому типу и вместо "5678helloworld" передаётся значение "5678", указывающее на существующую страницу, что приводит не к выходу, а к вызову метода update_item. Отмечается, что в зависимости от используемых плагинов уязвимость может привести не только к подстановке своего содержимого на страницу, но и к выполнению произвольного PHP-кода на сервере. 

Создатель Диспетчера задач объяснил, почему загрузка CPU в Windows врёт

Бывший инженер Microsoft Дэйв Пламмер, приложивший руку к таким знаковым вещам, как поддержка ZIP в Windows и меню «Пуск» в Windows NT, рассказал, как на самом деле Диспетчер задач считает загрузку процессора. И заодно объяснил, почему цифры в этом инструменте иногда кажутся немного странными, особенно если сравнивать их с тем, как компьютер ощущается в реальной работе.

По словам Пламмера, идея просто показать, насколько занят процессор на деле куда сложнее, чем кажется.

Вопросов тут сразу слишком много: занят чем именно, на одном ядре или на всех, прямо сейчас или в среднем за последние секунды, в пользовательском режиме или на уровне ядра? Как только начинаешь во всём этом разбираться, простая шкала загрузки уже перестаёт выглядеть такой уж простой.

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

Самым очевидным решением мог бы быть простой расчёт по времени между обновлениями интерфейса. Но Пламмер от такого подхода отказался: он посчитал, что полагаться на точность GUI-таймера — идея так себе. Он даже сравнил это с попыткой доверить точный ритм метронома, который едет в кузове пикапа по разбитой дороге.

Вместо этого он заложил в Диспетчер задач другой принцип. Утилита запрашивает, сколько процессорного времени каждый процесс суммарно использовал с момента запуска (отдельно в пользовательском и системном режимах).

Затем из нового значения вычитается предыдущее, полученное во время прошлого обновления. Так определяется, сколько CPU-времени процесс съел за конкретный промежуток. А дальше это сравнивается с общим объёмом процессорного времени, которое было израсходовано всеми процессами за тот же период.

Звучит не очень просто, но именно такой метод, по словам Пламмера, даёт более точный результат, чем грубый расчёт по таймеру. Проблема в другом: современные процессоры стали намного сложнее, чем во времена, когда создавался классический Диспетчер задач.

Сегодня на работу CPU влияют динамическое изменение частоты, турбобуст, тепловые ограничения, глубокие режимы простоя и другие механизмы. Из-за этого один и тот же процент загрузки уже не всегда означает один и тот же объём реально выполненной работы. Пламмер привёл образное сравнение: современная загрузка CPU больше похожа не на пройденное расстояние, а на загруженность шоссе. Полупустая трасса с быстрыми спорткарами может перевезти больше, чем полностью забитая дорога со старыми грузовиками.

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

RSS: Новости на портале Anti-Malware.ru