ждем ... тьфу ты

ну все венде теперь... м-да.

а под слакой не пойдет!!! Вот!

Очнулся..Еще вчера пофиксили

commit b7d061792b4c09fe7c290ddccae3f998d5b513c0
Author: Chris Wright <chrisw@sous-sol.org>
Date: Mon May 22 11:04:35 2006 -0700

Linux 2.6.16.18

commit 1db6b5a66e93ff125ab871d6b3f7363412cc87e8
Author: Patrick McHardy <kaber@trash.net>
Date: Sat May 20 09:31:26 2006 +0200

[PATCH] NETFILTER: SNMP NAT: fix memory corruption (CVE-2006-2444)

CVE-2006-2444 - Potential remote DoS in SNMP NAT helper.

Fix memory corruption caused by snmp_trap_decode:

- When snmp_trap_decode fails before the id and address are allocated,
the pointers contain random memory, but are freed by the caller
(snmp_parse_mangle).

- When snmp_trap_decode fails after allocating just the ID, it tries
to free both address and ID, but the address pointer still contains
random memory. The caller frees both ID and random memory again.

- When snmp_trap_decode fails after allocating both, it frees both,
and the callers frees both again.

The corruption can be triggered remotely when the ip_nat_snmp_basic
module is loaded and traffic on port 161 or 162 is NATed.

Found by multiple testcases of the trap-app and trap-enc groups of the
PROTOS c06-snmpv1 testsuite.

Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

"Удаленный пользователь может с помощью специально сформированного пакета аварийно завершить работу системы."

Пинг смерти, как когда-то в винде.

[:]||||||||||||||[:]

http://www.linux.org.ru/profile/xnix/view-message.jsp?msgid=1407489

Ну и как обычно: "Как же меня задолбал этот дырявый лялих!"

> 3. Уязвимость состояния операции обнаружена в функции "do_add_counters()" в netfilter. Локальный пользователь может получить доступ к памяти ядра или аварийно завершить работу системы. Для удачной эксплуатации уязвимости злоумышленник должен иметь привилегии CAP_NET_ADMIN.

Фигня, не очень страшно.

Ерунда, ничего серьёзного. Обидно только, когда красноглазые линупсоиды усираются, если в *BSD находят уязвимость (чаще всего даже не в ядре).

задалбал этот кривой лялих уже, хуже мастдая млин. что не месяц -- kernel critical vulnerability.

уйду в BSD

а я монастырь!

Уходи, там еще больше дыр.

да не беситеся вы. настройте крон чтоб каждый час обнавлял ядро и будет вам щастьэ. :)))

SCTP уже ктото использует?

> задалбал этот кривой лялих уже, хуже мастдая млин. что не месяц --

> kernel critical vulnerability.

> уйду в BSD

Нет никакого смысла. В BSD находят по 6 (ШЕСТЬ) удаленный уязвимостей за неполные два месяца.

Уже третью новость об уязвимости на лоре вижу с SCTP. Это там постоянно находят такое или просто одни и те же новости постят?

находят постоянно - пофиксить не могут

>да не беситеся вы. настройте крон чтоб каждый час обнавлял ядро и будет вам щастьэ. :)))
>Krechet (*) (23.05.2006 18:08:53)

В фортунки!!! :-)

>> Очнулся..Еще вчера пофиксили

Вы так говорите, как будь-то "вчера" было до изобретения компьютеров.

>> уйду в BSD >Нет никакого смысла. В BSD находят по 6 (ШЕСТЬ) удаленный уязвимостей за неполные два месяца. >dmesg (*) (23.05.2006 18:16:18) Ха - в то время как только в линуксовом ядре находят 6 (ШЕСТЬ) удаленных уязвимостей за неполные две недели?!?!? Винда давно отдыхает по сравнению с этим решетом!

И разумеется аналогия (та как всегда) проводится без учета того, что нужно еще и "специальный" пакетик сформировать, в отличие от простого задания "длины" для пинга? ;)

Вот стоит роутер со статическим хвостом в нет и стоит себе... в логах море строк с "пакет послан на йух" согласно правилам, и поди-ж ты, от самого 2.4.27 - ни одного инцидента с падением от кривого пакета... вспоминаем винды с пингом?... не говоря уже о бластерах... ;)

Саныч жжОт :)

Гы-гы-гы ! Ну и где же эти аплогеты лялиха , которые изрыгают хулу в адрес BSD систем ? Где же их разговоры о техническом превосходстве линакс ? Где высказывания о superior development model ? Если бы в линакс к исходному коду ядра имело доcтуп такое же кол-во разработчиков как в bsd системах, то боюсь коллапс уже наступил-бы потому как, этот проект держится только на разработке по методу тома сойера (вы пишите код а мы его скомитим, если захотим конечно) ни о каком аудите исходного кода на предмет безопасности речи идти не может.

> SCTP уже ктото использует?

Похоже, начали :)

это как с ошибками в "исчо"
"и" в одном стаб. патче исправляем, потом замечаем что "о" как то не к месту, потом и "сч" очередь доходит

Интересно, а зачем на секлабе дали ссылку на ChangeLog-2.6.16.17?

> "Удаленный пользователь может с помощью специально сформированного пакета аварийно завершить работу системы."

> Пинг смерти, как когда-то в винде.

время ожидания исправления известной ошибки в Линуксе ~2 дня, в винде ~2 года?

это ты так себя утешаешь? Дыры они и в африке дыры.

ужо давно. только не часто. читай, для чего он разрабатывался

>это ты так себя утешаешь? Дыры они и в африке дыры.

онанимус он и в африке онанимус. Конечно нет разницы между 2 дня и 2 года, главное ведь циферька была :) Про разные степени опасности дыр вообще промолчим

ну теперь то лялиху точно конец!

Лялихом больше - лялихом меньше, какая разница ! Весь его успех это всего-лишь понты помноженные на тренд и мегабаксы корпораций а-ля IBM .

*баное в сраку РЕШЕТО мля.

аще блин. вчера собрал 2.6.16.17.

Бздуны - ВНИМАТЕЛЬНО прочитайте url сайта и валите дальше пинга .... Задолбали SCTP - только разворачивается, раньше никому небыло до него дела, закончат с тем что важно (Linux) может быть возьмуться з пердюху ой сори бздюху

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

ПАЛАЖИ НА ФСЕ ХУЙ!

А ведь Касперский предупреждал..

>Нет никакого смысла. В BSD находят по 6 (ШЕСТЬ) удаленный уязвимостей за неполные два месяца.

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

Хотя что с тебя взять, я все уязвимости 2006-го года сам тут приведу:

1. FreeBSD-SA-06:01.texindex
2. FreeBSD-SA-06:02.ee
3. FreeBSD-SA-06:03.cpio
4. FreeBSD-SA-06:04.ipfw
5. FreeBSD-SA-06:05.80211
6. FreeBSD-SA-06:06.kmem
7. FreeBSD-SA-06:07.pf
8. FreeBSD-SA-06:08.sack
9. FreeBSD-SA-06:09.openssh
10.FreeBSD-SA-06:10.nfs
11.FreeBSD-SA-06:11.ipsec
12.FreeBSD-SA-06:12.opie
13.FreeBSD-SA-06:13.sendmail
14.FreeBSD-SA-06:14.fpu

Хотя тебе дурачку конечно же не дано прочитать об этих уязвимостях и ты будешь теперь тут бакланить во всё горло, что их на самом-то деле 14!

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

Да херня госсспЭди!

У ляпикса даже единного места нет с адвайзори :) А если по всем пробежаться - ограничение на длину поста на лоре не даст засунуть все в одну мессагу. А постить 15 подряд - антифлуд робот зарежет :)

Что-то не написано, а какие версии-то подвержены?

Или все 2.6.x? Или только 2.6.16?

>Что-то не написано, а какие версии-то подвержены?
Или все 2.6.x? Или только 2.6.16?

progserega (*) (24.05.2006 3:51:36)

А вам разве на email не приходят уязвимости в ядре? Или действительно всё так запущено, как сказал anonymous (*) (24.05.2006 1:11:55)?

кстате, вы знаете, как меня сильно расстроил FreeBSD-SA-06:13.sendmail - мне пришлось бросить пить и обновлять в срочном порядке кучу серверов, ибо через сраный php скрипт эта (казалось бы локальная уязвимость) лёгким движением руки...

FreeBSD-SA-06:13.sendmail - это к тому, что по умолчанию он забиндин на 127.0.0.1 - а опасности очень много!

Но к чему же тут FreeBSD-SA-06:13.sendmail?

да всё просто - FreeBSD-SA-06:13.sendmail входит в базовую систему, которая FreeBSD зовётся

Так что детки надо различать "FreeBSD" как собственно ядро, и "FreeBSD" как собственно систему.

Да, прошу прощения, везде, где про FreeBSD-SA упоминалость -- это я один и тот же анонимус писал.

Мысль опережала девок, которые пытались сковать мои мысли :)

Не приходят. А как сделать, чтобы приходили?

А фря все дырявей и дырявей....тьфу ты. прибили все ляпиксы - довольные как слоны

по умолчанию? коллега, понимайте, что по-умолчанию то не на продакшне.

>Нет никакого смысла. В BSD находят по 6 (ШЕСТЬ) удаленный уязвимостей за неполные два месяца.

В линух находят эээ.. 30-40 критических дырок за время между выпусками СТАБИЛЬНЫХ версий ядра.. И это только в ядре.. вышло 18 (восемнадцать) обновленый ядрер..А сколько их в остальном софте.. а в BSD всего 14.. за пол года и это во всей системе.. Сравните сами что называется..

> В линух находят эээ.. 30-40 критических дырок за время между выпусками СТАБИЛЬНЫХ версий ядра.. И это только в ядре.. вышло 18 (восемнадцать) обновленый ядрер..

Правда следует различать ядро, которое находится в активной разработке, и то, которое входит в дистрибутив. В последней версии ядра должно быть относительно много ошибок, которые постепенно выявляются. Но в дистрибутив ядро попадёт когда многие ошибки уже будут обнаружены и исправлены (например в Debian 3.1 используется версия 2.6.8, а на kernel.org в качестве текущей сейчас лежит уже 2.6.16.18). То есть многие ошибки в ядре не имеют практического значения - реальные рабочие системы построены на отлаженных старых версиях.

> А сколько их в остальном софте.. а в BSD всего 14.. за пол года и это во всей системе.. Сравните сами что называется..

В остальном софте? :-) Ты или занимаешься демагогией, или просто не представляешь себе предмет обсуждения. Прикладной софт у Linux и FreeBSD общий (разве что часть софта для Linux не пойдёт под FreeBSD). А ты хочешь сравнить количество уязвимостей во FreeBSD без дополнительного софта и в дистрибутиве Linux с кучей дополнительного софта? То есть если, к примеру, в GIMP найдут какую-то уязвимость, то ты её засчитаешь для дистрибутива Linux (если там есть GIMP), но не засчитаешь для дистрибутива FreeBSD (если там его нет), не обращая внимания на то, что пользователи реальных систем под Linux и FreeBSD, работающие с GIMP, окажутся в равном положении, естественно за исключением того, что пользователю Linux проще получать информацию об обновлениях - она собрана на сайте дистрибутива. Естественно GIMP взят чисто для примера.

Ядро линукс и умеет больше и поддерживает больше

> Ядро линукс и умеет больше и поддерживает больше
ему говорят бело, ему кажется черно.
вот список уязвимостей за год в openbsd http://www.openbsd.org/errata37.html
---------
013: SECURITY FIX: May 2, 2006 All architectures
A security vulnerability has been found in the X.Org server -- CVE-2006-1526. Clients authorized to connect to the X server are able to crash it and to execute malicious code within the X server.

012: SECURITY FIX: March 25, 2006 All architectures
A race condition has been reported to exist in the handling by sendmail of asynchronous signals. A remote attacker may be able to execute arbitrary code with the privileges of the user running sendmail, typically root.

011: SECURITY FIX: February 12, 2006 All architectures
Josh Bressers has reported a weakness in OpenSSH caused due to the insecure use of the system(3) function in scp(1) when performing copy operations using filenames that are supplied by the user from the command line. This can be exploited to execute shell commands with privileges of the user running scp(1).

010: RELIABILITY FIX: January 13, 2006 i386 architecture
Constrain i386_set_ioperm(2) so even root is blocked from accessing the ioports unless the machine is running at lower securelevels or with an open X11 aperture.

009: RELIABILITY FIX: January 13, 2006 i386 architecture
Change the implementation of i386 W^X so that the "execute line" can move around. Before it was limited to being either at 512MB (below which all code normally lands) or at the top of the stack. Now the line can float as mprotect(2) and mmap(2) requests need it to. This is now implemented using only GDT selectors instead of the LDT so that it is more robust as well.

008: SECURITY FIX: January 5, 2006 All architectures
Do not allow users to trick suid programs into re-opening files via /dev/fd.

007: SECURITY FIX: January 5, 2006 All architectures
A buffer overflow has been found in the Perl interpreter with the sprintf function which may be exploitable under certain conditions.

006: RELIABILITY FIX: November 5, 2005 All architectures
Due to wrong advertisement of RFC 3947 compliance interoperability problems with isakmpd(8) may occur.

005: SECURITY FIX: July 21, 2005 All architectures
A buffer overflow has been found in compress(3) which may be exploitable.
Please note that this fixes a different buffer overflow than the previous zlib patch.

004: SECURITY FIX: July 6, 2005 All architectures
A buffer overflow has been found in compress(3) which may be exploitable.

003: SECURITY FIX: June 20, 2005 All architectures
Due to a race condition in its command pathname handling, a user with sudo(8) privileges may be able to run arbitrary commands if the user's entry is followed by an entry that grants sudo ALL privileges to another user.

002: RELIABILITY FIX: June 15, 2005 All architectures
As discovered by Stefan Miltchev calling getsockopt(2) to get ipsec(4) credentials for a socket can result in a kernel panic.

001: SECURITY FIX: June 7, 2005 All architectures
Fix a buffer overflow, memory leaks, and NULL pointer dereference in cvs(1) . None of these issues are known to be exploitable. CAN-2005-0753 .
---------

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