Несколько новых уязвимостей:- В Linux ядре найдена уязвимость (http://secunia.com/advisories/38354/), позволяющая вызвать крах ядра при попытке (http://marc.info/?l=linux-mm&m=126466407724382&w=4) запуска на 64-разрядной системе 32-разрядного приложения с последующим вызовом из него 64-разрядной программы.
- В драйвере e1000 из состава Linux ядра серии 2.4.x найдена уязвимость (http://secunia.com/advisories/38394/), приводящая к краху ядра при обработке специально оформленного ethernet фрейма;
- В версии Solaris 10 для платформы x86 устранена (http://sunsolve.sun.com/search/document.do?assetkey=1-21-143...) уязвимость, дающая локальному пользователю возможность инициирования краха ядра системы через отправку специально скомпонованного UCODE_GET_VERSION IOCTL;
- В написанном на языке Python wiki-движке MoinMoin (http://moinmo.in) найдена уязвимость (http://moinmo.in/SecurityFixes), которой подвержены все версии начиная с 1.5.0 и заканчивая 1.9.1. Так как обнов...
URL:
Новость: http://www.opennet.me/opennews/art.shtml?num=25258
А их всё больше и больше!
Это только верхушка айсберга...
а что хотели чтобы код был идеально чисты и без дырок?
> а что хотели чтобы код был идеально чисты и без дырок?ага.
хотите дальше.
>>> а что хотели чтобы код был идеально чисты и без дырок?
>>ага.
>хотите дальше.Вообще-то этого реально достижимо, но для большинства критерий качества характеризуется фразой: "программа работает".
> при попытке запуска на 64-разрядной системе
> 32-разрядного приложения с последующим вызовом
> из него 64-разрядной программы.The problem seams to be located in fs/binfmt_elf.c:load_elf_binary().
It calls SET_PERSONALITY() prior checking that the ELF interpreter is
available. This in turn makes the previously 32 bit process a 64 bit
one which would be fine if execve() would succeed. But after the
SET_PERSONALITY() the open_exec() call fails (because it cannot find
the interpreter) and execve() almost instantly returns with an error.
If you now look at /proc/PID/maps you'll see, that it has the
vsyscall page mapped which shouldn't be. But the process is not dead
yet, it's still running. By now generating a segmentation fault and
in turn trying to generate a core dump the kernel just dies. I
haven't yet looked into this code but maybe you guys are much faster
than me and just can fix this problem :)
А Вот сранный Гуглы Хромой именно так и может...
По этому я его и снес нах...й, за одно GooleMap/Picasa и Gmail,
так как он просится в /proc и ему нужен прямой доступ к сетевухе и памяти...GOOGLE - ЗЛО!!!
согласен что гугал не нужен. однако его поделия не виноваты в том что в линакс не все нормально внутрях;)
>А Вот сранный Гуглы Хромой именно так и может...
>По этому я его и снес нах...й, за одно GooleMap/Picasa и Gmail,А как вы снесли Gmail? Просто интересно.
>так как он просится в /proc и ему нужен прямой доступ к сетевухе и памяти...А как, простите, Gmail у вас получил такие высокие привилегии?
>>А Вот сранный Гуглы Хромой именно так и может...
>>По этому я его и снес нах...й, за одно GooleMap/Picasa и Gmail,
>А как вы снесли Gmail? Просто интересно.
>>так как он просится в /proc и ему нужен прямой доступ к сетевухе и памяти...
>А как, простите, Gmail у вас получил такие высокие привилегии?У меня???? У всех!!! И под обычным юзером...
Чё он там делает не знаю, но например в конфигурации с 2-мя и более аплинками,
работать почти не может.ps ax вообще смотрели???
Какие-то шаманские не документированные ключи/proc/self/exe --channel=89.432454 --channel=4345345.3453 как-то так...
А то, что при квоте процессора для юзеров, он пожЫрает всё 100%
А вы говорите вирусов и троянов нет!!! Вот он, большой вирус ...
а может гугля сама Спам рассылает.