Здравствуйте, Sergey Storozhevykh, Вы писали:

SS>Интересно. Пожалуй....

Я вас поздравляю... Вы в числе не многих в мире, кто теперь знает об этой возможности...

AWW>>NTSTATUS CreateProcessNotify ( LPCWSTR lpApplicationName, ULONG Reason );

SS>Ну остается только добавить, что соглашение о вызовах — STDCALL.

Е-с-т-е-с-т-в-е-н-н-о! И никак иначе.



Да... В конце, я там не очень понятно написал про голосование. Но иными словами — один голос против перевешивает все. Если кто-то проголосовал, против, то процесс образован не будет.


SS> Так что полностью встроенными средствами, по-видимому, никак?

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

Здравствуйте, Andrew.W Worobow, Вы писали:

AWW>Уважаемый SS, к сожалению я достаточно занятой человек. Появится время и я постараюсь популярно обьяснить как что и где...

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

Здравствуйте, Andrew.W Worobow, Вы писали:

AWW>NTSTATUS CreateProcessNotify ( LPCWSTR lpApplicationName, ULONG Reason );

Хотелось бы спросить где можно о таких вещах почитать более конкретно ?
особенно о
> \\Registry\\MACHINE\\System\\CurrentControlSet\\Control\\Session Manager\\AppCertDlls
таких ветках и их содержимом и прилагающемся к ним длл ках ?

Здравствуйте, Romikgy, Вы писали:

R>Хотелось бы спросить где можно о таких вещах почитать более конкретно ?
R>особенно о
>> \\Registry\\MACHINE\\System\\CurrentControlSet\\Control\\Session Manager\\AppCertDlls
R>таких ветках и их содержимом и прилагающемся к ним длл ках ?

Вот здесь и читай. Можешь считать это первоисточником... Да скорее всего это так и есть...

Здравствуйте, Sergey Storozhevykh, Вы писали:

SS>Скорее всего вы имеете в виду проблему с LoadLibraryEx(LOAD_LIBRARY_AS_DATAFILE). Это API некорректно устанавливает атрибут исполнения в DesiredAccess при открытии файла, вследствие чего возможны ложные срабатывания. Это заметно напрягает, например, когда Explorer при отображении содержимого каталога запрашивает иконки из ресурсов бинарников.
нет, я не имел ввиду именно этот случай.

SS>А так, корректно написанная программа должна указывать FILE_EXECUTE только если она действительно хочет исполнить файл, FILE_READ — когда читать.
Корректно написанные программы — разве можно на это полагаться? Особенно там где специально пытаются обойти "хороших парней", полагающихся на "корректные программы". Если любая программа длиннее 100 строк уже потенциально некорректна — в плане багов (периодически встречаются статейки в т.ч. с мат обоснованием по этому поводу и, как правило, с апелляциями к статистике реальных проектов. выводы по качеству в среднем в индустрии стары как мир — оно ужасно, раз программы из 100 строк уже формально некорректны )

PS не знаю куда это лучше вставить и в ответ на чью фразу, посему оставлю тут: на самом деле если рассматривать проблему максимально широко — уметь контролировать запуск любого user-mode кода, запущенного честно через CreateProcess, процессы конструируемые на базе секций (на памяти) умельцами, свои лоадеры, скрипты, 16-bit код и т.п. то запросто может оказаться что даже файловый фильтр или решение Андрея (пока его не пощупал руками сложно сказать для чего оно годится, если даже работает — тотальное отсутствие инфы в гугле настораживает, хотя указанный ключ реестра в kernel32.dll присутствут и это факт. Который был получен через 30 сек после прочтения интереснейшей информации от Андрея

Автор: Andrew.W Worobow
Дата: 18.01.07

) — не покроет всех потребностей. И тут уже можно начинать думать об "альтернативных методах". Но не раньше. Как я неоднократно впрочем говорил

Автор: Valery A. Boronin
Дата: 18.01.07

и говорю

Здравствуйте, Valery A. Boronin, Вы писали:

VAB>решение Андрея (пока его не пощупал руками сложно сказать для чего оно годится, если даже работает — тотальное отсутствие инфы в гугле настораживает, хотя указанный ключ реестра в kernel32.dll присутствут и это факт. Который был получен через 30 сек после прочтения интереснейшей информации от Андрея

Автор: Andrew.W Worobow
Дата: 18.01.07

) — не покроет всех потребностей.


Валер, да работает это работает... А в гугле нет, потому, что "ещё" нет... Теперь будет. Я здесь первый раз про это рассказал... Вот и всё...


TO шареваршики: Спешите проги писать... Это самое "оно" то что называется — KNOW-HOW....


Этот способ, совершенно не безопасен !!!1 ... Обходится так же как и всё... см. описание к вот этому про NtCreateThread...

AWW>Валер, да работает это работает... А в гугле нет, потому, что "ещё" нет... Теперь будет. Я здесь первый раз про это рассказал... Вот и всё...
Андрей, проверил. Супер! все как заявлено в спецификации, вот теперь можно трешку влепить неглядя

AWW>Этот способ, совершенно не безопасен !!!1 ... Обходится так же как и всё... см. описание к вот этому про NtCreateThread...
это понятно. Да ты уже сам сказал про security & safety. согласен сразу был с этим утверждением. потому и был написан PS

Автор: Valery A. Boronin
Дата: 22.01.07

Однако сам способ чувствую, окажется нов не только для меня — и это несомненно ценная информация не только для шареваршиков

PS накидал тут тестовое приложение, блокирующее запуск notepad'a. Исходники проекта + сопутствующие артефакты доступны тут (этот же проект годится для тестирования Windows Logon Notification Packages, WLNP) — кто хочет убедиться что все работает — "налетай торопись, покупай живопись"

краткая инструкция: кладем wlnp.dll в %systemroot%\system32. Если хотим тестить WLNP — пускаем wlnp.reg, если хотим тестить блокировку приложений, регистрируемся через AppCertDlls.reg. Reboot. Достаем DbgView/WinDbg и смотрим логи. Для проверки пытаемся дернуть notepad.exe — навскидку решил блокировать все что имеет слово notepad в пути. Смотрим на экран и в лог.

Вот кусочек реального лога:

CreateProcessNotify: C:\Program Files\Far\Far.exe Reason: 1
CreateProcessNotify: C:\Program Files\Far\Far.exe Reason: 2
//...Far was launched fine. Notepad is being launched....
CreateProcessNotify: C:\WINDOWS\system32\notepad.EXE Reason: 1
CreateProcessNotify: C:\WINDOWS\system32\notepad.EXE Reason: 3
//...and blocked with a fun message (which is RtlNtStatusToDosError(STATUS_UNSUCCESSFUL), I suppose)

PS кстати само тестовое приложение ИМХО лучше годится в кач-ве иллюстрации механизма WLNP

Автор: Valery A. Boronin
Дата: 12.10.06

, чем пример к статье Winlogon notification package

Автор: Роман Бурда
Дата: 23.05.06

от ее автора

Здравствуйте, Andrew.W Worobow, Вы писали:

AWW>Этот способ, совершенно не безопасен !!!1 ... Обходится так же как и всё... см. описание к вот этому про NtCreateThread...
если создавать процесс/поток через native api, они не пройдут регистрацию в csrss, а это необходимо для нормальной работы win32 api

но обойти проверки в самом CreateProcess, конечно, можно — например, пропатчив код kernel32.dll в памяти — и это, кстати, отличает данный метод от других. если проверки выполняются не на клиентской стороне, а в ядре например — пользователь не сможет их обойти не имея административных прав.

Здравствуйте, Andrew.W Worobow, Вы писали:
AWW>Вот здесь и читай. Можешь считать это первоисточником... Да скорее всего это так и есть...
но это не полный список всех возможностей, хотелось бы больше инфы

Здравствуйте, Ivan, Вы писали:

I>Здравствуйте, Andrew.W Worobow, Вы писали:

AWW>>Этот способ, совершенно не безопасен !!!1 ... Обходится так же как и всё... см. описание к вот этому про NtCreateThread...
I>если создавать процесс/поток через native api, они не пройдут регистрацию в csrss, а это необходимо для нормальной работы win32 api

I>но обойти проверки в самом CreateProcess, конечно, можно — например, пропатчив код kernel32.dll в памяти — и это, кстати, отличает данный метод от других. если проверки выполняются не на клиентской стороне, а в ядре например — пользователь не сможет их обойти не имея административных прав.

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

В основу модели безопасности виндоуз, заложен принцип разграничения доступа к объектам системы, который ограничивает действия пользователей вне зависимости от того как эти "действия" оформлены. Не важно как именно называется программа которая пытается получить доступ к файлу. Не важно даже, что "это" — двоичный код или скрипт из текстового файла.

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

Мне лично все эти попытки создания "ограниченной программной среды" смешны... И напоминают затею писать против ветра...

Можно нагородить сложнейшие системы, которые будут блокировать 98% процентов способов исполнить некий код в системе... Но это простите не безопасность, это детский сад, так как если в саму архитектуру системы не заложен такой механизм, не проводилось анализа на полноту, то оставшиеся 2% сразу становятся 100% дырой... И ни о какой безопасность уже и речи быть не может...

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

Здравствуйте, Sergey Storozhevykh, Вы писали:


SS>>>А, понял! Точно, надо установить запрет исполнения устройства. Блин, только вот не пойму какого. Подскажите, а?
...
SS>Для какого конкретно устройства нужно настроить соответствующие атрибуты доступа, в случае необходимости блокировать запуск процессов со съемного USB-диска? Не торопитесь отвечать на этот вопрос, ниже я покажу, что это в принципе невозможно.

///////////////////////////////////////////////////////////////////

Вспоминать и проверять, что конкретно надо по USB времени нет да и честно говоря не охота, но думаю, что и примера с сидюком, вам будет достаточно —

Предположим в вашей системе есть два устройства IDE один жёсткий диск и сд-ром...

Воспользуемся WinObjEx, если вам так больше нравиться —

находим в "\Device\Ide"

\Device\Ide\IdeDevicePOT1L0-c — CD-ROM Drive
\Device\Ide\IdeDevicePOT1L0-4 — Disk Drive

Устанавливаем для устройства \Device\Ide\IdeDevicePOT1L0-c "Deny" "execute", для пользователя «aaa».

запускаем "Commаnd Prompt"

c:\> dir d:

конечно если у вас cd-rom это "D:"

видим содержимое диска, то есть для администратора запрета нет — все работает.


В запускаем RunAs /user:aaa /noprofile cmd.exe

с:\>dir d:\

Access is denied.

Ок. Что и требовалось...

///////////////////////////////////////////////////////////////////

SS>Для того чтобы запретить/разрешить исполнение, вполне достаточно манипуляций с атрибутом EXECUTE. Это, если хотите, необходимое и достаточное условие.

Нет вполне достаточно будет, и "не разрешения чтения"

SS>Поэтому установка атрибутов на объекты устройств не может повлиять на процедуру запуска процессов. Теперь понятно, почему я все время аппелирую к файлам?

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

SS>И, если вы все-таки будете продолжать упорствовать в своем намерении запустить такой фейковый процесс, то значит и ваша хваленая "безопаснось", на которую вы, судя по всему молитесь, не всемогуща?

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

Здравствуйте, Andrew.W Worobow, Вы писали:

[skip]

AWW>Вот здесь и читай. Можешь считать это первоисточником... Да скорее всего это так и есть...

Отвлеченно... кто-то утянул, достал то что кто-то потерял. Но мало кто это досконально читал

Здравствуйте, Andrew.W Worobow, Вы писали:

AWW>Встроенный механизм который я опубликовал, предназначен исключительно для обеспечения safety...
Требование и проверка цифровой подписи драйвера в висте это security или safety? Реализовано это требование таким образом, что даже имея административные права нельзя загрузить неподписанный драйвер. Думаю, дело здесь в том, что даже если речь идет о safety, а не security — инициатором запуска приложения или попытки загрузить неподписанный драйвер может быть не пользователь, а некоторое приложение. в этом случае наличие "дыр" сводит всю safety на нет. можно вспомнить еще DEP — это тоже механизм скорее для безопасности пользователя, но возможность отключить dep программно для процесса привела к тому, что вирусам не составляет труда его обойти.

Здравствуйте, Ivan, Вы писали:

AWW>>Встроенный механизм который я опубликовал, предназначен исключительно для обеспечения safety...

I>Требование и проверка цифровой подписи драйвера в висте это security или safety?

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

Я предложил это деление security и safety, и специально делаю акценты на их различии, только для того, чтобы люди недавно пришедшие в безопасность, ясно чувствовали разницу... Но это ни как не противоположнисти это в некотором роде паралельные вещи. В безопасности есть ещё и такие сушности ( простите за научность — сам терпеть не могу все эти заумные высказывания) как живучесть, целосность, надёжность... и пр. Все они подразумевают ограничение свободы действий пользователя... И в системе могут быть предусмотрены специальные механизмы для обеспечения и облегчения их реализаций, но использовать их, для целей и задач security нельзя.


I>Реализовано это требование таким образом, что даже имея административные права нельзя загрузить неподписанный драйвер. Думаю, дело здесь в том, что даже если речь идет о safety, а не security — инициатором запуска приложения или попытки загрузить неподписанный драйвер может быть не пользователь, а некоторое приложение. в этом случае наличие "дыр" сводит всю safety на нет.

Задачи safety, скроминые — по сути обычный фул пруф... И преодоление её не страшно, а ценность не высока... Поэтому и цена разработки ( а следовательно и качество кода) должна быть адекватной... А ошибки не критичными. Поэтому и её ставят, туда где она стоит. Ну вы поняли.

I> можно вспомнить еще DEP — это тоже механизм скорее для безопасности пользователя, но возможность отключить dep программно для процесса привела к тому, что вирусам не составляет труда его обойти.

Зашита от вирусов, это ещё одна, другая задача, помимо safety и security...

Мне вообще странно, почему так получилось, что у нас всё называется безопасность, а отсюда на мой взгляд вся эта путаница, с целями, задачами и механизмами. На мой взгляд, правильнее было-бы использовать термины безопасность, для safety. Охрана для securuty. Мне кажется, что виной всему товарищ Берия||Сталин — "Министерство Государственной Безопасности"...

Здравствуйте, Andrew.W Worobow, Вы писали:

AWW>TO шареваршики: Спешите проги писать... Это самое "оно" то что называется — KNOW-HOW....

AWW>Этот способ, совершенно не безопасен !!!1 ... Обходится так же как и всё... см. описание к вот этому про NtCreateThread...

спасибо, интересный способ
но я бы не стал на него полагаться — вся проверка в контексте вызовающего процесса
если бы в контексте какого-нибудь csrss более органично бы вписывалось в модель безопасности
ибо требовало бы SeDebugPrivilege или например SeLoadDriverPrivilege

Второй недостаток — слишком просто ломается — check в одном месте ни проверки кода, нифига
к примеру, на моем SP2 мне понадобилось ровно 8 минут
так что шароварщикам это ни к чему
а вот вирмейкерам бы наоборот эта тема очень пригодилась бы

#include <windows.h>
#include <assert.h>

#include <exception>
#include <iostream>
#include <algorithm>

class CLibGuard
{
    HMODULE m_hDll;
    CLibGuard(const CLibGuard &);
    CLibGuard&operator =(const CLibGuard &);
public:
    CLibGuard(HMODULE hDll)
        : m_hDll(hDll)
    {
    }
    ~CLibGuard()
    {
        FreeLibrary(m_hDll);
    }
};

DWORD PatchKernel(unsigned char* pBegin, unsigned char* pEnd)
{
    OSVERSIONINFOW verinfo;
    verinfo.dwOSVersionInfoSize = sizeof(verinfo);
    if (!GetVersionExW(&verinfo))
        throw std::exception("GetVersionExW failed");

    if (verinfo.dwMajorVersion == 5 && verinfo.dwMinorVersion == 1)
    {
        // хотя можно достать из PEB, ну ладно
        if (wcscmp(verinfo.szCSDVersion, L"Service Pack 2") == 0)
        {
            // xp sp 2 
            unsigned char buff[] = {0xFF, 0xB5, 0xE4, 0xF8, 0xFF, 0xFF,
                                    0xE8, 0x4F, 0x05, 0x00, 0x00, 
                                    0x8B, 0xF8, 
                                    0x89};
            unsigned char  * pData = std::search(pBegin, 
                                                 pEnd, 
                                                 buff, 
                                                 buff+sizeof(buff)/sizeof(buff[0]));
            if (pData!=pEnd)
            {
                unsigned char patch[] = {0x33, 0xC0,       // xor eax, eax
                                         0x90, 0x90, 0x90, // nops
                                         0x90, 0x90, 0x90, 
                                         0x90, 0x90, 0x90};

                memcpy(pData, patch, sizeof(patch));
                return sizeof(patch);
            }
            throw std::exception("Unknown kernel version");
        }
    }
    throw std::exception("Unsupported windows version");
}

int main()
{
    try
    {
        HMODULE hKernelDll = LoadLibraryW(L"kernel32.dll");
        CLibGuard scopeGuard(hKernelDll);

        LPVOID pAddress = GetProcAddress(hKernelDll, "CreateProcessW");
        MEMORY_BASIC_INFORMATION mem;
        if (VirtualQuery(pAddress, &mem, sizeof(mem)) )
        {
            DWORD dwOld;
            if (!VirtualProtect(mem.BaseAddress, mem.RegionSize, PAGE_EXECUTE_READWRITE, &dwOld))
                throw std::exception("Access denied");
        } else
            throw std::exception("Query failed");

        // patch
        
        PatchKernel((unsigned char*)mem.AllocationBase, 
                    (unsigned char*)mem.AllocationBase + mem.RegionSize);
    }
    catch(std::exception & e)
    {
        std::cout<<"Initialization error: "<<e.what()<<"\n";
        return -1;
    }

    // test
    STARTUPINFOW si;
    PROCESS_INFORMATION pi;

    memset(&si, 0, sizeof(si));
    if(!CreateProcessW(L"c:\\WINDOWS\\system32\\calc.exe",
                   0,
                   0,
                   0,
                   TRUE,
                   0,
                   0,
                   0,
                   &si,
                   &pi))
    {
        DWORD dwRes= GetLastError();
        assert( dwRes );
        std::cout<<"CreateProcess call failed, code: \n"<<dwRes;
        return -2;
    }

    return 0;
}

AWW>>Встроенный механизм который я опубликовал, предназначен исключительно для обеспечения safety...
I>Требование и проверка цифровой подписи драйвера в висте это security или safety? Реализовано это требование таким образом, что даже имея административные права нельзя загрузить неподписанный драйвер.

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

Здравствуйте, Andrew S, Вы писали:

AS>Слишком сильное утверждение, чтобы быть правдой. Загрузить можно, причем ровно тем же способом, что и в ХР. По крайней мере, я в ультимате такого добился безо всяких проблем...

о каком способе идет речь ? кстати, подпись драйверов, если не ошибаюсь, только на x64 энфорсится

Здравствуйте, Ivan, Вы писали:

I>Здравствуйте, Andrew S, Вы писали:

AS>>Слишком сильное утверждение, чтобы быть правдой. Загрузить можно, причем ровно тем же способом, что и в ХР. По крайней мере, я в ультимате такого добился безо всяких проблем...

I>о каком способе идет речь ? кстати, подпись драйверов, если не ошибаюсь, только на x64 энфорсится
вот здесь кстати описывается один из способов загрузки неподписанных драйверов через pagefile http://theinvisiblethings.blogspot.com/ (тема Vista RC2 vs. pagefile attack ) но эту возможность закрыли в Vista RTM — теперь даже администратор не может напрямую писать на диск.

AS>>Слишком сильное утверждение, чтобы быть правдой. Загрузить можно, причем ровно тем же способом, что и в ХР. По крайней мере, я в ультимате такого добился безо всяких проблем...

I>о каком способе идет речь ? кстати, подпись драйверов, если не ошибаюсь, только на x64 энфорсится

О способе изменения политики проверки подписи путем нахождения нужного хеша непосредственно в setupapi.dll. Насчет х64 не проверял, а на 32-х битной версии способ работает вполне как и раньше. Т.е. все ставится безо всяких вопросов и предупреждений. Вероятно, в х64 они эту схему поменяли, но опять же — слом этого лишь дело времени и желания. За вторым, я думаю, дело не станет, а вот совместными усилиями и первое раздобыть можно

Здравствуйте, Andrew S, Вы писали:

AS>>>Слишком сильное утверждение, чтобы быть правдой. Загрузить можно, причем ровно тем же способом, что и в ХР. По крайней мере, я в ультимате такого добился безо всяких проблем...

AS>О способе изменения политики проверки подписи путем нахождения нужного хеша непосредственно в setupapi.dll. Насчет х64 не >проверял, а на 32-х битной версии способ работает вполне как и раньше. Т.е. все ставится безо всяких вопросов и предупреждений.

мы наверное о разных вещах говорим. помимо предупреждений о подписи драйвера при установке драйвера
на висте x64 ядро отказывается загружать и запускать неподписанные драйверы. например ошибка у регмона выглядит так:

---------------------------
Regmon
---------------------------
Error loading REGMON701: Windows cannot verify the digital signature for this file. A recent hardware or software change might have installed a file that is signed incorrectly or damaged, or that might be malicious software from an unknown source.
--------------------------
OK
---------------------------

>Вероятно, в х64 они эту схему поменяли, но опять же — слом этого лишь дело времени и желания. За вторым, я думаю, дело не станет, а >вот совместными усилиями и первое раздобыть можно
возможно какие-то уязвимости о остались, но в целом схема очень продуманная — подпись драйвера проверяется ядром, а к ядру доступа как раз и нет, для критических системных файлов подпись проверяется при загрузке и есть еще PatchGuard, который будет мешать патчить код, проверяющий подпись драйвера.