The OpenNET Project / Index page

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



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

Оглавление

Уязвимость в libssh, приводящая к переполнению буфера, opennews (??), 28-Авг-21, (0) [смотреть все]

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


10. "Уязвимость в libssh, приводящая к переполнению буфера"  +/
Сообщение от Аноним (10), 28-Авг-21, 09:33 
Может просто указать размер буфера по максимально длинному хэшу в системе? Это самое простое и вообще не затратное решение, да и памяти экономит текущий способ максимум пару байт на ключ, что можно легко наверстать в другом месте.
Ответить | Правка | Наверх | Cообщить модератору

14. "Уязвимость в libssh, приводящая к переполнению буфера"  +3 +/
Сообщение от And (??), 28-Авг-21, 10:45 
А ещё можно просто проверять в коде поступающее снаружи.

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

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

15. "Уязвимость в libssh, приводящая к переполнению буфера"  –8 +/
Сообщение от ыы (?), 28-Авг-21, 10:58 
Ну, вы если бы писали подобное, я уверен предприняли все необходимые проверки и защиты. К счастью вас не пускают к написанию такого кода. Почему к счастью? Потому что тогда вы бы были заняты делом, и не могли из-за нехватки времени общаться с нами тут...
Ответить | Правка | Наверх | Cообщить модератору

27. "Уязвимость в libssh, приводящая к переполнению буфера"  +1 +/
Сообщение от Урри (ok), 28-Авг-21, 15:13 
Это на какой такой галере люди пашут 24\7?
Ответить | Правка | Наверх | Cообщить модератору

51. "Уязвимость в libssh, приводящая к переполнению буфера"  +/
Сообщение от пох. (?), 29-Авг-21, 00:15 
Ну что вы, что вы, хозяин добр - на большинстве галер рабы могут пару часиков поспать, поесть и поменять носки чтоб хозяину в нос не шибало.

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

16. "Уязвимость в libssh, приводящая к переполнению буфера"  –1 +/
Сообщение от Аноним (16), 28-Авг-21, 11:23 
Не, не, не, ты что, нельзя так делать! Такие проверки лишние, они только жрут ценное процессорное время и оно может тормозить на каком-то говне мамонта. Поэтому и не включают всякие stack-protector. Достаточно заявы погромиста "мамой клянусь, тут все ок" и можно сразу в прод!
Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

17. "Уязвимость в libssh, приводящая к переполнению буфера"  –2 +/
Сообщение от ыы (?), 28-Авг-21, 11:29 
Толи дело электрон.. вот в нем все хорошо... он просто не запускается на говне мамонта и можно делать все необходимые проверки...
Ответить | Правка | Наверх | Cообщить модератору

18. "Уязвимость в libssh, приводящая к переполнению буфера"  +/
Сообщение от Аноним (16), 28-Авг-21, 11:36 
А причем тут электрон? Вам религия не позволяет прописать нужные флаги при компиляции?
Или ваш говнокод просто не скомпилируется с ними или будет падать на каждый чих?))
Или 1% производительности вам важнее безопасности?
Ответить | Правка | Наверх | Cообщить модератору

19. "Уязвимость в libssh, приводящая к переполнению буфера"  +3 +/
Сообщение от Аноним (-), 28-Авг-21, 12:07 
> Или 1% производительности вам важнее безопасности?

Откуда такая большая цифра? На фоне подсчета самого хеша, проверка размера буфера и прочей обвязки теряются.
Заметны будут (в большинстве случаев ненужные, но обычно все время педалируемые в качестве эталонного примера "жырножручести проверок" местными Ылитистами) проверки на выход за границу массива в циклах ...

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

26. "Уязвимость в libssh, приводящая к переполнению буфера"  +/
Сообщение от Аноним (16), 28-Авг-21, 13:58 
Потому что писать меньше одного процента как-то некомильфо))
У этих ребят https://nvlpubs.nist.gov/nistpubs/TechnicalNotes/NIST.TN.186... просадка производительности вообще получилась на уровне погрешности измерений.
Ответить | Правка | Наверх | Cообщить модератору

52. "Уязвимость в libssh, приводящая к переполнению буфера"  +/
Сообщение от Аноним (52), 29-Авг-21, 06:24 
> А ещё можно просто проверять в коде поступающее снаружи.

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

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

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

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




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

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