Выпуск 9.04 поддерживался до 23 октября 2010 года. Об обнаруженной вами уязвимости было сообщено в августе 2009 года. Кажется разумным, что, поскольку релиз все еще был актуальным и поддерживался в то время, ISO был исправлен, и то, что вы скачали, было версией, которая больше не уязвима.
Более того, вы, кажется, довольно хорошо продемонстрировали, что она не уязвима. В конце концов, вы попробовали эксплойт, и, похоже, он не удался.
Почему бы вам не попробовать более новый эксплойт? Что-то вроде CVE-2013-2094, который должен также повлиять на Ubuntu, например.
Как говорит Кусалананда, увеличение file-max
не окажет прямого влияния на использование памяти, но позволит процессам открывать больше файловых дескрипторов, что окажет влияние -на эффект (как от отслеживания описаний файлов в ядре и увеличенное использование памяти в процессах, использующих эти описания и дескрипторы )— комментарии ядра предлагают примерно один килобайт на файл для данных ядра и уменьшат значение по умолчаниюfile-max
(8192 ), если это в конечном итоге представляет более 10% памяти при загрузке системы (, т.е. имеется только 80 МБ ОЗУ ). Максимальное значение, устанавливаемое ядром, — это максимальное значение, которое может быть сохранено в переменной типа long
в C вашей архитектуры.
Если вы увеличиваете file-max
, вы также должны увеличивать inode-max
; в документации ядра говорится, что это значение должно быть «в 3 -4 раза больше, чем значение в файле -max, поскольку stdin, stdout и сетевые сокеты также нуждаются в структуре inode для их обработки».
Обратите внимание, что при нажатии file-max
в журнале ядра появится сообщение «VFS :файл -максимальный предел n достигнут» с соответствующим значением для n .. Если у вас нет этого в ваших журналах, вы либо не нажимаете file-max
, либо слишком сильно фильтруете свои журналы (, это сообщение журнала уровня информации -).
(file-max
не ограничивает процессы с помощью CAP_SYS_ADMIN
, поэтому ее нажатие не остановит все.)