LINUX.ORG.RU

Потенциальная уязвимость к локальному переполнению буфера в ядрах linux-2.6.x


0

0

Jeremy Fitzhardinge обнаружил незначительную потенциальную уязвимость к локальному переполнению буфера в ядрах 2.6.x. Как сообщает secunia.com уязвимы функции sys32_ni_syscall() и sys32_vm86_warning(). Об эксплуатации этой уязвимости ничего не сообщается, предлагаемое решение - ограничить доступ к системе.

>>> Подробности

★★★

Проверено: Demetrio ()

Вообще, какой-то тупизм с этим sys32_ni_syscall. Зачем вообще было засирать kernel log ненужными сообщениями?

Ну про strcpy(...); я уже вообще молчу.

Благо, кроме как x86_64 это никого не затрагивает.

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

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

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

anonymous:

http://www.ussg.iu.edu/hypermail/linux/kernel/0411.3/1467.html

Что-то вроде того, что Linux на x86_64 пишет в kernel log обо
всех программах, которые пытаются использовать нереализованные
kernel calls. Чтобы сократить вывод они кэшируют имя последней
программы, которая делала некорректный вызов. Для этого заводят
статический буфер из 8 байт и хранят в нем 16 байтовое имя
программы. Чтобы понять как это можно проэксплуатировать нужно
понять куда gcc/ld размещает этот статический буфер (вероятно, для
многих ядер это вообще нельзя проэксплуатировать).

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

> Для этого заводят статический буфер из 8 байт и хранят в нем 16 байтовое имя программы.

Это как? урезают каждый символ до 4 бит, что ли?

или это и есть то самое потенциальное переполнение?

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

>или это и есть то самое потенциальное переполнение?

Оно самое.

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

> у вас еще есть strcpy? с чем вас и поздравляю.

В OpenBSD этой функции в ядре в принципе нет ;-) Как и sprintf.

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

> Самое печальное - что все это уже много раз проходили. Просто

> приходят пионеры, считающие своим долгом что-нибудь

> дописать в ядро, и лепят детские ошибки.

А мейнтейнеры, что эти патчи принимают, в этот момент, видимо, бананы охраняют?

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

ух, здорово, там оказывается не только strcpy, но еще и memcpy, strcmp. мда. вы вообще gcc запускаете? или он у вас не пишет, что использование всякого атавизма плохо сказывается на здоровье?

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

Народ, может я ошибаюсь, но в данном случае-то выполнение команд невозможно, и даже функция не упадет при переполнении... так что не стоит так нервничать

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

ss:

>ух, здорово, там оказывается не только strcpy, но еще и memcpy, strcmp

Чего вы ко _мне_ прицепились, любезный?
Я не пользуюсь strcpy и не приветствую, как это явственно следует из того, что я писал тут в комментариях.

>мда. вы вообще gcc запускаете? или он у вас не пишет, что использование всякого атавизма плохо сказывается на здоровье?

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

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

AK - это Andy Kleen, вроде как.
А вот постфикс меня тоже удивил (может Торвальдс сделал вид, что проверил?).

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