Представлены (https://lkml.org/lkml/2011/8/17/272) очередные корректирующие релизы Linux-ядра: 3.0.3 с 26 исправлениями (http://www.kernel.org/pub/linux/kernel/v3.0/ChangeLog-3.0.3) (пару дней назад также вышел релиз 3.0.2 с исправлением (http://www.kernel.org/pub/linux/kernel/v3.0/ChangeLog-3.0.2) 91 ошибки), 2.6.32.45 (6 исправлений (http://www.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.32...)) и 2.6.33.18 (6 исправлений (http://www.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.33...)). Как обычно, в анонсе выхода новых версий подчеркивается обязательность проведения обновления.
Во всех представленных версиях отмечено одно важное изменение: для генерации порядковых номеров TCP-пакетов (TCP/IP sequence number) и идентификаторов фрагментов пакетов теперь используются не 24-битные значения на основе хэша MD4 в сочетании с 8-разрядным счетчиком, а 32-битные идентификаторы на основе MD5 (lib/md5.c) без дополнительного счетчика. В примечании к исп...URL: https://lkml.org/lkml/2011/8/17/272
Новость: http://www.opennet.me/opennews/art.shtml?num=31525
Обновился отсюда http://kernel.ubuntu.com/~kernel-ppa/mainline/, до 3.1.0-0301rc2-generic
>Во всех представленных версиях отмечено одно важное изменение: для генерации порядковых номеров TCP-пакетов (TCP/IP sequence number) и идентификаторов фрагментов пакетов теперь используются не 24-битные значения на основе хэша MD4 в сочетании с 8-разрядным счетчиком, а 32-битные идентификаторы на основе MD5 (lib/md5.c) без дополнительного счетчика. В примечании к исправлению значится, что использование MD4 в настоящее время не оправдано с точки зрения безопасности (высокая предсказуемость), а былой выигрыш в производительности на современных компьютерах ничтожно мал. Поэтому решено использовать более безопасный метод, основанный на хэше MD5.Это очень хреновое решение для ядерного уровня. Выигрыш ничтожно мал на современных компьютера и если не рассматривать числа в мастштабе статистики. В студенчестве я от безделья проверял скорость генерации хэшей за секунду у MD4 и MD5. Сейчас уже не скажу - но тогда я разницу получил 10 в какой-то степени (>=2) раз.
Надеюсь девелоперы все-таки оставили возможность выбора способа генерации хэша при сборке ядра. А безопасные вещи я думаю надо реализовывать на более высоких уровнях (по модели OSI).
>> Это очень хреновое решение для ядерного уровня.фигня.
генерация id при фрагментации ip-пакета редка - нормальные протоколы должны ее избегать,
генерация TCP sequence number - только в момент установки TCP соединения.
> фигня.
> генерация id при фрагментации ip-пакета редка - нормальные протоколы должны ее избегать,
> генерация TCP sequence number - только в момент установки TCP соединения.Вы меня почти успокоили. Надо как-нибудь найти время и осилить всю "кухню" сетевого уровня.
> Linux-ядра: 3.0.3 с 26 исправлениями (пару дней назад также вышел релиз 3.0.2 с исправлением 91 ошибки)и того 115 ошибок :) нехрена себе обкатывают на хомячках.
>> Linux-ядра: 3.0.3 с 26 исправлениями (пару дней назад также вышел релиз 3.0.2 с исправлением 91 ошибки)
> и того 115 ошибок :) нехрена себе обкатывают на хомячках.По вашему же разработчики в угоду хомячкам должны все сделать идеально и подать на блюдечке? А хомячки в свою очередь порадуют разработчком тем что найдут немного времени и внимания чтоб опробовать их проект, так? Я все правильно понял?
скажите, "уязвимость позволяющая локальному пользователю повысить свои привилегии при запуске администратором утилиты perf в директории, подконтрольной атакующему." - это то, о чем в логах сообщается, что [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a purgeable buffer?
короче, поставил ядро 3.0.3 - действительно оказалось, что "уязвимость позволяющая локальному пользователю повысить свои привилегии при запуске администратором утилиты perf в директории, подконтрольной атакующему." - это то, о чем в логах сообщается, что [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a purgeable buffer.
после установки ядра 3.0.3 этот баг больше не появлялся.