The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Уязвимость в Glibc, эксплуатируемая через скрипты на PHP, opennews (??), 20-Апр-24, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


71. "Уязвимость в Glibc, эксплуатируемая через скрипты на PHP"  +2 +/–
Сообщение от Аноним (71), 21-Апр-24, 08:13 
и это в стандартной либе, а что же творится в миллионах васянских либ
Ответить | Правка | Наверх | Cообщить модератору

75. "Уязвимость в Glibc, эксплуатируемая через скрипты на PHP"  +/–
Сообщение от Аноним (73), 21-Апр-24, 08:30 
Да на тот же вордпресс посмотри и плагины к нему. Проще ssh порт оставить без пароля чем ставить все эти поделки.
Ответить | Правка | Наверх | Cообщить модератору

77. "Уязвимость в Glibc, эксплуатируемая через скрипты на PHP"  +3 +/–
Сообщение от Аноним (77), 21-Апр-24, 08:41 
> и это в стандартной либе, а что же творится в миллионах васянских либ

Проприетарный код недоступен для анализа.

Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

80. "Уязвимость в Glibc, эксплуатируемая через скрипты на PHP"  +/–
Сообщение от n00by (ok), 21-Апр-24, 10:11 
>> и это в стандартной либе, а что же творится в миллионах васянских либ
> Проприетарный код недоступен для анализа.

Доступен. Просто ты про не в курсе, какие варианты для этого возможны. А открытый код за тебя посмотрит Васян, да.

Ответить | Правка | Наверх | Cообщить модератору

153. "Уязвимость в Glibc, эксплуатируемая через скрипты на PHP"  +/–
Сообщение от Аноним (152), 23-Апр-24, 02:12 
> Доступен.

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

> А открытый код за тебя посмотрит Васян

Кому платишь, тот и смотрит.

Ответить | Правка | Наверх | Cообщить модератору

157. "Уязвимость в Glibc, эксплуатируемая через скрипты на PHP"  +/–
Сообщение от n00by (ok), 23-Апр-24, 10:48 
>> Доступен.
> Варианты, которые не вписываются в экономику, существуют, в основном, лишь гипотетически,
> для победы в спорах в Интернетике.

Открытый код приведён в сообщении #103.
Вместо указания на очевидную ошибку, ты ответил демагогией.

ЧИТД. Вариант "открыть сорцы и посмотреть глазами ... с этим может справиться даже студент" является гипотетическим.


Ответить | Правка | Наверх | Cообщить модератору

83. "Уязвимость в Glibc, эксплуатируемая через скрипты на PHP"  +/–
Сообщение от Аноним (-), 21-Апр-24, 11:12 
> Проприетарный код недоступен для анализа.

Любой бинарник доступен для анализа. Для этого даже код не нужен.
А вот сложность этого анализа для открытых и проприетарных приложений отличается на порядки.

В первом случае тебе нужно просто открыть сорцы и посмотреть глазами, натравить на них анализаторы, можно скомпилять и запустить фаззинг. У тебя есть хоть какое-то описание логики в виде документации, комментариев и названий функций/переменных. С этим может справиться даже студент.

Во втором случае тебе нужно дизассемблить исполняемый файл и ковыряться в асме/байткоде. Дока будет в лучше случае в виде описания публичных функций библиотеки. И разбираться в логике уже самому.
Для этого нужно уже быть как минимум хорошим разработчиком с опытом в данной сфере.

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

Ответить | Правка | К родителю #77 | Наверх | Cообщить модератору

88. "Уязвимость в Glibc, эксплуатируемая через скрипты на PHP"  +/–
Сообщение от Аноним (88), 21-Апр-24, 12:36 
>> Проприетарный код недоступен для анализа.
> Любой бинарник доступен для анализа.

Защищённый DRM с SGX-аттестацией (заливается общий анклав, выполняющий произвольный код в анклаве, анклав аттестуется, после аттестации по сети в него передаётся бинарник, остальная система его читать не может, так как он расшифровывается только в самом процессоре, а в физической DDR-5-оперативе хранится в зашифрованном виде, ключ известен только процессору) - недоступен.

Ответить | Правка | Наверх | Cообщить модератору

89. "Уязвимость в Glibc, эксплуатируемая через скрипты на PHP"  +/–
Сообщение от Аноним (-), 21-Апр-24, 12:55 
> Защищённый DRM с SGX-аттестацией

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

Но даже если взять ваш пример - то всё тоже возможно. Просто намного дороже))
en.wikipedia.org/wiki/Software_Guard_Extensions#List_of_SGX_vulnerabilities

Ответить | Правка | Наверх | Cообщить модератору

103. "Уязвимость в Glibc, эксплуатируемая через скрипты на PHP"  +/–
Сообщение от n00by (ok), 21-Апр-24, 15:43 
> В первом случае тебе нужно просто открыть сорцы и посмотреть глазами, натравить
> на них анализаторы, можно скомпилять и запустить фаззинг. У тебя есть
> хоть какое-то описание логики в виде документации, комментариев и названий функций/переменных.
> С этим может справиться даже студент.

Проверим гипотезу практикой?

Как раз из glibc

#define internal_syscall4(v0_init, input, number, arg1, arg2, arg3,     \
              arg4)                        \
({                                    \
    long int _sys_result;                        \
                                    \
    {                                \
    __syscall_arg_t _arg1 = ARGIFY (arg1);                \
    __syscall_arg_t _arg2 = ARGIFY (arg2);                \
    __syscall_arg_t _arg3 = ARGIFY (arg3);                \
    __syscall_arg_t _arg4 = ARGIFY (arg4);                \
    register __syscall_arg_t __s0 asm ("$16") __attribute__ ((unused))\
      = (number);                            \
    register __syscall_arg_t __v0 asm ("$2");            \
    register __syscall_arg_t __a0 asm ("$4") = _arg1;        \
    register __syscall_arg_t __a1 asm ("$5") = _arg2;        \
    register __syscall_arg_t __a2 asm ("$6") = _arg3;        \
    register __syscall_arg_t __a3 asm ("$7") = _arg4;        \
    __asm__ volatile (                        \
    ".set\tnoreorder\n\t"                        \
    v0_init                                \
    "syscall\n\t"                            \
    ".set\treorder"                            \
    : "=r" (__v0), "+r" (__a3)                    \
    : input, "r" (__a0), "r" (__a1), "r" (__a2)            \
    : __SYSCALL_CLOBBERS);                        \
    _sys_result = __a3 != 0 ? -__v0 : __v0;                \
    }                                \
    _sys_result;                            \
})

Ошибка очевидна и описана в книжках для студентов. Тысячеглаз смотрел лет 20, пока она кое-где не всплыла. Но тут то дажестуденты точно разглядят?

Ответить | Правка | К родителю #83 | Наверх | Cообщить модератору

143. "Уязвимость в Glibc, эксплуатируемая через скрипты на PHP"  +/–
Сообщение от n00by (ok), 22-Апр-24, 09:19 
Куда же пропали эксперты? Если ответа не будет, на местом "сообществе" анализаторов следует ставить крест, а распространителей мантры про Тысячеглаза записать в пустозвоны.
Ответить | Правка | Наверх | Cообщить модератору

149. "Уязвимость в Glibc, эксплуатируемая через скрипты на PHP"  +/–
Сообщение от Аноним (149), 22-Апр-24, 19:12 
#define internal_syscall4(v0_init, input, number, arg1, arg2, arg3, arg4)    \
    ({                                                                       \
        long int _sys_result;                                                \
                                                                             \
        {                                                                    \
            __syscall_arg_t          _arg1 = ARGIFY(arg1);                   \
            __syscall_arg_t          _arg2 = ARGIFY(arg2);                   \
            __syscall_arg_t          _arg3 = ARGIFY(arg3);                   \
            __syscall_arg_t          _arg4 = ARGIFY(arg4);                   \
            register __syscall_arg_t __s0 asm("$16") __attribute__((unused)) \
            = (number);                                                      \
            register __syscall_arg_t __v0 asm("$2");                         \
            register __syscall_arg_t __a0 asm("$4") = _arg1;                 \
            register __syscall_arg_t __a1 asm("$5") = _arg2;                 \
            register __syscall_arg_t __a2 asm("$6") = _arg3;                 \
            register __syscall_arg_t __a3 asm("$7") = _arg4;                 \
            __asm__ volatile(".set\tnoreorder\n\t" v0_init "syscall\n\t"     \
                             ".set\treorder"                                 \
                             : "=r"(__v0), "+r"(__a3)                        \
                             : input, "r"(__a0), "r"(__a1), "r"(__a2)        \
                             : __SYSCALL_CLOBBERS);                          \
            _sys_result = __a3 != 0 ? -__v0 : __v0;                          \
        }                                                                    \
        _sys_result;                                                         \
    })
Ответить | Правка | Наверх | Cообщить модератору

156. "Уязвимость в Glibc, эксплуатируемая через скрипты на PHP"  +/–
Сообщение от n00by (ok), 23-Апр-24, 10:34 
5.1.1.2 Translation phases

2. Each instance of a backslash character (\ ) immediately followed by a new-line character is
deleted, splicing physical source lines to form logical source lines. [...]

Ответить | Правка | Наверх | Cообщить модератору

154. "Уязвимость в Glibc, эксплуатируемая через скрипты на PHP"  +/–
Сообщение от Аноним (152), 23-Апр-24, 02:15 
> следует ставить крест, а распространителей мантры про Тысячеглаз

Однако, обсуждаемую уязвимость нашел не ты, а Тысячеглаз. 0:1 в его пользу.

Ответить | Правка | К родителю #143 | Наверх | Cообщить модератору

155. "Уязвимость в Glibc, эксплуатируемая через скрипты на PHP"  +/–
Сообщение от n00by (ok), 23-Апр-24, 10:30 
Я понимаю, что ты не способен увидеть очевидную проблему с кодом выше, но оправдаться хоть как-то очень хочется - примечательно, что за чужой счёт.
Ответить | Правка | Наверх | Cообщить модератору

105. "Уязвимость в Glibc, эксплуатируемая через скрипты на PHP"  +1 +/–
Сообщение от Аноним (105), 21-Апр-24, 15:46 
Серьёзные ничего не анализируют. Серьёзные вставляют сразу в код всё что нужно. Посмотри то же последнее интервью Дурова.
Ответить | Правка | К родителю #83 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру