Trustix уже выпустил обновления

>The exploit code will be released next week.

Спасибо, за заботу.

http://lists.netsys.com/pipermail/full-disclosure/2004-February/017498.html

А для каких ядер?

Version: 2.2 up to 2.2.25, 2.4 up to 2.4.24, 2.6 up to 2.6.2 (и, очевидно, 2.6.3)

[shaman@bondarenko shaman]$ ./a.out mmap: Cannot allocate memory created ~65615 VMAs now mremapping 0x40139000 at 0x40135000 Segmentation fault Так что не катит. Fedora Core.

Wed Feb 18 03:07:58 PST 2004
kernels/*: Recompiled to fix another bounds-checking error in the
kernel mremap() code. (this is not the same issue that was fixed
on Jan 6) This bug could be used by a local attacker to gain root
privileges. Sites should upgrade to a new kernel. After installing
the new kernel, be sure to run 'lilo'.
For more details, see:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0077
Thanks to Paul Starzetz for finding and researching this issue.
(* Security fix *)
a/kernel-ide-2.4.24-i486-2.tgz: Patched, recompiled.
(* Security fix *)
----
казалось бы, при чём здесь Slackware

Хотя нет, катит. kernel BUG at mmap.c:1448! invalid operand: 0000 ipx joydev nls_iso8859-1 udf cmpci gameport soundcore sd_mod ide-cd cdrom parport_pc lp parport autofs rfcomm l2cap bluez e100 floppy sg scsi_mod microcode ra CPU: 0 EIP: 0060:[<c0132994>] Not tainted EFLAGS: 00210287

EIP is at insert_vm_struct [kernel] 0x44 (2.4.22-1.2166.nptl) eax: 40136000 ebx: 00001000 ecx: c4ef7898 edx: c4ef7880 esi: 40138000 edi: c4ef79c4 ebp: c4ef7980 esp: cc2a7f18 ds: 0068 es: 0068 ss: 0068 Process a.out (pid: 9398, stackpage=cc2a7000) Stack: ca2f6a80 40135000 cc2a7f2c cc2a7f30 cc2a7f34 40139000 40135000 c4ef7800 00001000 40138000 c4ef79c4 00001000 c01386f7 ca2f6a80 c4ef7980 40139000 00001000 d677d000 cc2a7f84 ca2f6a80 00000000 09cd75b4 c4ef7800 c4ef7980 Call Trace: [<c01386f7>] do_mremap [kernel] 0x3b7 (0xcc2a7f48) [<c0138afc>] sys_mremap [kernel] 0x5c (0xcc2a7fa0) [<c0109747>] system_call [kernel] 0x33 (0xcc2a7fc0)

Code: 0f 0b a8 05 97 09 28 c0 89 2c 24 8b 7c 24 14 8b 74 24 18 8b

[shaman@bondarenko shaman]$

rost@magnetta ~$ make mremap_poc_2
cc     mremap_poc_2.c   -o mremap_poc_2
rost@magnetta ~$ ./mremap_poc_2
mmap: Cannot allocate memory
created ~5346 VMAs
now mremapping 0x05385000 at 0x05381000
kernel may not be vulnerable
rost@magnetta ~$ uname -a
Linux magnetta 2.4.24-grsec #1 Sun Feb 1 01:02:35 EET 2004 i686 unknown
rost@magnetta ~$

Это как раз значит, что катит. Пробовал потом dmesg смотреть?

Да, я уже понял

2.4.25 released
:)

Оперативней стал работать LOR :)

Увидел эту заметку -> глянул письма -> сообщения от Debian с предложением проапгредиться немедленно -> сказал apt-get update;apt-get dist-upgrade и перезагрузился. Обычно сначало письмо и апгрейд, а затем заметка на LOR :)

2.4.25 уязвимо ?

Из http://kernel.org/pub/linux/kernel/v2.4/ChangeLog-2.4.25
Andrea Arcangeli:
o Return proper do_munmap() error code
наверное, это оно

http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.3

Если это оно, то 2.6.3 неуязвимо для этой ошибки:

<akpm@osdl.org> [PATCH] check do_munmap() failure From: Andrea Arcangeli <andrea@suse.de> Return the proper error code

DSA: 438-1, 439-1, 440-1 :)

Up since: Wed Apr 16 13:10:08 2003
Load Average: 119.12 123.33 117.91 (1263 processes)
Ram: 5950784KB
Free: 5308KB
Current bandwidth utilization 241.34 Mbit/s 

Все активно качают ;)))

А это как понимать?

bug@wepserwer:~$ x3 mmap: Cannot allocate memory created ~65530 VMAs now mremapping 0x3FFE5000 at 0x3FFE1000 Segmentation fault bug@wepserwer:~$ dmesg |tail -n 16 kernel BUG at mmap.c:1190! invalid operand: 0000 CPU: 0 EIP: 0010:[<c0126a89>] Tainted: P EFLAGS: 00010287 eax: 3ffe2000 ebx: d6978b40 ecx: d6978bd8 edx: d6978bc0 esi: d6978b84 edi: d6978904 ebp: d69788c0 esp: d5447f50 ds: 0018 es: 0018 ss: 0018 Process x3 (pid: 454, stackpage=d5447000) Stack: d6978b40 d6978b84 d6978904 d69788c0 d69788c0 c012b567 db689c00 c012b5d2 db689c00 d69788c0 d5446000 00001000 db689c1c ffff0001 db689c00 c0114f56 d5446000 d6978840 c012b692 3ffe5000 00001000 00001000 00000003 3ffe1000 Call Trace: [<c012b567>] [<c012b5d2>] [<c0114f56>] [<c012b692>] [<c0106d33>]

Code: 0f 0b a6 04 a1 a7 28 c0 8b 7c 24 10 8b 74 24 14 8b 5c 24 18

пока писал сообщение Current bandwidth utilization 283.46 Mbit/s ;)))

Похоже, что OpenWall патч к 2.4.24 not vulnerable. По крайней мере все проверки там на месте.

http://www.securityfocus.com/advisories/6345 DSA говорит что 2.4.25 и 2.6.3 не уязвимо.

2Rost (*) (18.02.2004 17:27:29)
респект, grsec - самое оно, 2.4.19-grsec до сих пор не обновлял, с позапрошлого года.

угу, аналогично - 2.4.24-grsec и я в танке там где надо.

$ ./a.out
mmap: Cannot allocate memory
created ~65529 VMAs
now mremapping 0x3FFE1000 at 0x3FFDD000
kernel may not be vulnerable
$ uname -r
2.6.3
$

>Похоже, что OpenWall патч к 2.4.24 not vulnerable. По крайней мере все проверки там на месте. 

Угу ;)

ss@xantippe:~/test/mremap_poc_2
mmap: Cannot allocate memory
created ~65865 VMAs
now mremapping 0x40521000 at 0x4051D000
kernel may not be vulnerable
ss@xantippe:~$ uname -a
Linux xantippe 2.4.24-ow1-ck1 #1 Птн Янв 30 09:46:09 MSK 2004 i686 unknown unknown GNU/Linux

http://fedoranews.org/updates/FEDORA-2004-079.shtml

http://fedoranews.org/updates/FEDORA-2004-079.shtml

Офигеть, пофиксили 5 декабря, а зарелизили 18-го

* Thu Feb 05 2004 Dave Jones - Check do_mremap return values (CAN-2004-0077)

> created ~65865 VMAs

Ого, это уже интересно :) А я думал не больше 65535?

>Офигеть, пофиксили 5 декабря,

> Thu Feb 05

Могет все таки февраля а не декабря ? ;)

>Ого, это уже интересно :) А я думал не больше 65535?

С чего бы это ? Как я понял, сия цифра зависит от объема оперативки - 
в данном конкретном случае это 

ss@xantippe:~$ free
             total       used       free     shared    buffers     cached
Mem:        773828     271088     502740          0      42932     128344

[dmi /tmp]$ ./a.out mmap: Cannot allocate memory created ~65531 VMAs now mremapping 0x3FFE9000 at 0x3FFE5000 kernel may not be vulnerable [admin /tmp]$ uname -r 2.2.16

Ядро не патченное...

А как понять такое:
---------------
$ ./a.out
Segmentation fault
$
---------------
Больше никаких сообщений. dmesg пустой, без следов kernel BUG.
Ядро 2.4.24 ванильное (самосборка с включенным ACPI и lm_sensors),
OS Slackware-9.1. Неужели слэкварь опять всех отымела? ;)

Забыл сказать, что выставлены лимиты на память. Может они помешали?

Конечно же слакварь опять всех обставила. А вы все кричите...

mremap.c

> OpenWall патч к 2.4.24 not vulnerable
Sure. I have compared 2.4.24-ow1.diff and patch-2.4.25, they seems to be the same. And yet:
C:\>./test_mremap
mmap: Cannot allocate memory
created ~65874 VMAs
now mremapping 0x40545000 at 0x40541000
kernel may not be vulnerable
C:\>uname -rspm
Linux 2.4.24-ow1-xattr-acl i686 unknown
And yet:
~>./test_mremap
bash: ./test_mremap: Permission denied:
~>uname -rspm
Linux 2.4.21-pre5-ac3-ptrace-ow0-xattr-acl i686 unknown

And there is alos one simple and quick workaround to those who cannot restart with a new kernel ASAP:
=========================
/*
* Hotfix for mremap() vulnerability in <=2.4.23 and other kernels.
*
* (C) Copyright 2004 Wojtek Kaniewski <wojtekka@irc.pl>
* GPLv2, NO WARRANTY OF ANY KIND.
*
* gcc -Wall -O3 -fomit-frame-pointer -c mremap.c
*/

#include <linux/autoconf.h>
#ifdef CONFIG_SMP
#define __SMP__
#endif

#define MODULE
#define __KERNEL__
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/types.h>
#include <linux/sched.h>
#include <linux/errno.h>
#include <linux/mman.h>
#include <asm/unistd.h>

#ifdef MODULE_LICENSE
MODULE_LICENSE("GPL");
#endif

extern void *sys_call_table[];
static unsigned long (*old_mremap)(unsigned long, unsigned long, unsigned long, unsigned long, unsigned lo
ng);

static unsigned long new_mremap(unsigned long addr, unsigned long old_len, unsigned long new_len, unsigned
long flags, unsigned new_addr)
{
if ((flags & MREMAP_FIXED) && !new_len && (new_addr != addr)) {
printk("possible mremap() exploit attempt. uid=%d, comm=\"%.100s\"\n", current->uid, curre
nt->comm);
return -EPERM;
}

return old_mremap(addr, old_len, new_len, flags, new_addr);
}

int init_module()
{
unsigned long flags;

save_flags(flags);
cli();

old_mremap = sys_call_table[__NR_mremap];
sys_call_table[__NR_mremap] = new_mremap;

restore_flags(flags);

return 0;
}

void cleanup_module()
{
unsigned long flags;

save_flags(flags);
cli();

sys_call_table[__NR_mremap] = old_mremap;

restore_flags(flags);
}

===========================

Блядь! Когда вы научитесь слово "привИлегии" писать?!!

Пофиг. Все равно exploit работает.

> Пофиг. Все равно exploit работает.
Пофиг на Что? В ow exploit не работает.

"hotfix" таковым не является

2 anonymous (*) (19.02.2004 10:52:16):

Subj.

в рассылках встретил ссылку на hotfix

http://linux.bkbits.net:8080/linux-2.4/diffs/mm/mremap.c@1.8?nav=index.html|Chan geSet@-4d|cset@1.1323

marat@darkness:~$ gcc -W -Wall mremap_poc_2.c -o mremap_poc_2
marat@darkness:~$ ./mremap_poc_2
mmap: Cannot allocate memory
created ~65530 VMAs
now mremapping 0x3FFE5000 at 0x3FFE1000
kernel may not be vulnerable
marat@darkness:~$ cat /proc/version
Linux version 2.6.3-mm1-rsbac (marat@darkness.tps.uz) (gcc version 3.2.3) #20 Thu Feb 19 16:47:11 UZT 2004

в dmesg ничего нет

зы. Ядро 2.6.3 + mm1 + rsbac рулят ;)

Как какой то "hotfix" связан с 2.4.24-ow1 ?

Идем на http://openwall.com/linux/

и читаем

February 19, 2004 The second mremap(2) system call vulnerability discovered and made public by Paul Starzetz yesterday does NOT affect Linux 2.4.23-ow2 and 2.4.24-ow1. A variation of it does, however, affect Linux 2.2.x. Linux 2.4.25-ow1 (just an update to Linux 2.4.25, not security critical for most users) and 2.2.25-ow2 (with the security fix) will be made available shortly.

[rooty@zeelog:tmp]$ ./mm
mmap: Cannot allocate memory
created ~65531 VMAs
now mremapping 0x3FFE9000 at 0x3FFE5000
kernel may not be vulnerable
[rooty@zeelog:tmp]$ uname -r
2.2.25

Alpha

гы - фиксит. но оригинально. это ведь всего лишь модуль, предотвращающий использование mremap. именно что "hotfix".

>> Ого, это уже интересно :) А я думал не больше 65535?
> С чего бы это ?
По ссылке ходил?

This happens if one tries to unmap
middle part of an existing memory mapping and the process's limit on the
number of VMAs has been reached (which is currently 65535).

>> Ого, это уже интересно :) А я думал не больше 65535? 
> С чего бы это ? 
>По ссылке ходил? 
 
>This happens if one tries to unmap 
>middle part of an existing memory mapping and the process's limit on >the 
>number of VMAs has been reached (which is currently 65535). 

На заборе "x@й" написано, а там дрова лежат (c) Народный

hint: То что выводится в коде ИХсплоита как число созданных VMA  не является строго говоря man_count - это именно число вызовов mmap() не более того

как вы думаете - что делает следующий код из mmap.c
который идет сразу за вышеописанной проверкой лимитов ? ;)

/* Can we just expand an old anonymous mapping? */
	if (!file && !(vm_flags & VM_SHARED) && rb_parent)
		if (vma_merge(mm, prev, rb_parent, addr, addr + len, vm_flags))
			goto out;



Фокус в том что при входе в процедуру main() процесс уже имеет ненулевое число
отмапленных областей ненулевой длины.

Просто попробуем вызвать mmap() РОВНО 65536 раз и посмотрим на РЕАЛЬНЫЙ
map_count

ss@xantippe:~/$ mremap_poc_2 & cat /proc/`ps ax | grep mremap_poc_2 | cut -d " " -f 2 `/maps | wc -l; killall -9 mremap_poc_2
[1] 4949
  65208
^^^^^^^^^


Идея понятна ?

интересно, когда Линусу надоедят рутовые эксплоиты? может уже пришло время задуматься над модуляризацией сервисов? Линус большой противник микроядра, но надо как-то выходить из положения, железо будет развиваться такими темпами ещё хрен знает сколько, и без переписывания кучи кода не обойтись, а программёры как и все люди ошибаются, архитектура системы должна это учитывать. Не нравится микроядро - давай своё не менее мощное решение. Вон интел уже helper-threading двигает, скоро до подпроцессоров додумается. Монолитное ядро на такой железяке уже проиграет микроядерному с с параллельным выпролнением ядрёных сервисов...

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