Слушайте, кто может что-нибудь сказать серьезного о программировании под Linux? Народ чего-то шевелится всякими там Kylix-ами и GNU C — а толку мало..... Надо ли все это????
Переношу в Прочее из Философии программирования.
Если начнётся неконструктивный флейм, топик будет удалён. Если будет что интересное, вернём его в Философию.
Право называться "философским топиком" надо заработать!
Здравствуйте RonWilson, Вы писали:
RW>Слушайте, кто может что-нибудь сказать серьезного о программировании под Linux? Народ чего-то шевелится всякими там Kylix-ами и GNU C — а толку мало..... Надо ли все это????
Здравствуйте RonWilson, Вы писали:
RW>Слушайте, кто может что-нибудь сказать серьезного о программировании под Linux? Народ чего-то шевелится всякими там Kylix-ами и GNU C — а толку мало..... Надо ли все это????
"Если звезды зажигаются на небе, значит это кому-нибудь нужно..."
Здравствуйте RonWilson, Вы писали:
RW>Слушайте, кто может что-нибудь сказать серьезного о программировании под Linux? Народ чего-то шевелится всякими там Kylix-ами и GNU C — а толку мало..... Надо ли все это????
Java вам поможет (может быть).
Как правило Linux — это серверная платформа для Интранет/Интернет.
На серверных платформах (иногда используют Win2000, как правило, работают сервера приложений.
Сервера приложений, как правило, поддерживают Java2 Platform Enterprise edition(J2EE), в частности, Enterprise JavaBeans(EJB — далёкий аналог COM+, но для Java), Java Server Pages(JSP/Servlets).
Итак, Java, благодаря своей многоплатформенности (Windows, Linux, UNIX, MacOS, Netware, VMS,etc.) сегодня представляет единственную независящую от железа платформу, на которой работают около 70% приложений бизнеса.
Конечно, есть сервера приложений и для технологий от MS (DCOM, COM+, ASP, ASP.Net), но они используются ТОЛЬКО на платформе WINTEL и не имеют никакого отношения к Linux.
Сервер приложений MS Windows.NET Server пока находится в стадии разработки.
Microsoft прихлопнула еще трех «клопов»
Джо Уилкокс (Joe Wilcox), CNET News.com
18 октября, 2002, 10:58
<...>
Эти предупреждения пополнили длинный список секьюрити-бюллетеней Microsoft. В начале месяца компания исправила другие ошибки в SQL Server и во всех версиях Windows, а также предупредила об уязвимости Outlook Express. С начала года Microsoft распространила 61 предупреждение об ошибках — это немного больше, чем за весь 2001 год.
В тот же день Microsoft признала факт взлома своего веб-сервера, которым пользуются 20 тыс. бета-тестеров Windows, и порекомендовала им сменить пароли.
Здравствуйте iZEN, Вы писали:
ZEN>Здравствуйте Алекс, Вы писали:
А>>Linux — MUST DIE!
ZEN>Что сегодня? ZEN>Смотрим: http://zdnet.ru/?ID=289922 ZEN>Чт мы видим: ZEN> ZEN>Microsoft прихлопнула еще трех «клопов» ZEN>Джо Уилкокс (Joe Wilcox), CNET News.com ZEN>18 октября, 2002, 10:58 ZEN><...> ZEN>Эти предупреждения пополнили длинный список секьюрити-бюллетеней Microsoft. В начале месяца компания исправила другие ошибки в SQL Server и во всех версиях Windows, а также предупредила об уязвимости Outlook Express. С начала года Microsoft распространила 61 предупреждение об ошибках — это немного больше, чем за весь 2001 год. ZEN>В тот же день Microsoft признала факт взлома своего веб-сервера, которым пользуются 20 тыс. бета-тестеров Windows, и порекомендовала им сменить пароли.
Вообщем Денис же писал, что флуда то не нада. А это флуд, что первое, что второе сообщение.
Можете что хотите говорить о багах в Linux но для них достаточно
быстро выпускаются Update-ы. Тогда как MS баги мусолит годами
Вот 2 сообщения с BugTrack сравните даты
Microsoft: опять двойка.
01.04.02 10:20
Т.е. дырка. Хорошая такая, связанная с подсистемой отладки WindowsNT и
Windows2000. В результате, любой пользователь, даже с самыми
минимальными привилегиями (GUEST, например), сможет выполнить код с
правами администратора. Пример можно посмотреть здесь, а "лекарство" взять
тут.
Источник: PCWorld
Бага в дебаггере
28.05.02 08:16
Microsoft выпустила очередной бюллетень, посвященный
обнаруженной в отладчике Windows NT и Windows 2000
ошибке. Ошибка позволяет пользователю, имеющему доступ к
системе, повысить уровень своих привилегий.
Источник: newsfactor
Дак вот Microsoft-у понадобилось 2 месяца чтобы поправить
баг который они сами оценили как Critical, хотя люди которые
его нашли дали защитную фиговину прямо вместе с ним.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте Алекс, Вы писали:
А>Здравствуйте RonWilson, Вы писали:
RW>>Слушайте, кто может что-нибудь сказать серьезного о программировании под Linux? Народ чего-то шевелится всякими там Kylix-ами и GNU C — а толку мало..... Надо ли все это????
А>Linux — MUST DIE!
Мля, ну говорят же Windows — MUST DIE. Почему Linux нельзя? Или я забыл рожицу поставить?
В принципе ожидал подобную реакцию, но что столько нулей и сразу! Е-мое! Похоже на цензуру!
Я ведь нигого не оскорбил, выражался прилично, кратко, словом не нарушил ни одного правила. И что? Цензура!
Ну просто у меня хорошее настроение с утра было, и просто я забыл наставить рожиц ( )
Давайте, уважаемые дяди, либо уберем нолики, либо обоснуем вашу позицию!
Начнем со свеженайденного страшного Windows-бага, против которого вроде
как нет противоядия. Вкратце о сути идеи. Как известно, в Windows любая
программа может послать любому окну любое сообщение (на самом деле, с
некоторыми оговорками, о которых позже), при этом источник сообщения
определить невозможно. Так было заведено давным давно, и даже не с NT 3.5
(3.1 на самом деле), как пишет автор сообщения, а со старого доброго
16-битного Windows — потому как смена этого механизма привела бы к не
самым большим, но все же проблемам по переносу старого 16-битного софта
под Win32 (если кто не помнит, для перехода индустрии под Win32
потребовался выход Windows'95, до тех же пор многие производители софта
особо и не утруждали себя этим переносом).
Итак, схема взлома. Находим подходящий сервис, исполняющийся из-под
аккаунта, с бОльшими правами, чем наш текущий, который будет способен
принимать оконные сообщения, что мы ему собираемся посылать (грубо
говоря, способный открывать окна . Находим в окне, открытом сервисом,
подходящий элемент управления (edit box) и вставляем туда побольше
символов, включающих в том числе внедряемый код (между делом для этого,
возможно, придется снять ограничение на количество символов, которые
можно вставить в текстовое поле, но и это можно сделать, послав сообщение,
так что это непринципиально). В итоге все это хозяйство оказывается где-то в
недрах адресного пространства данного приложения. Где именно — можно
определить экспериментальным путем, вставив в текст некую сигнатуру и
найдя ее с помощью отладчика. Далее внедренный код надо бы как-то
выполнить. На помощь приходит еще одно сообщение, WM_TIMER, в качестве
одного из параметров которого можно указать адрес callback-функции. Стало
быть, посылаем WM_TIMER, передав адрес, находящийся внутри блока наших
засланных команд, после чего наш засланный код выполняется с правами того
аккаунта, из-под которого был запущен сервис, если повезет — с системными. Из
вышесказанного делается вывод о наличии принципиальной уязвимости
системы передачи сообщений Windows и затягивается очередная песня про
мастдай, потому как MSовцы ничего в ней не хотят менять.
Сразу скажу свое мнение о данной уязвимости. Схема хороша и заслуживает
занесения в список проверяемых потенциальных уязвимостей отдельных
сервисов (по сути это действительно новый класс уязвимостей, аналогичный
buffer overflow), но говорить о жуткой принципиально неизлечимой дырке
рановато. Полный запрет приема сообщений от всех сторонних процессов,
пожалуй, не имеет смысла и потому нереален. Конечно, наличие
идентификатора источника сообщения могло бы пригодиться при
программировании, но и в этом случае его анализ требовал бы усилий со
стороны программиста. К тому же, добавление к сообщению информации об
источнике приведет к необходимости перетряхнуть весь существующий софт,
потому как просто так добавить опциональный параметр в оконную функцию
вряд ли удастся. Наконец, подобная радикальная смена существующего API
просто не нужна, поскольку начиная с NT 3.51 существует вполне рабочий
механизм Window Stations и Desktops, созданный, по утверждению MSDN, в
первую очередь именно для разработчиков интерактивных сервисов и
обладающий всеми средствами по разграничению доступа.
Итак, какие средства у нас есть на руках, чтобы бороться с данной проблемой.
Во-первых, рабочие станции и десктопы, у которых с защитой все в порядке —
сервис, к примеру, вполне в состоянии создать окно, которое будет
выполняться в контексте текущего пользователя. Во-вторых, даже если забыть о
десктопах, есть вполне стандартная схема, обеспечивающая взаимодействие
сервиса с пользователем — написание вспомогательной программки,
запускающейся с пользовательскими правами и тем или иным способом
взаимодействующей с сервисом (по уму — с помощью защищенных объектов
ядра). Далее, не совсем верно утверждение, что WM_TIMER не попадает в
очередь сообщений и его нет возможности игнорировать — цитируя MSDN,
"You can process the message by providing a WM_TIMER case in the window
procedure. Otherwise, the default window procedure will call the TimerProc callback
function specified in the call to the SetTimer function used to install the timer.".
Желающие могут проверить — без какого-никакого цикла обработки сообщений
никакой callback от таймера работать не будет, а стало быть, вставить свою
обработку таки можно. Другой вопрос, кто этим озаботился — тем более что в
оконную функцию сообщение все же не попадет, и проверку придется
встраивать непосредственно в цикл обработки сообщений. Наконец, особые
параноики наподобие авторов PGP, вообще не используют стандартные классы
окон и до кучи используют дополнительный драйвер, защищающий память
приложения.
Таким образом, из общесистемной проблема все-таки переходит в разряд
проблем авторов сервисов, на которых и надо перевести стрелки — в конце
концов, и в проблеме постоянно вылезающих buffer overflow можно обвинять
создателей C, но это нефункционально Вот если б в примере оказался
какой-нибудь стандартный сервис, это было бы гораздо интереснее. Однако ж
ситуация вовсе не безоблачна. Написав этот абзац, полез смотреть, что
творится у меня под носом — увы, сходу нашлась пара примеров, Outpost и
MDaemon, которые, похоже, ведут себя так же. К чести Norton Antivirus, тот
запускает отдельную программку с пользовательскими правами. Видимо, в
целом картина не сильно успокаивающая и можно найти немало других
популярных сервисов, которые можно поймать на эту уловку.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте Anatolix, Вы писали:
A>(Источник bugtrack.ru)
A> Начнем со свеженайденного страшного Windows-бага, против которого вроде A> как нет противоядия. Вкратце о сути идеи. Как известно, в Windows любая
Ну вот Ё-маё. Понеслось. Это видь не канструктив. Суть вапроса была не в том...
Здравствуйте Anatolix, Вы писали:
A>(Источник bugtrack.ru)
[]
Для того, чтобы просмотреть что-либо в чужом процессе ты должен иметь права PROCESS_VM_READ. Ты их не получишь для системных процессов, если не будешь иметь привилегий (которую еще включить надо) SE_DEBUG_NAME. По умолчанию юзера не имеют этой привилегии.
Ну предположим ты админ. Сообщение WM_SETTEXT пересылает текст, а не двоичные данные. Ну ладно, ты написал код, в котором нули не встречаются . Ты каким-то образом посылаешь сервису сообщение о нажатии кнопки, он считывает строку во внутренний буфер.
И чего? Ты будешь сканировать адресное пространство процесса пока не найдешь свою сигнатуру? И сколько ты это будешь делать?
Здравствуйте Anatolix, Вы писали:
A> найдя ее с помощью отладчика. Далее внедренный код надо бы как-то A> выполнить. На помощь приходит еще одно сообщение, WM_TIMER, в качестве A> одного из параметров которого можно указать адрес callback-функции. Стало A> быть, посылаем WM_TIMER, передав адрес, находящийся внутри блока наших A> засланных команд, после чего наш засланный код выполняется с правами того A> аккаунта, из-под которого был запущен сервис, если повезет — с системными.
Может я чего не понимаю — но кто сказал что попытка выполнить код в странице, в которой находяться данные контрола не приведет к исключению?
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте Алекс, Вы писали:
А>>В принципе ожидал подобную реакцию, но что столько нулей и сразу! Е-мое! Похоже на цензуру!
AVK>Ты еще попробуй сказать "С++ — маздай"
Не, С++ я уважаю!
Мля, RSDN'овцы совсем, по моему, заработались. Стоит рожу не поставить сразу в штыки.
Здравствуйте Алекс, Вы писали:
А>И чего? Ты будешь сканировать адресное пространство процесса пока не найдешь свою сигнатуру? И сколько ты это будешь делать?
Нет она вполне возможно будет всегда выкладываться по одному и тому же адресу,
а его можно на своей машине узнать дизассемблером.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте Anatolix, Вы писали:
A>> найдя ее с помощью отладчика. Далее внедренный код надо бы как-то A>> выполнить. На помощь приходит еще одно сообщение, WM_TIMER, в качестве A>> одного из параметров которого можно указать адрес callback-функции. Стало A>> быть, посылаем WM_TIMER, передав адрес, находящийся внутри блока наших A>> засланных команд, после чего наш засланный код выполняется с правами того A>> аккаунта, из-под которого был запущен сервис, если повезет — с системными.
AVK>Может я чего не понимаю — но кто сказал что попытка выполнить код в странице, в которой находяться данные контрола не приведет к исключению?
Кстати да, это тема.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
, как правило, работают сервера приложений.
Е-мое! Похоже на цензуру!
