30 июля 00 года


          
- RU.OS.CMP (2:5015/42) --------------------------------------- RU.OS.CMP -
From : *ghazan@postman.ru                  2:5020/52  Tue 18 Jul 00 07:23
To   : Mike Timonov                                   Wed 19 Jul 00 14:22
Subj : Re: Hадоел inprise/borland
---------------------------------------------------------------------------
From: *ghazan@postman.ru
Reply-To: *ghazan@postman.ru

Hello! "Mike_Timonov" wrote:
>
>  FU> Да. А главный драйвер, вокруг которого все вертится - драйвер
>  FU> Microsoft Mouse. :)
>
>   А кстати, Microsoft выпускает моpе pазного софта и только один пpедмет
>  хаpдвеpа - вышеупомянутую мышь. Символично, пpавда?

Один студиозус, спрошенный на этот же предмет, гордо ответил: "Из железа M$
выпускает клавиатуру и Loopback Adapter".

    С уважением,                         ghazan@postman.ru
        Георгий Хазан.

         
          Выловлено в просторах FidoNet :-) И правда - из софта выпускают почти всё, а из железа - клавы, мыши, да... loopback adapter :-)
         
shutdown
Микрософтоненавистнических страничек сейчас развелось ну очень много, но вот интересных среди них как бы очень мало. эту [http://pla-netx.com/linebackn/index.html] страничку я сначала было принял за одну из тех, которых много, но потом понял, что ошибался. Во первых, не такая уж она и MS-hate (хотя, конечно, ie4 и виндоуз там ругают предостаточно), во вторых - неожиданно большая и проработанная, в третьих... в-общем, рекомендую. Для раскачки - windows 2001 preview [http://pla-netx.com/linebackn/evil/crash.html], для догонки - галерею GUI [http://pla-netx.com/linebackn/guis/index.html], от win 1.01 до AmigaOS или, скажем, GEOS.
          Есть такой жанр, сродни эпистолярному - называется "переписка в средствах массовой информации". Особенно тяжелый случай - переписка в разных изданиях :-)
          На меня сослался Igor's digest [http://digest.idl.co.il/index.phtml?issue=126], на тему дырки в outlook express, ну, и поразоблачал заблуждения немного. Не спорю - заблуждаюсь я часто и регулярно, но стараюсь делать это не слишком глубоко. :-) А теперь - к заблуждениям :-)
          "Заблуждения, если быть точным, на самом деле два. Первое - очевидное. Проблема из серии buffer overflow не имеет отношения ни к самим строкам, ни к их представлению. Появилась эта весьма дорогостоящая человечеству прореха исключительно из-за особенности реализации компиляторов. Язык Си в данном случае - не единственно "опасный". Вот решили, не подумавши о последствиях, размещать локальные переменные функций (говоря терминами Си - автоматические переменные) в стеке. Вариант быстрый, эффективный и... очень ненадежный"
          Л-логично. Но. Я и не говорил, что buffer overflow однозначно связан с Сишными строками - только лишь заявил, что большой процент случаев "перееха буфера" связан именно со строками. Ну, исторически так сложилось что-ли, что стандартная реализация сишных строк способствует их overrun'у и прочим приятностям. Далее. Реализация - это хорошо, но. Попробуйте-ка в, скажем, Паскале, с включенной проверкой выхода за границы массива, сделать переполнение буфера, желательно без использования "сторонних" функций (включая системнное API - ему-то пофиг куда писать, оно само на Сях писано). Скорее всего это таки получится сделать, но не без применения каких-либо ухищрений. А теперь покажите мне реализацию Си, в которой я не смогу затереть "соседний" массив, выйдя за пределы или поэкспериментировав с указателями. Впрочем, опять-таки, возможно такие и есть, но можно ли их называть "языком Си", учитывая что "грязные трюки" с указателями в Си есть штатная и разрешенная вещь.
          Далее. Я в курсе про стек, и в курсе про адрес возврата. Даже соглашусь, что возможность достучаться до адреса возврата через переполнение чего-либо есть куда большая дыра в идеологии, чем какие-то сишные строки и непроверка границ массива. Но - пока вокруг нас винды борются с юниксами, адрес возврата в стеке - объективная реальность, которая, как мы помним, существует независимо от нашего сознания. Вот будут распространены системы, где переполнение буфера не будет приводить к "срыву стека" - тогда уж разберемся.
          "Второе заблуждение связано с тем, что в языке Си строк нет вообще. Керниган и Ричи ничего не решали: базовый тип char* является обычным указателем на память с увеличением/уменьшением на указанное количество sizeof(char) (не единиц! :-) при арифметических операциях над ним. Вот и все. Ассоциировать этот тип со строками не имеет ни малейшего смысла, ибо язык Си есть язык очень низкого уровня. Представление строк, дат, реляционных кортежей, содержания web-страниц и т.п. находится в ведении только лишь разработчиков."
          А тут фигня вот в чем. В том, что строки в языке есть. Чтобы в этом убедиться, достаточно прочитать любую книжку по Си - там будет глава "работа со строками", с обязательными strcat(), strcpy() и прочим. Вот "реляционных кортежей" действительно нет, да и вообще, структур сложнее числовых да адресных штатно не предусмотрено. А значит, дыры в реализации "реляционных кортежей" или библиотек работы со сложнейшей структурой complex (состоящей из {double re; double im;}) будут проблемой разработчиков, но не языка. А вот char*... Поскольку str*() функции стандартно входят в clib - то и строки в Си есть. Поскольку эти странные создания типа char* сплошь и рядом передаются таким необходимым функциям, как fopen(), {f|s}printf() и что совсем плохо - {f|s}scanf() - отказаться от них среднему программисту и написать что-то свое будет морально тяжело. Ну, а что не только программисты готовы пользоваться тем, что "пусть кривое, но уже есть и стандартно", чем искать прямое но нестандартное или писать своё - известно. Ну, а раз уж создатели языка изначально заложили потенциально опасную реализацию "стандартных" строк, то результат более-менее очевиден. И пусть есть strn*(), и пусть в том же *scanf можно явно ограничивать длину вводимой строки - но это же нужно помнить, держать в голове, и не ошибаться при наборе цифири. А точнее - обвешивать все вызовы кружевами из sizeof(s) и... даже не знаю уж, как политкорректно вставить sizeof внутрь форматной строки sscanf.
          А любое усложнение жизни либо отвергается (ну зачем тогда вообще сделали gets(), когда fngets() заведомо безопаснее и столь же функционален), либо приводит к новым ошибкам.
          И даже если святые К и Р, придумывая str*() и gets() рассчитывали на то, что программисты быстренько поймут их нежелательность и нарисуют свою, безопасную, обвязку для всего этого, эти ожидания явно не сбылись. Да и с чего бы им сбываться?
          А веселье продолжается. Великий и могучий браузер Netscape (разработчики которого, похоже, не в курсе, что сеть может быть ресурсом, который надо экономить - как вам попытки загружать анимированный баннер RLE в цикле, непрерывно - просто потому, что expiration у него маленький? А весьма [странное] занятие, на котором я его ловлю регулярно - вытягиваем страничку, на ходу показываем, вытянув полностью - чистим экран и вытягиваем еще раз. После чего уже окончательно показываем. Или говорим, что, мол, эта страничка (которую я даже почти успел прочитать) есть result of POST operation и чуток outdated, поэтому нажмите, плз, reload. Не на всех серверах это помогает. Да - никаких meta refresh нет, и в ie все ok).
          Ну, да ладно. Я не о том. Я опять о буферах и переполнениях. В NN, версий от 3.0 до 4.72, а равно и в mozilla M15, есть переполнение в декодере jpeg [http://rsn.hackzone.ru/cgi-bin/board.mcgi?rsnb0=829.html]. Что, вполне вероятно, можно будет использовать для атаки через картинку :-)
          В исходник я не вглядывался (а по патчу не поймешь - просто добавляется проверка), так что может дело и не в строках, но что половину таких дыр можно было бы предотвратить сменив язык (или еще во времена К и Р внеся в Си нужные ограничения) - я уверен. Да, ограничения - не в реализацию, а в спецификацию. И не думайте, что я сторонник Паскаля - сам пишу на Си :-)
          И АОЗТ dz online [http://www.dz.ru] на что нибудь полезно. Хотя и нравится оно мне все меньше и меньше.
          Оказывается, ICQ (вы только не обижайтесь, если я очевидную вещь скажу - у меня-то icq нет, могу и поудивляться, да и позлорадствовать) теперь не совсем freeware. На днях AOL заставила пользвателей ICQ [http://dz.yandex.ru/00/jul/news-25.htm] любоваться рекламными баннерами. Долго я ждал этого момента, и дождался :-) А что еще веселей - пользователей никто даже не спросил. Просто произошел очередной AutoUpdate, и на миллионы компьютеров сам закачался и установился новый icq, уже с рекламным движком. И делай что хочешь.
          А так ведь можно, кстати, и что-нибудь повеселей закачивать. Я даже не имею в виду собственно AOL (впрочем... был какой-то случай трояна в очень распространенной почтовой программе), а, скажем, хакера-тинейджера из вашей локалки, научившегося спуфить dns-reply и вовремя подставившего под автоапдейт свой сервер...
          Не люблю бесплатности. Точнее, люблю конечно, но приходится всегда держать в голове, что бесплатно, хорошо и надолго - не бывает. Или плохо, или ненадолго. Или - небесплатно.
          ...дело DOS (не путать с DoS!) живет и побеждает. Роутеры "под дос" (точнее, под ka9q) делают, httpd запустить тоже можно, nat есть... да и с клиентской стороны прогресс не остановился. Arachne [http://arachne.cz/] - такой маленький, но симпатичный, браузер под ДОС, живет и обновляется. Сам удивляюсь - дос практически мертв, но тем не менее живет и развивается.
          Счетчик Rambler недавно (наконец-то!) автоматизировал отсекание "хитов" с открытых прокси. Сколько лет хакеры изощрялись в накрутке, и только недавно... :-)
          Прверяют нехитро и довольно надежно. Я когда-то предлагал скриптом искать на альтависте "proxy list", выковыривать все, что похоже на адрес:порт, и сканировать их, здесь же сделано чуть более эффективно.
         
         
From: Serge Aksenov
To: list@banners.net.ru
Subj: Re: [BANNERS] New rules
-----Original Message-----
From: Aleksey Zvyagin <zal@zal.pp.ru>
To: list@banners.net.ru <list@banners.net.ru>
Date: 28 июля 2000 г. 21:02
Subject: Re: [BANNERS] New rules

>Возникает закономерный вопрос: как Рамблер определяет, что такой-то IP -
>публичный прокси, а вот такой - не публичный? Можно, конечно, каждому IP
>адресу проверку устраивать - сканировать у него все TCP порты и потом на
>каждый делать попытку взять какой-нибудь URL.

      1) Проверяются на открытость прокси, честно сообщающие, что они прокси (посредством заголовка X-FORWARDED-FOR, пусть даже обнуленного). Достаточно проверить один стандартный порт 3128 и два стандартных де-факто порта - 80 и 8080. Причем делать это однократно, результат (как положительный, так и отрицательный) заносить в базу данных, перепроверку проводить, скажем, раз в неделю-месяц.

      2) Проверяются на "проксизм" хосты, с которых приходит статистически повышенное число хитов в счетчики. Можно примерно прикинуть, сколько счетчиков Рамблера загружает отдельно взятый белковый клиент, и при превышении такового числа вдвое-втрое - проверить хост на вшивость, все по тем же стандартным портам.

      Таким образом удастся отсеять, я полагаю, порядка 97% открытых прокси-серверов, зацепив при этом максимум сто-двести человек, виновных по определению в кривой настройке локального WinGate'а или аналогичного софта. ;-) Эффект борьбы, я полагаю, мы увидим уже через две недели.

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

--
Сергей Аксенов, webmaster@film.ru
Фильм.Ру, http://www.film.ru
ВидеоГид(R), http://www.videoguide.ru/

=================[ http://www.banners.net.ru ]=====
To unsubscribe, e-mail: list-unsubscribe@banners.net.ru
For additional commands, e-mail: list-help@banners.net.ru
          Хи-хи-хи :-) Неужели правда в SCO Unix есть такая дыра? Презабавнейшая штучка.
          "It seems that I have been hit by bug in HTFS filesystem on SCO Openserver 5. The problem is that You could do unlink("..") and this operation will be successful (if You have permissions) corrupting filesystem. I have discovered this anomaly when investigating constant system crashes when users were deleting mailboxes in Cyrus imap server 1.5.2 There was bad code in imapd that was trying to delete ".." when removing mailbox (newer versions of imapd are fixed). So usual user may severely damage filesystem by doing unlink("..") in subdirectories, where hi has permissions to do this. I had reported this bug to SCO, but they replied that I have problems with hardware."
          А запаяв пару резисторов на плату GeForce256 - можно получить почти настоящую Quadro [http://202.106.168.78/~xtennis/G-Quadro/]. По разным тестам прирост произвидительности - от 1-2% до 6-7 раз. Похоже, нет в мире ничего, что нельзя было бы "разогнать" при помощи кувалды, паяльника и какой-то матери.


Оригинал страницы находится на http://dibr.nnov.ru/issue300700.html.(с) DiBR
При перепечатке ссылка обязательна. <<  *  >>