LINUX.ORG.RU

[C] Безопасность библиотечных функций


0

0

Пишу на работе проект. После первичной проверки кода заказчиком имеем следующее:

Максимальный риск
Функция: access
Уязвимость функции:
Если атакующий сможет воспользоваться одним и тем же ресурсом в промежуток времени между вызовом access() и фактическим использованием файла то он сможет воспользоваться условиями перехвата (race condition). Возникает блокировка обоих процессов или происходит сбой в программе или с возможностью получения атакующим прав суперпользователя.
Рекомендации по устранению:
Установите верно права доступа для текущего процесса (например используя setuid()) или откажитесь от использования access()

Примерно тоже самое написано про mkdir. Хотелось бы знать Ваше мнение по этому поводу. И если все это так, то предложите более безопасную замену этим функциям.


При чём тут замена функций? Написано же:

Установите верно права доступа для текущего процесса


Вполне здравая мысль.

LamerOk ★★★★★ ()
Ответ на: комментарий от LamerOk

Можно поподробнее? Ато я никак не пойму как это сделать.

Torvus ()

Кстати, очень интересно, что значит: верные права доступа процесса?

Torvus ()

Что касается access, то может лучше сразу делать с файлом open (или что там ещё), не проверяя перед этим права доступа, и проверять потом errno?

undet ()
Ответ на: комментарий от beastie

Ну хорошо. Допустим. Как мне понизить себе права, не зная ни одного непривилегированного пользователя в системе?

Torvus ()
Ответ на: комментарий от undet

Я тоже об этом подумал и где можно так сделать уже сделал.

Torvus ()
Ответ на: комментарий от Torvus

Требовать для работы программы наличие в системе непривелигированного пользователя X.

undet ()
Ответ на: комментарий от Torvus

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

int
drop_priv(char *user)
{
        struct  passwd *pw;
        int     size = 10;
        gid_t   groups[size];

        if (!user)
                user = defuser;

        pw = getpwnam(user);

        if (!pw) {
                syslog(LOG_ERR, "no such user %s", user);
                return -1;
        }

        getgrouplist(user, pw->pw_gid, groups, &size);

        if (setgroups(size, groups) ||
            setresgid(pw->pw_gid, pw->pw_gid, pw->pw_gid) ||
            setresuid(pw->pw_uid, pw->pw_uid, pw->pw_uid)) {
                syslog(LOG_ERR, "failed to drop privs");
                return -1;
        }

        return 0;
}

beastie ★★★★★ ()
Ответ на: комментарий от beastie
        if (!user) 
                user = defuser; 

лишнее — это у меня fallback в одном поекте был

beastie ★★★★★ ()
Ответ на: комментарий от undet

А в чём проблема с mkdir?

Функция: mkdir
Уязвимость функции:
Если атакующий сможет воспользоваться одним и тем же ресурсом в промежуток времени между вызовом mkdir() и фактическим использованием файла то он сможет воспользоваться условиями перехвата (race condition). Возникает блокировка обоих процессов или происходит сбой в программе или с возможностью получения атакующим прав суперпользователя.
Рекомендации по устранению:
Установите верно права доступа для текущего процесса (например используя setuid()) или откажитесь от использования mkdir()

Torvus ()

Про привелегии (и не только) хорошо расписано вот в этой книге: http://oreilly.com/catalog/9780596003944

Там же на странице слева есть ссылка на исходники из книги.

undet ()
Ответ на: комментарий от Torvus

Ничего не понял :). Есть более подробное/доступное описание этой проблемы с mkdir? Если есть, дайте сслыку.

undet ()
Ответ на: комментарий от undet

>Ничего не понял :). Есть более подробное/доступное описание этой проблемы с mkdir? Если есть, дайте сслыку.

Видимо это:

http://seclab.cs.ucdavis.edu/projects/vulnerabilities/doves/2.html

Вообще мутная штука, так как mknod вроде как принимает ID пользователя при создании, а значит откуда директория, созданная с рутовскими правами. Да и вышеуказанной ссылке много лет.

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

anonymous ()
Ответ на: комментарий от Torvus

> Функция: mkdir

Уязвимость функции:


Чувак тебе дело толкует - уязвимость на файловых операциях была довольно популярной атакой на локалхосте. В идеале, весь код, требующий рута, надо свести к минимуму, всё остальное делать от дяди васи и избегать (даже от дяди васи) неатомарных операций с ФС.

LamerOk ★★★★★ ()
Ответ на: комментарий от undet

> Требовать для работы программы наличие в системе непривелигированного пользователя X.

Можно эту идею развить и требовать для работы вообще всё необходимое окружение (файлы, директории). А окружение это создавать исключительно в однопользовательском режиме, для пущей безопасности.

undet ()
Ответ на: комментарий от anonymous

http://seclab.cs.ucdavis.edu/projects/vulnerabilities/doves/2.html

Это не то, не актуально для Linux, mkdir уходит прямо в ядро и сразу создается каталог с заданными правами. Последовательного вызова mknod и chown нет.

В общем, ИМХО, название топика некорректно. Дело не в уязвимости библиотечных функций, а в их некорректном использовании. Хотя не факт, что первичная проверка был корректна, может просто заметели использование access() и выдали готовый шаблон.

mky ★★★★★ ()
Ответ на: комментарий от mky

может просто заметели использование access() и выдали готовый шаблон.

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

Torvus ()
Ответ на: комментарий от Torvus

> еще много подобных уязвимостей, не имеющих никакого отношения к моему проекту.

Авторы тех проектов, в отношении которых эти уязвимости были использованы, тоже думали, что к _их_ проектам эти уязвимости никакого отношения не имеют... )))

LamerOk ★★★★★ ()
Ответ на: комментарий от LamerOk

т.е. ты предлагаешь совсем не использовать mkdir?

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.