Обнаружена серьезная уязвимость в антивирусе AVG

Обнаружена серьезная уязвимость в антивирусе AVG

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

По неофициальным данным стало известно о наличии ошибки в приложении AVG LinkScanner, которая может привести к засорению трафика веб-сайтов (флуд), в результате многократных HTTP запросов, а так же ограничению нормальной работы браузера.

Приложение AVG LinkScanner имеет две функции. Первая - Search-Shield, которая отображает рейтинг безопасности для всех результатов поиска, возвращаемых самыми популярными поисковыми службами. И вторая - Surf-Shield, осуществляет проверку веб-страниц в реальном времени на наличие вредоносов, как при переходе по ссылке, так и при введении адреса страницы в адресную строку браузера. Как оказалось, именно при такой проверке возникает проблема.

Дело в том, что при проверке, в самое начало исходного HTML кода страницы добавляется скриптовый элемент, который затем загружает локальный JavaScript файл - avg_ls_dom.js. Таким образом, антивирус подключается между браузером и веб-сайтом, для возможности проверки страницы до того, как будет запущен какой-либо потенциально опасный код.

Загружаемый JavaScript код, как предполагается, создает буфер с контентом загружаемой страницы и перенаправляет его через POST на другой относительный адрес URL - /CC0227228D62/CheckData.

Запрос выглядит следующим образом:
httpRequest.open("POST", "/CC0227228D62/CheckData", false);
httpRequest.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
httpRequest.send(params);

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

В результате запрос будет выглядеть так: <source_ip> - - [12/Oct/2010:00:06:32 -0400] "POST /CC0227228D62/CheckData HTTP/1.1" 404 5486 "http://<url>" "Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100722 YFF35 Firefox/3.6.8" (27)

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

Данная проблема обсуждалась на тематических форумах и блогах, так же как и на франзузком форуме технической поддержки AVG, где компания сообщила о том, что знает о существующей проблеме и работает над ее устранением.

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

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

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

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

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

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

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

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

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

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

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

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