Új infók a PaX "expand_stack() sebezhetőség"-ről

Kernel

Frissített grsecurity (PaX) patchek jelentek meg arra az "expand_stack() bug"-ra, amelyet a Digital Armaments nevű cég jelentett nemrég. A grsecurity csapat eleinte FUD-nak minősítette a sebezhetőséggel kapcsolatos híreket, de úgy néz ki mégiscsak valós lesz a dolog. A grsec csapat szerint DA figyelmeztetőjével ellentétben a hiba nem az "expand_stack()" függvényben van, és csak az a rendszer érintett, amelyen a SEGMEXEC funkció engedélyezve van. A grsec csapat úgy gondolja, hogy a bug privilégium szint emelésre nehezen használható ki. Bővebb infók itt.

( trey | 2007. 01. 24., sze – 08:56 )

Még egy "elnézést a Digital Armaments-től, hogy FUD-ot kiáltottunk" belefért volna a grsec csapat "bejelentésébe".

--
trey @ gépház

Köszi, hogy figyelmeztetsz, én fordítottam, így tudom miről van szó. Mindenesetre a DA figyelmeztetéséből kifolyólag "jöttek rá", hogy probléma van. Ha egy köszönöm nem is, de egy "elnézést" elfért volna. Nem beszélve arról, hogy a DA azt állítja, hogy más problémáról is tud. Kicsit kisebb arccal kellene fogadni az ilyen advisory-kat, mert ha mégis van probléma, akkor elkerülhető a kínos pofáraesés esete. Ez nem csak a grsec-nek, hanem úgy általában véve mindenkinek hasznos lehet.

--
trey @ gépház

vicces, hogy nem programozo letedre ilyen jol tudod, hogy mit kellene vagy nem kellene csinalnunk. de ha mar szoba hoztad, nezzuk ki is esett pofara (ugye nem az ominozus tavalyi, csendben javitot linux kernel bugok ota bassza a csorodet (btw, van azota uj, erdekel? ;-), hogy pofara estel, es most probalsz elegtetelt venni?).

egy egyszeru peldaval illusztralom, hogy mi is tortent valojaban. ugye mindenki hallott mar az strcpy() nevu csodarol ('man strcpy' ha nem). ennek a fuggvenynek megvan az a jo tulajdonsaga, hogy eleg gyors, de cserebe nem olyan robusztus, mint lehetne. pl, ervenytelen mutatokkal meghivva siman segfault-ol, vagy nem megfeleloen megvalasztott meretu celpuffernel siman tulszalad rajta.

mindezen fogyatekossagai ellenere meg senki nem vadolta meg azzal (na jo, OpenBSD-t leszamitva, de az 'strlcpy cure is worse than the disease', szoval az nem szamit), hogy bugos. ahelyett dokumentalt, hogy mit csinal es az ot hasznalo programozotol elvaras, hogy betartsa a szabalyokat.

persze az strcpy() csak egy pelda, kb. minden program minden fuggvenye (akar publikus konyvtare vagy csak a progi sajat belso hasznalatuja) tele van ilyen 'elvarasokkal' (angolul asszem contract-nak hivnak), es sajnos a legtobb programozasi nyelv nem teszi lehetove, hogy minden ilyet kodban is kifejezzunk (es mar forditaskor megtalaljuk az ilyen szabalyok be nem tartasabol eredo hibakat), ezert marad a dokumentalas (mar amikor), ill. a kodolvasas, teszteles, stb (meg van egy kulon kis tudomany a statikus ill. dinamikus kodellenorzesre, metacompilation, model checking meg tarsai, ha valakit erdekel).

visszaterve az expand_stack()-re, itt sincs semmi gond vele, csak vannak bizonyos elvarasok, amiket az ot hivonak be kell tartani, es ez az, ami nem sikerult minden esetben. egeszen pontosan ket hivas erdekes. az egyik az, ami a userland verem automatikus noveleset vegzi (ide kerult az igazi javitas), a masik pedig egy erdekes belso allat (get_user_pages()), onnan siman kiszedtem az egesz veremnovelest, mindjart elmondom miert.

olyan ket evvel ezelott egy masik bug javitasa soran mar belefutottam ebbe a get_user_pages()-be, ami a kernel belso infrastrukturaja arra, hogy szukseg eseten fizikai memoriaba kenyszeritse a kivant userland memoriatartomanyt (hogy azutan oda segfault veszelye nelkul tudjon irni pl). a problema az, hogy ez a hivas is kepes kivaltani a veremszeru tartomanyok automatikus novekedeset, ami egyaltalan nem tervezett tulajdonsaga, hanem sok evvel ezelott orokolte egy ptrace-szel kapcsolatos kodkonszolidaciobol (hogy a ptrace-nek miert volt ra szuksege, az egy kulon rejtely). en anno megkerdeztem ket linux VM gurut is (akpm meg Hugh Dickins) es egyiknek sem volt otlete ra, hogy vajon mi a francert is vannak igy a dolgok. most viszont itt volt a kivalo alkalom, hogy megszabaduljak ettol (az elozo bugnal vegulis nem tettem meg, mert az egesz bugfix befuccsolt, ugyanis tul sok mindent kellett volna atirni, es a nyereseg nem lett volna eleg nagy).

na, osszefoglalva, a DA mogott allo jomadarak jo kis 'wild-goose chase'-re kuldtek minket, es trey allitasaval ellentetben az eredeti advisory nem segitett semmit, a PoC 'exploit' volt az, ami megmutatta, hogy hol is volt az igazi problema (a masodik advisory szovege is pont olyan gagyi volt, mint az elsoe).

a bug, amit igazabol talaltak, az persze letezik, es DoS-ra kivalo, viszont privilegium emelesre onmagaban nehez kihasznalni, mert minden automatikus veremnoveles soran a kernel kinullazza a megnovelt verem legalso lapjat, ami a kernelbe nyulo vma eseten ugye azt jelenti, hogy egy random kernel memorialap hirtelen 0-ba allitodik - ezt vagy tuleli vagy nem. viszont ha letezik tetszoleges kernel memoriat olvaso bug valahol, akkor annak segitsegevel nagyon pontosan lehet elvegezni ezt a nullazast es akkor tenyleg ki lehet hasznalni tetszoleges privilegium emelesre. vegul, de nem utolso sorban, az egesz bug nem triggerelheto, ha valaki rendesen hasznalja a grsec-et, vagyis a PaX flag-ekre is mandatory control-t hasznal, minden mas gyengitett felallas es ilyenkor jol latszik, hogy miert.

trey, szerintem meg kene fogadnod a sajat tanacsodat, es kicsit kisebb arccal kene futtatni ezt a blogot, mert ha meg sincs igazad, akkor elkerulheto a kinos pofaraeses esete.

Így van, így továbbra is azt tanácsolom minden magában vakon bízó programozónak, hogy ha valaki bugot jelent neki, aki ne FUD-ot kiáltson, hanem álljon neki, aztán nézzen körül a kódjában. Kíváncsi lennék, hogy ha nem lett volna a DA bejelentése, akkor megszületett volna-e ez a javítás. Ha meg nincs hiba, akkor mire fel a javítás? Továbbá a DoS nem hiba? Szóval nekem itt kis ellentmondások vannak, és ez az egész kicsit utólagos magyarázkodásnak tűnik.

--
trey @ gépház

ha valaki bugot jelent neki, aki ne FUD-ot kiáltson, hanem álljon neki, aztán nézzen körül a kódjában

Egyrészről nem _neki_ jelentették bugot, hanem egy levlistára küldték be, mint potenciális ügyfél csalogató. Másrészről nem kiáltott FUD-ot először, hanem körülnézett a kódjában, de az expand_stack() függvényben - amelyre az advisory hivatkozott - nem talált semmiféle hibát. (Ezeket mind le is írta spender).

Kíváncsi lennék, hogy ha nem lett volna a DA bejelentése, akkor megszületett volna-e ez a javítás.

Nyilván nem, de ha csak az első bejelentés marad és semmi további info nem érkezik, akkor sem, mert az advisory félrevezető volt.

Ha meg nincs hiba, akkor mire fel a javítás? Továbbá a DoS nem hiba? Szóval nekem itt kis ellentmondások vannak, és ez az egész kicsit utólagos magyarázkodásnak tűnik.

Nem a hiba volt a kérdéses, hanem hogy kihasználható-e, tekintve az Advisory azt hirdeti, hogy "local root", illetve "privilege escalation", amely esetén egy ilyen "cégnél" az ember joggal gondolhatja, hogy van hozzá exploit is, pedig nincs.

csendben javitot linux kernel bug

Ha esetleg tudsz újabb ilyenről, és megosztanád részleteiben, sz'tem sokan megköszönnénk. / főleg akik nem a vanilla-t használjuk, mondjuk mert kb. nincs időnk a heti változásait követni :-) /

ehhez kapcsolódik a másik kérdésem, a "csak a kérdéses hibát" javító patch kb. ez ?, / ami mondjuk kis csúszással nem csak vanilla 2.6.19.2re is alkalmazható /

trey-től előre is bocs a hosszú beillesztésért. 


diff -Nru regi2.6.19.2/arch/i386/kernel/efi.c linux-2.6.19.2/arch/i386/kernel/ef
i.c
--- regi2.6.19.2/arch/i386/kernel/efi.c 2007-01-24 00:00:19.000000000 +0100
+++ linux-2.6.19.2/arch/i386/kernel/efi.c       2007-01-24 00:01:22.000000000 +0
100
@@ -72,7 +72,7 @@

        clone_pgd_range(efi_bak_pg_dir_pointer, swapper_pg_dir, KERNEL_PGD_PTRS)
;
        clone_pgd_range(swapper_pg_dir, swapper_pg_dir + USER_PGD_PTRS,
-                       USER_PGD_PTRS >= KERNEL_PGD_PTRS ? KERNEL_PGD_PTRS : USE
R_PGD_PTRS);
+                       min_t(unsigned long, KERNEL_PGD_PTRS, USER_PGD_PTRS));

        /*
         * After the lock is released, the original page table is restored.
diff -Nru regi2.6.19.2/arch/i386/kernel/head.S linux-2.6.19.2/arch/i386/kernel/h
ead.S
--- regi2.6.19.2/arch/i386/kernel/head.S        2007-01-24 00:00:19.000000000 +0
100
+++ linux-2.6.19.2/arch/i386/kernel/head.S      2007-01-24 00:01:22.000000000 +0
100
@@ -261,6 +261,7 @@
        /* Make changes effective */
        wrmsr
        btsl $63,__supported_pte_mask-__PAGE_OFFSET
+       movl $1,nx_enabled-__PAGE_OFFSET

 4:
        movl %edi,%ebx
diff -Nru regi2.6.19.2/arch/i386/kernel/reboot.c linux-2.6.19.2/arch/i386/kernel
/reboot.c
--- regi2.6.19.2/arch/i386/kernel/reboot.c      2007-01-24 00:00:19.000000000 +0
100
+++ linux-2.6.19.2/arch/i386/kernel/reboot.c    2007-01-24 00:01:22.000000000 +0
100
@@ -227,7 +227,7 @@
 #endif

        clone_pgd_range(swapper_pg_dir, swapper_pg_dir + USER_PGD_PTRS,
-                       USER_PGD_PTRS >= KERNEL_PGD_PTRS ? KERNEL_PGD_PTRS : USE
R_PGD_PTRS);
+                       min_t(unsigned long, KERNEL_PGD_PTRS, USER_PGD_PTRS));

 #ifdef CONFIG_PAX_KERNEXEC
        pax_close_kernel(cr0);
diff -Nru regi2.6.19.2/arch/i386/mm/fault.c linux-2.6.19.2/arch/i386/mm/fault.c
--- regi2.6.19.2/arch/i386/mm/fault.c   2007-01-24 00:00:19.000000000 +0100
+++ linux-2.6.19.2/arch/i386/mm/fault.c 2007-01-24 00:01:22.000000000 +0100
@@ -541,6 +541,12 @@
                if (address + 65536 + 32 * sizeof(unsigned long) < regs->esp)
                        goto bad_area;
        }
+
+#ifdef CONFIG_PAX_SEGMEXEC
+       if ((mm->pax_flags & MF_PAX_SEGMEXEC) && vma->vm_end - SEGMEXEC_TASK_SIZ
E - 1 < address - SEGMEXEC_TASK_SIZE - 1)
+               goto bad_area;
+#endif
+
        if (expand_stack(vma, address))
                goto bad_area;
 /*
diff -Nru regi2.6.19.2/include/linux/mm.h linux-2.6.19.2/include/linux/mm.h
--- regi2.6.19.2/include/linux/mm.h     2007-01-24 00:00:21.000000000 +0100
+++ linux-2.6.19.2/include/linux/mm.h   2007-01-24 00:01:23.000000000 +0100
@@ -1126,7 +1126,6 @@
 }

 pgprot_t vm_get_page_prot(unsigned long vm_flags);
-struct vm_area_struct *find_extend_vma(struct mm_struct *, unsigned long addr);
 struct page *vmalloc_to_page(void *addr);
 unsigned long vmalloc_to_pfn(void *addr);
 int remap_pfn_range(struct vm_area_struct *, unsigned long addr,
diff -Nru regi2.6.19.2/kernel/futex.c linux-2.6.19.2/kernel/futex.c
--- regi2.6.19.2/kernel/futex.c 2007-01-24 00:00:22.000000000 +0100
+++ linux-2.6.19.2/kernel/futex.c       2007-01-24 00:01:23.000000000 +0100
@@ -200,7 +200,7 @@
         * The futex is hashed differently depending on whether
         * it's in a shared or private mapping.  So check vma first.
         */
-       vma = find_extend_vma(mm, address);
+       vma = find_vma(mm, address);
        if (unlikely(!vma))
                return -EFAULT;

diff -Nru regi2.6.19.2/mm/memory.c linux-2.6.19.2/mm/memory.c
--- regi2.6.19.2/mm/memory.c    2007-01-24 00:00:22.000000000 +0100
+++ linux-2.6.19.2/mm/memory.c  2007-01-24 00:01:23.000000000 +0100
@@ -1012,7 +1012,7 @@
                struct vm_area_struct *vma;
                unsigned int foll_flags;

-               vma = find_extend_vma(mm, start);
+               vma = find_vma(mm, start);
                if (!vma && in_gate_area(tsk, start)) {
                        unsigned long pg = start & PAGE_MASK;
                        struct vm_area_struct *gate_vma = get_gate_vma(tsk);
diff -Nru regi2.6.19.2/mm/mmap.c linux-2.6.19.2/mm/mmap.c
--- regi2.6.19.2/mm/mmap.c      2007-01-24 00:00:22.000000000 +0100
+++ linux-2.6.19.2/mm/mmap.c    2007-01-24 00:01:23.000000000 +0100
@@ -1703,23 +1703,6 @@
 {
        return expand_upwards(vma, address);
 }
-
-struct vm_area_struct *
-find_extend_vma(struct mm_struct *mm, unsigned long addr)
-{
-       struct vm_area_struct *vma, *prev;
-
-       addr &= PAGE_MASK;
-       vma = find_vma_prev(mm, addr, &prev);
-       if (vma && (vma->vm_start <= addr))
-               return vma;
-       if (!prev || expand_stack(prev, addr))
-               return NULL;
-       if (prev->vm_flags & VM_LOCKED) {
-               make_pages_present(addr, prev->vm_end);
-       }
-       return prev;
-}
 #else
 /*
  * vma is the first one with address < vma->vm_start.  Have to extend vma.
@@ -1796,29 +1779,6 @@
        anon_vma_unlock(vma);
        return error;
 }
-
-struct vm_area_struct *
-find_extend_vma(struct mm_struct * mm, unsigned long addr)
-{
-       struct vm_area_struct * vma;
-       unsigned long start;
-
-       addr &= PAGE_MASK;
-       vma = find_vma(mm,addr);
-       if (!vma)
-               return NULL;
-       if (vma->vm_start <= addr)
-               return vma;
-       if (!(vma->vm_flags & VM_GROWSDOWN))
-               return NULL;
-       start = vma->vm_start;
-       if (expand_stack(vma, addr))
-               return NULL;
-       if (vma->vm_flags & VM_LOCKED) {
-               make_pages_present(addr, start);
-       }
-       return vma;
-}
 #endif

 /*
diff -Nru regi2.6.19.2/mm/nommu.c linux-2.6.19.2/mm/nommu.c
--- regi2.6.19.2/mm/nommu.c     2007-01-10 20:10:37.000000000 +0100
+++ linux-2.6.19.2/mm/nommu.c   2007-01-24 00:01:23.000000000 +0100
@@ -350,15 +350,6 @@
 EXPORT_SYMBOL(find_vma);

 /*
- * find a VMA
- * - we don't extend stack VMAs under NOMMU conditions
- */
-struct vm_area_struct *find_extend_vma(struct mm_struct *mm, unsigned long addr)
-{
-       return find_vma(mm, addr);
-}
-
-/*
  * look up the first VMA exactly that exactly matches addr
  * - should be called with mm->mmap_sem at least held readlocked
  */
osconsfortress:/home/oscon# cat /usr/src/oscon/grsecurity/pax_expand_stack.diff
diff -Nru regi2.6.19.2/arch/i386/kernel/efi.c linux-2.6.19.2/arch/i386/kernel/efi.c
--- regi2.6.19.2/arch/i386/kernel/efi.c 2007-01-24 00:00:19.000000000 +0100
+++ linux-2.6.19.2/arch/i386/kernel/efi.c       2007-01-24 00:01:22.000000000 +0100
@@ -72,7 +72,7 @@

        clone_pgd_range(efi_bak_pg_dir_pointer, swapper_pg_dir, KERNEL_PGD_PTRS);
        clone_pgd_range(swapper_pg_dir, swapper_pg_dir + USER_PGD_PTRS,
-                       USER_PGD_PTRS >= KERNEL_PGD_PTRS ? KERNEL_PGD_PTRS : USER_PGD_PTRS);
+                       min_t(unsigned long, KERNEL_PGD_PTRS, USER_PGD_PTRS));

        /*
         * After the lock is released, the original page table is restored.
diff -Nru regi2.6.19.2/arch/i386/kernel/head.S linux-2.6.19.2/arch/i386/kernel/head.S
--- regi2.6.19.2/arch/i386/kernel/head.S        2007-01-24 00:00:19.000000000 +0100
+++ linux-2.6.19.2/arch/i386/kernel/head.S      2007-01-24 00:01:22.000000000 +0100
@@ -261,6 +261,7 @@
        /* Make changes effective */
        wrmsr
        btsl $63,__supported_pte_mask-__PAGE_OFFSET
+       movl $1,nx_enabled-__PAGE_OFFSET

 4:
        movl %edi,%ebx
diff -Nru regi2.6.19.2/arch/i386/kernel/reboot.c linux-2.6.19.2/arch/i386/kernel/reboot.c
--- regi2.6.19.2/arch/i386/kernel/reboot.c      2007-01-24 00:00:19.000000000 +0100
+++ linux-2.6.19.2/arch/i386/kernel/reboot.c    2007-01-24 00:01:22.000000000 +0100
@@ -227,7 +227,7 @@
 #endif

        clone_pgd_range(swapper_pg_dir, swapper_pg_dir + USER_PGD_PTRS,
-                       USER_PGD_PTRS >= KERNEL_PGD_PTRS ? KERNEL_PGD_PTRS : USER_PGD_PTRS);
+                       min_t(unsigned long, KERNEL_PGD_PTRS, USER_PGD_PTRS));

 #ifdef CONFIG_PAX_KERNEXEC
        pax_close_kernel(cr0);
diff -Nru regi2.6.19.2/arch/i386/mm/fault.c linux-2.6.19.2/arch/i386/mm/fault.c
--- regi2.6.19.2/arch/i386/mm/fault.c   2007-01-24 00:00:19.000000000 +0100
+++ linux-2.6.19.2/arch/i386/mm/fault.c 2007-01-24 00:01:22.000000000 +0100
@@ -541,6 +541,12 @@
                if (address + 65536 + 32 * sizeof(unsigned long) < regs->esp)
                        goto bad_area;
        }
+
+#ifdef CONFIG_PAX_SEGMEXEC
+       if ((mm->pax_flags & MF_PAX_SEGMEXEC) && vma->vm_end - SEGMEXEC_TASK_SIZE - 1 < address - SEGMEXEC_TASK_SIZE - 1)
+               goto bad_area;
+#endif
+
        if (expand_stack(vma, address))
                goto bad_area;
 /*
diff -Nru regi2.6.19.2/include/linux/mm.h linux-2.6.19.2/include/linux/mm.h
--- regi2.6.19.2/include/linux/mm.h     2007-01-24 00:00:21.000000000 +0100
+++ linux-2.6.19.2/include/linux/mm.h   2007-01-24 00:01:23.000000000 +0100
@@ -1126,7 +1126,6 @@
 }

 pgprot_t vm_get_page_prot(unsigned long vm_flags);
-struct vm_area_struct *find_extend_vma(struct mm_struct *, unsigned long addr);
 struct page *vmalloc_to_page(void *addr);
 unsigned long vmalloc_to_pfn(void *addr);
 int remap_pfn_range(struct vm_area_struct *, unsigned long addr,
diff -Nru regi2.6.19.2/kernel/futex.c linux-2.6.19.2/kernel/futex.c
--- regi2.6.19.2/kernel/futex.c 2007-01-24 00:00:22.000000000 +0100
+++ linux-2.6.19.2/kernel/futex.c       2007-01-24 00:01:23.000000000 +0100
@@ -200,7 +200,7 @@
         * The futex is hashed differently depending on whether
         * it's in a shared or private mapping.  So check vma first.
         */
-       vma = find_extend_vma(mm, address);
+       vma = find_vma(mm, address);
        if (unlikely(!vma))
                return -EFAULT;

diff -Nru regi2.6.19.2/mm/memory.c linux-2.6.19.2/mm/memory.c
--- regi2.6.19.2/mm/memory.c    2007-01-24 00:00:22.000000000 +0100
+++ linux-2.6.19.2/mm/memory.c  2007-01-24 00:01:23.000000000 +0100
@@ -1012,7 +1012,7 @@
                struct vm_area_struct *vma;
                unsigned int foll_flags;

-               vma = find_extend_vma(mm, start);
+               vma = find_vma(mm, start);
                if (!vma && in_gate_area(tsk, start)) {
                        unsigned long pg = start & PAGE_MASK;
                        struct vm_area_struct *gate_vma = get_gate_vma(tsk);
diff -Nru regi2.6.19.2/mm/mmap.c linux-2.6.19.2/mm/mmap.c
--- regi2.6.19.2/mm/mmap.c      2007-01-24 00:00:22.000000000 +0100
+++ linux-2.6.19.2/mm/mmap.c    2007-01-24 00:01:23.000000000 +0100
@@ -1703,23 +1703,6 @@
 {
        return expand_upwards(vma, address);
 }
-
-struct vm_area_struct *
-find_extend_vma(struct mm_struct *mm, unsigned long addr)
-{
-       struct vm_area_struct *vma, *prev;
-
-       addr &= PAGE_MASK;
-       vma = find_vma_prev(mm, addr, &prev);
-       if (vma && (vma->vm_start <= addr))
-               return vma;
-       if (!prev || expand_stack(prev, addr))
-               return NULL;
-       if (prev->vm_flags & VM_LOCKED) {
-               make_pages_present(addr, prev->vm_end);
-       }
-       return prev;
-}
 #else
 /*
  * vma is the first one with address < vma->vm_start.  Have to extend vma.
@@ -1796,29 +1779,6 @@
        anon_vma_unlock(vma);
        return error;
 }
-
-struct vm_area_struct *
-find_extend_vma(struct mm_struct * mm, unsigned long addr)
-{
-       struct vm_area_struct * vma;
-       unsigned long start;
-
-       addr &= PAGE_MASK;
-       vma = find_vma(mm,addr);
-       if (!vma)
-               return NULL;
-       if (vma->vm_start <= addr)
-               return vma;
-       if (!(vma->vm_flags & VM_GROWSDOWN))
-               return NULL;
-       start = vma->vm_start;
-       if (expand_stack(vma, addr))
-               return NULL;
-       if (vma->vm_flags & VM_LOCKED) {
-               make_pages_present(addr, start);
-       }
-       return vma;
-}
 #endif

 /*
diff -Nru regi2.6.19.2/mm/nommu.c linux-2.6.19.2/mm/nommu.c
--- regi2.6.19.2/mm/nommu.c     2007-01-10 20:10:37.000000000 +0100
+++ linux-2.6.19.2/mm/nommu.c   2007-01-24 00:01:23.000000000 +0100
@@ -350,15 +350,6 @@
 EXPORT_SYMBOL(find_vma);

 /*
- * find a VMA
- * - we don't extend stack VMAs under NOMMU conditions
- */
-struct vm_area_struct *find_extend_vma(struct mm_struct *mm, unsigned long addr)
-{
-       return find_vma(mm, addr);
-}
-
-/*
  * look up the first VMA exactly that exactly matches addr
  * - should be called with mm->mmap_sem at least held readlocked
  */
osconsfortress:/home/oscon# cat /usr/src/oscon/grsecurity/pax_expand_stack.diff
diff -Nru regi2.6.19.2/arch/i386/kernel/efi.c linux-2.6.19.2/arch/i386/kernel/efi.c
--- regi2.6.19.2/arch/i386/kernel/efi.c 2007-01-24 00:00:19.000000000 +0100
+++ linux-2.6.19.2/arch/i386/kernel/efi.c       2007-01-24 00:01:22.000000000 +0100
@@ -72,7 +72,7 @@

        clone_pgd_range(efi_bak_pg_dir_pointer, swapper_pg_dir, KERNEL_PGD_PTRS);
        clone_pgd_range(swapper_pg_dir, swapper_pg_dir + USER_PGD_PTRS,
-                       USER_PGD_PTRS >= KERNEL_PGD_PTRS ? KERNEL_PGD_PTRS : USER_PGD_PTRS);
+                       min_t(unsigned long, KERNEL_PGD_PTRS, USER_PGD_PTRS));

        /*
         * After the lock is released, the original page table is restored.
diff -Nru regi2.6.19.2/arch/i386/kernel/head.S linux-2.6.19.2/arch/i386/kernel/head.S
--- regi2.6.19.2/arch/i386/kernel/head.S        2007-01-24 00:00:19.000000000 +0100
+++ linux-2.6.19.2/arch/i386/kernel/head.S      2007-01-24 00:01:22.000000000 +0100
@@ -261,6 +261,7 @@
        /* Make changes effective */
        wrmsr
        btsl $63,__supported_pte_mask-__PAGE_OFFSET
+       movl $1,nx_enabled-__PAGE_OFFSET

 4:
        movl %edi,%ebx
diff -Nru regi2.6.19.2/arch/i386/kernel/reboot.c linux-2.6.19.2/arch/i386/kernel/reboot.c
--- regi2.6.19.2/arch/i386/kernel/reboot.c      2007-01-24 00:00:19.000000000 +0100
+++ linux-2.6.19.2/arch/i386/kernel/reboot.c    2007-01-24 00:01:22.000000000 +0100
@@ -227,7 +227,7 @@
 #endif

        clone_pgd_range(swapper_pg_dir, swapper_pg_dir + USER_PGD_PTRS,
-                       USER_PGD_PTRS >= KERNEL_PGD_PTRS ? KERNEL_PGD_PTRS : USER_PGD_PTRS);
+                       min_t(unsigned long, KERNEL_PGD_PTRS, USER_PGD_PTRS));

 #ifdef CONFIG_PAX_KERNEXEC
        pax_close_kernel(cr0);
diff -Nru regi2.6.19.2/arch/i386/mm/fault.c linux-2.6.19.2/arch/i386/mm/fault.c
--- regi2.6.19.2/arch/i386/mm/fault.c   2007-01-24 00:00:19.000000000 +0100
+++ linux-2.6.19.2/arch/i386/mm/fault.c 2007-01-24 00:01:22.000000000 +0100
@@ -541,6 +541,12 @@
                if (address + 65536 + 32 * sizeof(unsigned long) < regs->esp)
                        goto bad_area;
        }
+
+#ifdef CONFIG_PAX_SEGMEXEC
+       if ((mm->pax_flags & MF_PAX_SEGMEXEC) && vma->vm_end - SEGMEXEC_TASK_SIZE - 1 < address - SEGMEXEC_TASK_SIZE - 1)
+               goto bad_area;
+#endif
+
        if (expand_stack(vma, address))
                goto bad_area;
 /*
diff -Nru regi2.6.19.2/include/linux/mm.h linux-2.6.19.2/include/linux/mm.h
--- regi2.6.19.2/include/linux/mm.h     2007-01-24 00:00:21.000000000 +0100
+++ linux-2.6.19.2/include/linux/mm.h   2007-01-24 00:01:23.000000000 +0100
@@ -1126,7 +1126,6 @@
 }

 pgprot_t vm_get_page_prot(unsigned long vm_flags);
-struct vm_area_struct *find_extend_vma(struct mm_struct *, unsigned long addr);
 struct page *vmalloc_to_page(void *addr);
 unsigned long vmalloc_to_pfn(void *addr);
 int remap_pfn_range(struct vm_area_struct *, unsigned long addr,
diff -Nru regi2.6.19.2/kernel/futex.c linux-2.6.19.2/kernel/futex.c
--- regi2.6.19.2/kernel/futex.c 2007-01-24 00:00:22.000000000 +0100
+++ linux-2.6.19.2/kernel/futex.c       2007-01-24 00:01:23.000000000 +0100
@@ -200,7 +200,7 @@
         * The futex is hashed differently depending on whether
         * it's in a shared or private mapping.  So check vma first.
         */
-       vma = find_extend_vma(mm, address);
+       vma = find_vma(mm, address);
        if (unlikely(!vma))
                return -EFAULT;

diff -Nru regi2.6.19.2/mm/memory.c linux-2.6.19.2/mm/memory.c
--- regi2.6.19.2/mm/memory.c    2007-01-24 00:00:22.000000000 +0100
+++ linux-2.6.19.2/mm/memory.c  2007-01-24 00:01:23.000000000 +0100
@@ -1012,7 +1012,7 @@
                struct vm_area_struct *vma;
                unsigned int foll_flags;

-               vma = find_extend_vma(mm, start);
+               vma = find_vma(mm, start);
                if (!vma && in_gate_area(tsk, start)) {
                        unsigned long pg = start & PAGE_MASK;
                        struct vm_area_struct *gate_vma = get_gate_vma(tsk);
diff -Nru regi2.6.19.2/mm/mmap.c linux-2.6.19.2/mm/mmap.c
--- regi2.6.19.2/mm/mmap.c      2007-01-24 00:00:22.000000000 +0100
+++ linux-2.6.19.2/mm/mmap.c    2007-01-24 00:01:23.000000000 +0100
@@ -1703,23 +1703,6 @@
 {
        return expand_upwards(vma, address);
 }
-
-struct vm_area_struct *
-find_extend_vma(struct mm_struct *mm, unsigned long addr)
-{
-       struct vm_area_struct *vma, *prev;
-
-       addr &= PAGE_MASK;
-       vma = find_vma_prev(mm, addr, &prev);
-       if (vma && (vma->vm_start <= addr))
-               return vma;
-       if (!prev || expand_stack(prev, addr))
-               return NULL;
-       if (prev->vm_flags & VM_LOCKED) {
-               make_pages_present(addr, prev->vm_end);
-       }
-       return prev;
-}
 #else
 /*
  * vma is the first one with address < vma->vm_start.  Have to extend vma.
@@ -1796,29 +1779,6 @@
        anon_vma_unlock(vma);
        return error;
 }
-
-struct vm_area_struct *
-find_extend_vma(struct mm_struct * mm, unsigned long addr)
-{
-       struct vm_area_struct * vma;
-       unsigned long start;
-
-       addr &= PAGE_MASK;
-       vma = find_vma(mm,addr);
-       if (!vma)
-               return NULL;
-       if (vma->vm_start <= addr)
-               return vma;
-       if (!(vma->vm_flags & VM_GROWSDOWN))
-               return NULL;
-       start = vma->vm_start;
-       if (expand_stack(vma, addr))
-               return NULL;
-       if (vma->vm_flags & VM_LOCKED) {
-               make_pages_present(addr, start);
-       }
-       return vma;
-}
 #endif

 /*
diff -Nru regi2.6.19.2/mm/nommu.c linux-2.6.19.2/mm/nommu.c
--- regi2.6.19.2/mm/nommu.c     2007-01-10 20:10:37.000000000 +0100
+++ linux-2.6.19.2/mm/nommu.c   2007-01-24 00:01:23.000000000 +0100
@@ -350,15 +350,6 @@
 EXPORT_SYMBOL(find_vma);

 /*
- * find a VMA
- * - we don't extend stack VMAs under NOMMU conditions
- */
-struct vm_area_struct *find_extend_vma(struct mm_struct *mm, unsigned long addr)
-{
-       return find_vma(mm, addr);
-}
-
-/*
  * look up the first VMA exactly that exactly matches addr
  * - should be called with mm->mmap_sem at least held readlocked
  */

-----------

Nem a zsömle kicsi, a pofátok nagy...

> Ha esetleg tudsz újabb ilyenről, és megosztanád részleteiben, sz'tem sokan
> megköszönnénk. / főleg akik nem a vanilla-t használjuk, mondjuk mert kb. nincs
> időnk a heti változásait követni :-) /

pl. ez speciel olyan csendesre sikerult, hogy egyreszt nulla komment van hozza, masreszt a subject feligazsagot allit csak (a ki nem mondott fele az erdekes, refcount overflow-rol van szo, ha valaki bele akarja asni magat), harmadreszt pedig meg a 2.6.19.2-t is sikerult elkerulnie.

> ehhez kapcsolódik a másik kérdésem, a "csak a kérdéses hibát" javító patch kb.
> ez ?, / ami mondjuk kis csúszással nem csak vanilla 2.6.19.2re is alkalmazható /

az arch/i386/kernel/efi.c, arch/i386/kernel/head.S es az arch/i386/kernel/reboot.c chunkok nem tartoznak bele.

> pl. ez speciel olyan csendesre sikerult

Az még hagyján, de pl. 2.6.18-ban bent sincs ilyen formában a "hibás" kód. 2.6.19.2-ben a "hibás van" tényleg, de a "régiben" meg más módon oldották meg. (?). legalábbis debian etch féle 2.6.18-7-esben nincsen. (pipe.c dec. 11.)...

érdekes.

> az arch/i386/kernel/efi.c, arch/i386/kernel/head.S es az
> arch/i386/kernel/reboot.c chunkok nem tartoznak bele.

thx.

Valami más fontos javítás apróbb részei, vagy ez a "hármas" egy kisebb "minor PaX update" ?

---------

Nem a zsömle kicsi, a pofátok nagy...

> Az még hagyján, de pl. 2.6.18-ban bent sincs ilyen formában a "hibás" kód.

azert nincs, mert a kerdeses bug a 2.6.19-ben kerult be, ki tudod keresni a git history-bol.

> Valami más fontos javítás apróbb részei, vagy ez a "hármas" egy kisebb "minor PaX update" ?

a clone_pgd_range() chunkok egy altalam irt regebbi bugfix reszei, amit azota kicsit maskepp megoldottak a vanilla linux-ban is, es erre adaptaltam az enyemet (hogy kisebb legyen a patch merete, ha mar egyszer ugyanazt csinalja a ketfele kod). a head.S chunk meg arra jo, hogy ha valaki bepatch-eli a PaX-ot, de nem engedelyezi a NOEXEC cuccokat, akkor a kernel megis probalja meg hasznalni a hw NX bitet (mar ha van, persze).

1. Az első (pre-)advisory-ban nem volt semmi konkrét, csak annyi, hogy expand_stack() függvényben van a hiba, amelyről meg kiderült, hogy nem is abban van a hiba, hanem az őt meghívó függvényekben.

2. Mivel nem volt a pre-advisory-ban semmi konkrétabb info, ezért joggal gondolhatta mindenki, hogy csak FUD az egész, főleg mivel a digitalarmaments.com domain egy nem létező címre van bejegyezve, így nem tekinthető komoly cégnek. Ráadásul info hiányában nem lehetett elkezdeni a hibakeresést sem.

3. Ha spender nem mondja azt, hogy csak FUD az Advisory, akkor a DA nem adja ki a PoC-t, ergo a hiba még mindig nem lenne kijavítva. Az szerinted jobb lenne?

Annyit akartam mondani reggel, hogy lehetett volna diplomatikusabban is fogalmazni.

"1. Az első (pre-)advisory-ban nem volt semmi konkrét, csak annyi, hogy expand_stack() függvényben van a hiba, amelyről meg kiderült, hogy nem is abban van a hiba, hanem az őt meghívó függvényekben."

Nyilván, hiszen pénz reményében vissza akarták tartani. Bevett szokás.

"2. Mivel nem volt a pre-advisory-ban semmi konkrétabb info, ezért joggal gondolhatta mindenki, hogy csak FUD az egész, főleg mivel a digitalarmaments.com domain egy nem létező címre van bejegyezve, így nem tekinthető komoly cégnek. Ráadásul info hiányában nem lehetett elkezdeni a hibakeresést sem."

Feltételezés.

"3. Ha spender nem mondja azt, hogy csak FUD az Advisory, akkor a DA nem adja ki a PoC-t, ergo a hiba még mindig nem lenne kijavítva. Az szerinted jobb lenne?"

Ezek szerint kiadtak egy PoC-ot, ami segített egy probléma megoldásában?

--
trey @ gépház

Feltételezés.

Nem feltételezés. Nincs ilyen cím:

Administrative Contact:
Savely, Roan digitalarmaments@yahoo.com
52th - 1065
New York, New York 10001
US
001555636525

Ezek szerint kiadtak egy PoC-ot, ami segített egy probléma megoldásában?

"Ha spender nem mondja azt, hogy csak FUD az Advisory, akkor a DA nem adja ki a PoC-t, ergo a hiba még mindig nem lenne kijavítva. Az szerinted jobb lenne?"

A feltételezést arra értettem, hogy abból a tényből, hogy nem egy nem létező cég állít valamit, azt a következtetést kár lenne előre levonni, hogy amit állít, az nem igaz. Pl. ha valaki bejelent egy hibát Hakapeszi Maki néven, az nem feltétlenül jelenti azt, hogy a hiba nem létezik. Nem biztos, hogy mindenki akarja felfedni a kilétét (ez mindkét oldalra igaz lehet).

"Ezek szerint kiadtak egy PoC-ot, ami segített egy probléma megoldásában?

"Ha spender nem mondja azt, hogy csak FUD az Advisory, akkor a DA nem adja ki a PoC-t, ergo a hiba még mindig nem lenne kijavítva. Az szerinted jobb lenne?""

Az én szempontomból teljesen közömbös, mert sose használtam a grsec-et. A grsec felhasználók szempontjából hasznos lehet, de nem biztos, hogy ez lett volna az elintézési módja.

--
trey @ gépház

ha valaki bejelent egy hibát Hakapeszi Maki néven, az nem feltétlenül jelenti azt, hogy a hiba nem létezik.

Ez igaz lenne abban az esetben, ha ez a Hakapeszi Maki először tenne ilyet. Azonban mivel a DA már előtte is több alkalommal olyan kijelentéseket tett (remote Linux kernel root és hasonlók), amely nehezen elképzelhető és sosem bizonyította még ellenkezőjét, ezért érthető, hogy nem csak a grsecurity, hanem mindenki más is kétkedve fogadta a dolgot.

Ráadásul elég jól vissza lehet fogni egy projekt fejlődését/fejlesztését azzal, hogy kevés információval rendelkező bug reportokkal bombázod. Aki ilyen területen dolgozik az alá tudja támasztani ezt. Nincs annál rosszabb, mint amikor jön egy olyan bug report (vagy advisory, bár én DA első bejelentését nem is nevezném annak), amelyik nem tartalmaz semmi használható információt a hibával kapcsolatban. Ráadásul ilyen körökben akár ezt direkt is megtehetnék, hogy hamis advisorykat küldenek be szivatásból, mert nyilván sok haxornak szúrja a szemét, hogy van egy ilyen szintű HIPS megoldás Linux-ra, amelyik rengeteg támadási formát ellehetetlenít...

A DA esetében a helyzetet bonyolítja, hogy adtak már korábban valós bejelentést is, ahol még kb. a fél évet is tartották. (az apache_ldap modulban). Tehát kb. dobj fel egy pénzt, hogy ez most igaz vagy hamis... ;-)

http://www.digitalarmaments.com/2006090173928420.html

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0150

--------

Nem a zsömle kicsi, a pofátok nagy...

Igaz, bár a

"For example this can generate a custom format string that can be supplied by the attacker through the username given during the apache authentication process but several parts of the module are affected."

kicsit egyszerűbben ellenőrízhető, mint

"A vulnerability exist in expand_stack() of grsecurity patch. This vulnerability is exploitable only locally."

Ha a DA már elsőre olyan advisoryt adott volna ki, mint amelyet most másodjára, akkor nem lett volna FUD-nak kikiáltva.

OFF: Először is kösz, hogy javítottad az eredeti "beküldés"-t...sajnos az angoltudásom az istennek nem akar javulni, pedig folyamatosan pecselem. de valami design error lehet. :)

ON: Az egész tudtommal úgy indult, hogy egy nemlétező címmel rendelkező cég kikáltott egy lokális priv. emelési bugot a grsecben hogy majd fél év mulva közli a részleteket, addig az exploit a 80000 dolcsis "csomagban" elérhető.

Ez fedte az igazságot? nem. akkor most FUD, avgy nem FUD ? döntsd el...

Namost egy olyan cégtől elnézést kérni, amelyik látszólag se nem létezik, se nem közli a hibaleírást, csak miután "felpiszkálják", és akkor sem arról a hibáról, amit eredetileg bejelentett (expand_stack nem egyenlő find_extend_vma() ?, és még a "hatás" sem az amit bejelentett (local root nem egyenlő local DoS), hát nem azért, de talán mégse kéne...és azt nem elfelejtve hoyg elkért ezért 80000 dolcsit... ;-)

/ gondold bele magad fordított helyzetbe. ha mondjuk - vicc kedvéért :-) - a HuP kódjában hibát találnék, amivel bárki nevében tudnék írkálni a fórumon, mert hibás a bejelentkezéskezelő modul. aztán közlöm hogy mégse tudok írkálni a fórumon mások nevében, csak mondjuk a háttérképet tudom megváltoztatni, és a hiba nem is a bejelentkezőmodulban van. te elnézést kérnél ? ;-)) most tényleg csak a "morális" kérdés miatt mondtam ilyen extrém valótlan esetet. /

Az egyedüli hátránya az eseményeknek talán az, hogy 1-1,5 (?) napig 0day local DoS kód került ki. De ezt végülis nem lehetett védeni jelen esetben. mert ha nem kiált a grsec FUDot, akkor valszeg fél év mulva jön ki a DA-től az újabb info.

OFF: Hol vannak már a régi szép idők, mikor a hiba felfedezője először a "gyártónak" küldte az infot, és javítás kikerülés után jött az advisory...régi szép idők... nem pedig 80.000 dolcsit követelt nemlétező címen levő cégnevében ?

-----------

Nem a zsömle kicsi, a pofátok nagy...

"/ gondold bele magad fordított helyzetbe. ha mondjuk - vicc kedvéért :-) - a HuP kódjában hibát találnék, amivel bárki nevében tudnék írkálni a fórumon, mert hibás a bejelentkezéskezelő modul. aztán közlöm hogy mégse tudok írkálni a fórumon mások nevében, csak mondjuk a háttérképet tudom megváltoztatni, és a hiba nem is a bejelentkezőmodulban van. te elnézést kérnél ? ;-)) most tényleg csak a "morális" kérdés miatt mondtam ilyen extrém valótlan esetet. /"

Marha rossz a példa, mert én nem írom a HUP kódját, csak használom, így nem analóg a dolog. De értem, hogy mire akarsz kilyukadni. Megmondom neked a frankót, le se szarnám, hogy mit állítasz :)

"Namost egy olyan cégtől elnézést kérni, amelyik látszólag se nem létezik, se nem közli a hibaleírást, csak miután "felpiszkálják", és akkor sem arról a hibáról, amit eredetileg bejelentett (expand_stack nem egyenlő find_extend_vma() ?, és még a "hatás" sem az amit bejelentett (local root nem egyenlő local DoS), hát nem azért, de talán mégse kéne..."

Értem én, hogy most központi ellenség, mert a haversrác kódjában talált csontot, meg hogy a rossz hír hozóját le kell lőni... Ez így szokott lenni. Én annyit látok, hogy állítottak valamit, aminek a nyomán született egy patch. Ha ez előbbre viszi a grsec-et, akkor azt már pozitív dologként kell a DA számlájára írni. Legyen az fantomcég, vagy Hakapeszi Maki.

--
trey @ gépház

Bocs, de nem volt időm nagyon napközben...

"és még a "hatás" sem az amit bejelentett (local root nem egyenlő local DoS), hát nem azért, de talán mégse kéne..."

Olvasd el azért ez újra :) Óvatosan van ez már megfogalmazva ;-)

"We are erring on the side of caution and calling this bug exploitable, though we believe reliable exploitation of the bug (in the privilege escalation sense, not the DoS sense) to be very difficult, especially in the presence of KERNEXEC/UDEREF."

--
trey @ gépház

Ha jól értem, az vagyon ideírva, hogy "nagyon nehéz" privilégiumemeléshez felhasználni. nem pedig az hogy lehetetlen. / de az angoltudásom köztudottan pocsék :) úgyhogy nem biztos /

De van egy kis "magyar" segítség :

PaXTeam: 

ha letezik tetszoleges kernel memoriat olvaso bug valahol, akkor annak segitsegevel nagyon pontosan lehet elvegezni ezt a nullazast es akkor tenyleg ki lehet hasznalni tetszoleges privilegium emelesre.

Tehát a magasabb jogosultsági szint eléréséhez önmagában még kevés ez a bug. A bug önmagában local DoS-t okoz, nem pedig "local root"-t, amit a DA állít(ott?).

Persze a DA előállhat újabb infoval, de ezt majd az idő fogja eldönteni. ;-)

--------------

Nem a zsömle kicsi, a pofátok nagy...

ide irom a tobbi hozzaszolasodhoz is a valaszt, nincs kedvem szazfele szakitani a szalat (nahat, ez rimelt, figyeled? ;). nezzuk akkor:

1. szemelyeskedes. kulonos, hogy ezt felhoztad, mert mindjart az elejen te kezdtel el arcmeretekrol meg pofaraesesrol ertekezni, hogy a magaban vakon bizo programozorol mar ne is beszeljek (de azert fogok, lasd alabb ;). ezt hivjak kettos mercenek?

2. tanulj meg olvasni. vagy ha mar tudsz, es hozzaszolsz valaki mas iromanyahoz, legalabb annyi faradtsagot vegyel, hogy vegigolvasod, mielott valamit valaszolsz. konkretabban:

> Így van, így továbbra is azt tanácsolom minden magában vakon bízó
> programozónak, hogy ha valaki bugot jelent neki, aki ne FUD-ot
> kiáltson, hanem álljon neki, aztán nézzen körül a kódjában

te hol lattal bugjelentest? orulnek, ha ideirnad az url-t. en speciel egy arva levelet nem kaptam a DA-tol, amit meg az elso advisory-ban leirtak, nem bugreport, ahogy valaki mar emlitette (de ha te abbol ki tudtad olvasni a bugot, akkor ne habozz megosztani velunk a tudasod, mi is szeretnenk okulni).

aztan, tanuld meg a FUD jelenteset, ha mar hasznalod. ha nem erted, miert mondom, akkor itt van: Fear, Uncertainity, Doubt (felelem, bizonytalansag, ketseg). ezek kozul egyik szo sem jelent 'hazugsag'-ot, amivel te szemmel lathatolag osszekeverted. spender pontosan azt allitotta, amit az elso advisory kivaltott az emberekbol: semmi hasznalhato info (meg az allitolagos hibas fuggveny sem bizonyult annak, bar te a fentiek szerint jobban tudod, kivancsian varom a reszleteket), viszont annal tobb bizonytalansagot kelto allitas. ez a FUD jelentese, nem az, hogy hazudtak (ha nem tunt volna fel, meg senki nem inditott pl. a Microsoft ellen hitelrontasert pert, pedig nyilvanos hazugsagert (de nem FUD-ert) az jar).

aztan, koszonom a jotanacsot (miszerint nezzek korul a kodomban), es lehet, hogy nem fogod elhinni, de azonnal megtettem. hihetetlen, hogy az ilyen magukban vakon bizo programozok mi mindenre nem vetemednek, mi?

> Kíváncsi lennék, hogy ha nem lett volna a DA bejelentése, akkor
> megszületett volna-e ez a javítás.

ez azon mulik, hogy valaki megtalalja-e a bugot vagy sem, nehez volt kitalalni, mi?

> Ha meg nincs hiba, akkor mire fel a javítás?

ki mondta, hogy nincs hiba (url kene)? ja, meg sikerult elolvasnod, amikor azt irtam, hogy "a bug, amit igazabol talaltak, az persze letezik..."? erted a 'letezik' szo jelenteset?

> Továbbá a DoS nem hiba?

ki mondta, hogy a DoS nem hiba (url kene)?

> Szóval nekem itt kis ellentmondások vannak, és ez az egész kicsit
> utólagos magyarázkodásnak tűnik.

mi itt az ellentmondas? mert ugye ahhoz kene legalabb 2, egymasnak ellentmondo allitas. mik lennenek ezek? a magyarazkodasra majd visszaterunk, amikor vegignezzuk a te itt mutatott produkciodat, ill. hogy hogyan probalod majd magad megint kivagni (szerintem legjobb lesz a tavalyi strategiat kovetned, es inkabb nem egetni magad tovabb).

3. random zoldsegek

> Ez egy ördögi kör, nekem nem tetszik a grsec kommunikációja, nekik meg
> az én véleményem. Kérdés melyik volt előbb (elnézést, hogy más
> véleményem van, és nem állok be fluffernek).

te abban a tevhitben elsz, hogy valakit is erdekel a velemenyed. ki kell abranditsalak. ami viszont erdekel az az, hogy ne terjessz hulyeseget velemeny moge rejtve.

> "a PoC 'exploit' volt az, ami megmutatta, hogy hol is volt az igazi problema"

> Az honnan származott?

a masodik advisory-bol. es? ja igen, kifelejtetted a mondat elejet (mert te ugye veletlenul sem probalsz meg ferditeni), ami teljes egeszeben ugye igy nezett ki:

> es trey allitasaval ellentetben az eredeti advisory nem segitett
> semmit, a PoC 'exploit' volt az, ami megmutatta, hogy hol is volt az
> igazi problema...

szoval az elso advisory nem segitett, a masodikbol pedig a PoC, nem a szoveg (ami kb. ugyanaz, mint az elso, de mintha ezt is leirtam volna). vagy most azon akarsz lovagolni, hogy a PoC a masodik advisory resze volt es akkor mar a teljes advisory hirtelen segitsegge valik?

> Ha egy köszönöm nem is, de egy "elnézést" elfért volna.

miert is? mert (ne adj isten, elore) ertesitettek minket, hogy az advisory-val egy idoben tudjunk javitast kozzetenni? vagy mert csak 80k USD-t kellett volna erte kiperkalni? vagy mert az advisory-k tele voltak hibas allitasokkal, amikkel FUD-ot okoztak? tudod mi pl. a Microsoft policy-ja?

Szánalmas, amikor egy programozó besértődik azon, hogy a nagyszerű kódjában hibát találnak, és azt még netán szóvá is teszik. Naponta látok ilyet. Sebaj. További erőt, egészséget a PaX fejlesztéséhez és használatához (ofkoz 2.4-gyel, mert az biztonságos) <- this is not a FUD!

--
trey @ gépház

Nem értem, hogy jön ez ide, de kár előkeresni, mert az álláspontom nem változott a felesleges optimalizálgatásokkal kapcsolaban. Egyébként úgy emlékszem, hogy Gentoo kapcsán került elő, de végülis ez nem változtat a lényegen.

--
trey @ gépház

segítek:

"Szánalmas, amikor egy programozó besértődik azon, hogy a nagyszerű kódjában hibát találnak"
vs.
"Ideggorcsot kapok, ha valaki az ilyet keri szamon a fejlesztoktol, mikor lassan a legkisebb kaphato memoriamodul 512 MB."

Érdekes, pedig a Gnome esetében kapásból volt még tisztességesnek mondható bugreport is. Nekem ebből az jön le hogy a grsec-et szánalmas programozók csinálják a Gnome-ot meg fejlesztők. Ühüm.

Nagyon jó ez így kiragadva a szövegkörnyezetéből. Idézzük ide inkább az egészet:

Szerintem meg itt lenne az ideje elfelejteni a 128 MB memoriaval felszerelt gepeket. Ideggorcsot kapok, ha valaki az ilyet keri szamon a fejlesztoktol, mikor lassan a legkisebb kaphato memoriamodul 512 MB.
Annak idejen amikor a 128 MB volt a standard a gepekeben (4-5 eve?) akkor a GNOME jol futott rajta. Manapsag a vekonykliensekbe tesznek ennyi RAM-ot.

Ez kb. olyan, mintha valaki azt kerne a webfejlesztoktol 2005-ben, hogy 14" monitorra optimakoljak az oldalaikat. Kozben mar 15"-os monitort se kapni.

Erdekes, hogy senki nem hasznal Ericsson 198-as telefont manapsag. Termeszetes, hogy evente-ketevente lecsereljuk a telefonunkat (van aki havonta). Akkor miert termeszetes, hogy szutykokon kell dolgozni? A szamitastechnika nem a szegenyek sportja. Aki nekiall es ezzel dolgozik, vagy ezzel szorakoztatja magat, az koltson ra.

Nem ertem miert termeszetes sokaknak hogy junk-okon akarnak GNOME-ot futtatni. Akinek 128 MB RAM-ja van, az ne akarjon GNOME-ot. Annak van mas opcioja. En se akarnak 140-nel repeszteni, ha csak Trabantom lenne. Plane azt utalom, amikor egy ceg ilyenen sporol. Van egy gepparkja Win95-tel, es azon morfondirozik, hogyan lehetne ra Windows XP-t tenni. ROTFL.

Emellett persze jo, ha a fejlesztok figyelnek a memoria hasznalasra, es igyekeznek azt csokkenteni. De azert ne akarjunk mar visszafele menni az idoben...

Szerintem ezt nem konkrét bug kapcsán, hanem általánosságban mondtam, és továbbra is fenntartom. A GNOME itt behelyettesíthető gyakorlatilag az összes mai DE-vel, vagy operációs rendszerrel, beleértve a Windows XP-t is. Hogy GNOME szerepel benne, az annak köszönhető, hogy abban a témában merült fel.

"Érdekes, pedig a Gnome esetében kapásból volt még tisztességesnek mondható bugreport is. Nekem ebből az jön le hogy a grsec-et szánalmas programozók csinálják a Gnome-ot meg fejlesztők. Ühüm."

Ez egy téves következtetés, ami a te fejedben állt össze.

--
trey @ gépház

Én viszont továbbra is fenntartom hogyha _van_ bugreport akkor fixálják a hibát a fejlesztők, akár ilyen kisstílűnek tűnő háromszors memóriafoglalás akár komoly security fixről van szó. Ha viszont odaböfögés van csak akkor _ne_ a programozó legyen már a gané alak hogy nem fixálja a hibát seperc alatt hanem esetleg elutasítja a "hibajelentést".

> Szánalmas, amikor egy programozó besértődik azon, hogy a nagyszerű kódjában hibát találnak, és azt még netán szóvá is teszik.

ez az osszes reakciod? hogy sajat magad idezzem: szanalmas. amikor arra tippeltem, hogy tovabbi egetes helyett inkabb abbahagyod, gondoltam, hogy nem uszom meg me'g egy kis rugdalozas nelkul:

azt mibol szurted le, hogy en barmin is megsertodtem? te most komolyan azt gondolod, hogy a DA azok utan, hogy talalt egy bugot, megtartotta maganak, majd megprobalta eladni az 'alvilagban', majd amikor ez nem sikerult, kiadott egy tomeny FUD 'advisory'-t (tovabbi fel evig valo visszatartassal fenyegetve es 80k USD zsarolassal fuszerezve), majd ropke egy het utan (miutan meg mindig nem sikerult palimadarat fogniuk), kiadtak egy PoC-ot (exploitjuk sohasem volt), szoval mindezek utan nekik *koszonet* meg *elnezes* jar? neked a gyulolettol elment az eszed (egyszer majd, felnott modjara, azt is kifejthetned, hogy mibol taplalkozik ez a gyulolet irantunk, remelem nem holmi kicsinyes, 'bantotattok a szegeny kis spanomat, thuglife-ot' dologrol van szo ;). azon is elgondolkozhatsz, hogy a spanjaid kozul egy sem szolt meg hozza a szalhoz veled egyetertve... talan tamaskodas helyett be kene latnod, hogy bizony nagyon rossz lora tettel most.

> Naponta látok ilyet. Sebaj. További erőt, egészséget a PaX fejlesztéséhez és használatához

az ironia annak all jol, akinek van stilusa. neked nincs.

> (ofkoz 2.4-gyel, mert az biztonságos) <- this is not a FUD!

latom, a FUD jelentesevel tovabbra sem vagy tisztaban (segitseg: FUD-ot negativ tartalmu/celzatu allitasokkal lehet csinalni...).

PaxTeam. Rossz lóra tettem. Azt hittem értelmesebb ember vagy, de ezzel, hogy belekeverted thuglife-ot, akinek ehhez semmi köze ehhez (nem is értem hogyan jön ide) bizonyítottad, hogy annyira mégsem. Tőlem lehetsz marha jó programozó - ne vitatom, hogy az vagy (sose vitattam) - de kommunikációban van még mit tanulnod / tanulnotok.

"latom, a FUD jelentesevel tovabbra sem vagy tisztaban (segitseg: FUD-ot negativ tartalmu/celzatu allitasokkal lehet csinalni...)."

Gondoltam, annyira leszel ügyes, hogy csavarsz egyet rajta, és az ellentétében megérzed a FUD szagot. Ebben is tévedtem.

Részemről le van zárva a téma.

--
trey @ gépház

> Azt hittem értelmesebb ember vagy, de ezzel, hogy belekeverted thuglife-ot, akinek ehhez semmi köze ehhez
> (nem is értem hogyan jön ide) bizonyítottad, hogy annyira mégsem.

talan nezd meg, hogy ki beszelt elottem a spanokrol ebben a szalban. gondoltam, ha a te kis vilagod ilyen elven mukodik, akkor biztos velunk is az a bajod, hogy valami spanodat valami rettenetes szornyuseg erte reszunkrol, ezert rakerdeztem (tudod, feltetelezesekbe nem csak te bocsatkozhatsz, ja, meg tanuld meg a smiley jelenteset :). de ha nem, hat nem, ettol meg mindig nem lettem okosabb, hogy mi is a bajod velunk. szoval kibokod vegre a jelen szalban bemutatott amokfutasod igazi okat? vagy legalabb megvalaszolod az en egyaltalan nem koltoi kerdeseimet vegre? tudod, ragalmazni nem szep dolog. vagy ez is a kettos mercedhez tartozik?

>Tőlem lehetsz marha jó programozó - ne vitatom, hogy az vagy (sose vitattam) - de kommunikációban van még mit tanulnod / tanulnotok.

neked mitol van az a fixa idead, hogy en jo programozo vagyok (vagy annak tartom magam)? ezt abbol szurod le, hogy (uram bocsa'), kritizalni merem a szakmam dolgait? tudod, hany jo programozo lenne akkor a vilagon? :)

> Gondoltam, annyira leszel ügyes, hogy csavarsz egyet rajta, és az ellentétében megérzed a FUD szagot. Ebben is tévedtem.

lehet a dolog igazi ironiaja az, hogy te magad eszre se vetted :).

> Részemről le van zárva a téma.

a kisebb rossz, orulok, hogy belattad. legkozelebb ha nincs igazi mondanivalod es csak bele akarsz rugni valakibe, probald meg valami butordarabon levezetni, itt csak porul jarsz.

Igen beláttam. Keresem az alábbi URL-t, de nem találom. Valaminek szerettem volna utánanézni. Talán tudnál segíteni:

http://www.grsecurity.net/news.php#digitalfud

Csak nem le lett törölve? A korábbi állásfoglalással együtt? Mi az oka? :-O

Pontosabban ezt hiányolom:

Official message regarding claimed grsecurity/PaX vulnerabilities
 
While we do not want to bring any more attention to the obviously attention-seeking "company" claiming two vulnerabilities (one local, and one remote) in nonspecific versions of the Linux kernel in combination with nonspecific versions of grsecurity/PaX, I believe it's prudent to reply to the FUD in a direct way so that our users can be better informed.

The company in question is the same company that claimed a Linux 2.6.x remote root which never came to fruition (see http://www.zone-h.org/content/view/14395/31/).

The company clearly is trying to drum up attention for itself and fool some people with deep pockets into throwing away $80,000 to them and hope that in 6 months time people will forget all about it just like the remote Linux 2.6.x vulnerability.

As the PaX team has mentioned on the forums (see http://forums.grsecurity.net/viewtopic.php?t=1643), the function they claim the vulnerability to be in is a trivial function, which can, and has been, easily checked for any supposed vulnerabilities.

The company is very likely not of US origin, given their cheap hosting provider, nonexistent business address, nonexistent LLC in New York, and horrible spelling. They've also attempted to drum up interest in their company by posing as potential customers on mailing lists (see: http://www.securityfocus.com/archive/82/415359).

For these public reasons, it can safely be said that these vulnerability claims are pure attention-seeking FUD for a shady company.

Itt még megvan.

--
trey @ gépház

Először is nem számonkértem, csak érdeklődtem. Másodszor érdekes módja a "frissítésnek" a korábbi FUD szavakat tartalmazó írás módszeres eltávolítása. Harmadszor, az egyszavas offtopik hozzászólásokat törlöm, ahogy az _előre_ be lett jelentve.

Számomra innentől az egész komolytalanná vált.

--
trey @ gépház

Inkább ne folytattad volna! /o\

A "de ezzel, hogy belekeverted thuglife-ot" után ugyanis mint a villám jutott eszembe a Gabu barátosnéjának felemlegetése by trey. Gondoltam abbahagytad, tehát nem hozom fel...dehát mégsem.

Ok..végül is a Te "blogod", úyg szemeteled össze ahogy akarod. :/

> Keresem az alábbi URL-t, de nem találom. Valaminek szerettem volna utánanézni. Talán tudnál segíteni:

most megtalaltad vagy meg mindig keresed? amugy meg itt a segitseg, o irta (nekem nulla hozzaferesem ill. beleszolasom van a grsec weboldalaba, amit en akartam elmondani, az (meg mindig) ott van a grsec forumon).