Имеется информация о том, что сайт www.ms-dynamics.ru используется для атак на компьютеры пользователей.

[glibs]

В Firefox только что прочитал.

"
...
Имеется информация о том, что сайт www.ms-dynamics.ru используется для атак на компьютеры пользователей.
...
Сайты, атакующие компьютеры, пытаются установить программное обеспечение, которое похищает персональную информацию, вредит вашей системе или использует ваш компьютер для атак на другие компьютеры.

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

Интересно, это правда, или Firefox так воюет с Микрософтом? Откуда у них такие сведения?

[gl00mie]

Цитата:

Сообщение от glibs

В Firefox только что прочитал.

Цитата:

...Имеется информация о том, что сайт www.ms-dynamics.ru используется для атак на компьютеры пользователей...

Интересно, это правда, или Firefox так воюет с Микрософтом? Откуда у них такие сведения?

ОБС да и только... Где подробности "атак на компьютеры пользователей"? Мол, на такой-то странице есть такой-то java-скрипт, который делает то-то и то-то. Или для просмотра такой-то страницы предлагают установить такой-то ActiveX-компонент, который на самом деле делает то-то. А так, информации ноль, только разъяснения для обывателей, как с сайта можно атаковать компьютер. Обывателю при этом не объясняют, что "пытатьтся установить программное обеспечение" на чей-либо компьютер сайт при всем желании не может - это может лишь, к примеру, браузер, тем или иным образом обрабатывающий страницу с сайта, либо сам пользователь, тыкающий по всевозможным ссылкам на страницах. Что именно из этого "пытается" сделать указанный сайт, не сообщается. Или, может, нашли очередную дырку в MSIE, и скрытый посыл сообщения - переходить на Firefox?

[mazzy]

Цитата:

Сообщение от glibs

Интересно, это правда, или Firefox так воюет с Микрософтом? Откуда у них такие сведения?

Майкрософт то тут при чем? www.ms-dynamics.ru принадлежит конкретному человеку и обслуживается конкретным человеком. Этот сайт не принадлежит Майкрософту, насколько я знаю.
Опять ты Глеб рознь раздуваешь на ровном месте.

www.ms-dynamics.ru использует вполне стандартные движки, у которых есть уязвимости. Я не знаю что и как на самом деле, но вместо того, чтобы провозгласить о войне титанов, обратился бы лучше к владельцу/адмнистратору ресурса - может его сайт атаковали и внедрили что-нибудь, об этом FF и предупреждает.

Если же лениво сообщать, то воспольуйся предупреждением FF и не пользуйся сайтом.

См. также
http://yandex.ru/yandsearch?rpt=rad&...%B8%20invision
http://yandex.ru/yandsearch?text=%D1...2%D0%B8+Joomla!

[glibs]

Цитата:

Сообщение от mazzy

...
Опять ты
...

Все ты без фамильярностей никак не можешь...

Цитата:

Сообщение от mazzy

...
рознь раздуваешь на ровном месте
...

"Я прощу прощения, а часовню тоже я разрушил". Цитата может быть неточной, по памяти.

Предлагаю тогда на меня еще "повесить" разжигание первой мировой войны до кучи.

За остальную информацию спасибо. Я пока еще этой фичей пользоваться не научился.

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

[mazzy]

Цитата:

Сообщение от glibs

Откуда у них такие сведения?

Кстати, если тебе это действительно интересно, то на странице с предупреждением есть кнопка "Почему этот сайт заблокирован". Кнопка выводит на страницу гугля
http://safebrowsing.clients.google.c...namics-nav-50/

цитирую:

Цитата:

Of the 1 pages we tested on the site over the past 90 days, 1 page(s) resulted in malicious software being downloaded and installed without user consent. The last time Google visited this site was on 07/04/2008, and the last time suspicious content was found on this site was on 07/04/2008.

Malicious software includes 1 trojan(s). Successful infection resulted in an average of 2 new processes on the target machine.

Malicious software is hosted on 1 domain(s), including 61.155.8.0.

[gl00mie]

В продолжение темы "атак на компьютеры пользователей"... Читая один не относящийся к тематике форума блог, обнаружил там упоминание о занимательной дыре в MSIE. Вот выдержка из упомянутого в блоге доклада Alexander Sotirov & Mark Dowd Bypassing Browser Memory Protections в вольном переводе (стр.33):

Цитата:

MSIE версии 6 и выше позволяет внедрять в страницы элементы управления .NET (иногда именуемые элементами пользовательского интерфейса - UI Controls). Эти элементы управления являются бинарными файлами .NET, которые выполняются в "песочнице" (т.е. в ограниченной контролируемой среде) внутри процесса браузера и могут восприниматься как .NET-эквивалент Java-апплетов, либо как более безопасная замена элементов управления ActiveX. Загружаются эти элементы управления браузером за счет использования тега <OBJECT>:

PHP код:

<OBJECT classid="ControlName.dll#Namespace.ClassName"> 


Синтаксис схож с тем, как внедряются элементы ActiveX, но есть несколько ключевых отличий:

• Вместо GUID атрибут classid содержит URL, указывающий на местоположение исполняемого файла .NET, а также пространство имен и название класса для элемента управления.
• В конфигурации MSIE по умолчанию элементы управления .NET могут быть внедрены в любой странице в зоне Internet. Это поведение можно изменить через закладку настройки безопасности MSIE.
• В отличие от ActiveX, не выводится никаких предупреждений, когда браузер встречает неизвестный прежде элемент управления .NET. Это связано с тем, что такие элементы управления выполняются в "песочнице" и рассматриваются как безопасные независимо от места своего происхождения, подобно тому как рассматриваются Java-апплеты.

Библиотеки .NET являются PE-файлами с дополнительным заголовком, описывающим классы и .NET байткод, содержащийся в библиотеке. Байткод является скомпилированным кодом на Intermediate Language (IL), выполняемым виртуальной машиной Common Language Runtime (CLR). Когда библиотека .NET загружается в браузер, средой выполнения проверяется, что она содержит только IL-код и не содержит исполняемого кода, который бы мог выполняется непосредственно процессором. Фактически же выполняется довольно обширный набор проверок с целью удостовериться, что загружаемый файл является корректным.
Однако, поскольку формат библиотек .NET по структуре является надмножеством формата PE-файлов, CLR отображает их в память как обычные исполняемые файлы. Это значит, что ядро разбирает PE-заголовок и загружает все секции в память точно так же, как и для обычных исполняемых файлов или DLL-библиотек. По ходу этого процесса ядро устанавливает разрешения для каждой секции в соответствии с флагами, прописанными для нее в PE-заголовке. Если бинарный файл содержит исполняемую секцию (т.е. секцию с соответствующим флагом в заголовке), то она будет загружена в память, и ее страницы будут помечены как исполняемые. Все это дает возможность злоумышленнику поместить исполняемый код оболочки в секцию .text (обычное название для секции кода исполняемых файлов, собираемых Microsoft'овским компоновщиком) библиотеки .NET и сделать так, что этот код будет загружен в помеченные как исполняемые страницы памяти в контексте процесса браузера. В Windows XP адрес, по которому будет загружен исполняемый файл, зависит от значения image base, указанного в PE-заголовке этого файла, которое также контролируется злоумышленником.
Возможность разместить исполняемый код оболочки по известному адресу в адресном пространстве обычно имеет первостепенное значение в успешном использовании уязвимости, связанной с нарушением содержимого памяти. Использование элементов управления .NET для размещения такого кода по ряду причину чрезвычайно полезной для злоумышленников:

• Злоумышленник может создать под такой код буфер произвольного размера.
• Злоумышленник не ограничен в том, какие значения байтов можно использовать в таком коде.
• Злоумышленник может также создавать произвольные сложные структуры данных и загружать их по известному адресу в памяти.

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

Проверил сейчас настройки безопасности для зоны Internet в MSIE7 на своем рабочем компе - для .NET-компонент, не подписанных с помощью Authenticode, в настройках запуска стоит "разрешить", т.е. внедряй в страничку что хочешь - MSIE это все тихо-мирно загрузит и запустит у меня на компе

[Aleksey_M]

Цитата:

В Windows XP адрес, по которому будет загружен исполняемый файл, зависит от значения image base, указанного в PE-заголовке этого файла, которое также контролируется злоумышленником.

Указание своего image base не гарантирует, что код будет загружен именно по этому адресу, там уже может быть занято какой-нить библиотекой. А вообще да, вполне может и загрузить, пакость такая.

[gl00mie]

Цитата:

Сообщение от Aleksey_M

Указание своего image base не гарантирует, что код будет загружен именно по этому адресу, там уже может быть занято какой-нить библиотекой.

Помнится, для системных библиотек image base прописан так, чтобы минимизировать вероятность того, что память по указанному адресу в момент их загрузки уже будет занята, - такой же подход можно применить и к своей dll: прописать не штатный адрес 0x00400000, а что-нить "повыше", поближе к границе 2-го гигабайта адресного пространства. Вообще же, здесь была упомянута WinXP в контексте того, что в Vista уже появилась такая вещь, как Address Space Layout Randomization (ASLR). Т.е. Vista специально случайным образом меняет адреса, на которые в адресном пространстве отображаются загружаемые модули. Об этой дополнительной "мере предосторожности" подробно рассказывается в упомянутом докладе - равно как и способах минимизировать эффект этой "меры предосторожности" ОС