Да. Это не серверная машинка, тут ты прав. С серверной все еще хуже, там практически нет утилит, которые не нужны для веба.

Но общую идею я понял с закидыванием готового бинаря. Придется усложнять юзерам жизнь :)

Посоны! Чот не работают хвалёные эксплоиты:

test@ntfs-Vostro-3555:~$ /lib64/ld-linux-x86-64.so.2 ./a.out
DirtyCow root privilege escalation
Backing up /usr/bin/passwd to /tmp/bak
cp: failed to access '/tmp/bak': Permission denied
Size of binary: 54256
Racing, this may take a while..
thread stopped
thread stopped

... # всё ещё работает

Ну а бинарники любые можно запускать, хоть и с правами обычного юзера.

Но общую идею я понял с закидыванием готового бинаря

Нет. Идея не в закидывании готового бинаря, а в том, что куча интерпретаторов имеет возможность выполнять код в памяти. noexec и umask тебя не спасут, когда есть возможность передать или сгенерировать код прямо в память.

Эмм...Специально ничо не патчил, но пару дней назад скомпилил ядро 4.4. Ты ломал обыкновенную Убунту 16.04. Обновления не ставлю принципиально.

Та шелл засекюрить труда не составит. Особенно если он правильно построенный, выделенный. Мне больше интересно, можно ли эту багу использовать с веба. Через пых или cgi-perl.

Видимо 4.4.* не подвержено уязвимости. Либо эксплоиты надо править под него. Я честно говоря даже не смотрел толком что там внутри и как оно должно взаимодействовать с багой в ядре - просто скачал и запустил.

Через пых или cgi-perl.

Если пых позволяет писать файлы хоть куда-нибудь (скорее всего да) и позволяет делать exec() (скорее всего да), то эксплоит использовать можно.

Та шелл засекюрить труда не составит

Я назвал 3 командных интерпретатора.

И кстати tailgunner дело говорит. В том же питоне, насколько я помню, есть стандартные модули для ffi. Они скорее всего позволяют выделять память и вызывать произвольные функции по произвольному адресу в памяти. Этого достаточно чтобы выполнить любой произвольный код даже без закидывания файла и вызова exec().

не смотрел толком что там внутри

IMHO, это самый простой эксплойт, что я видел. Нет ни подготовки хитрых данных, ни попыток протолкнуть нагрузку. Просто одна нить отчаянно вызывает madvise, а вторая отчаянно вызывает write. Фишка в том, что реализация в ядре на короткое время ставит флаг доступности записи, и write срабатывает.

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

И кстати убунта там не обыкновенная:

2016-10-21 00:19:33 install linux-image-4.4.21-custom:amd64 <none> 4.4.21-custom-10.00.Custom
2016-10-21 00:19:33 status half-installed linux-image-4.4.21-custom:amd64 4.4.21-custom-10.00.Custom
2016-10-21 00:19:38 status unpacked linux-image-4.4.21-custom:amd64 4.4.21-custom-10.00.Custom
2016-10-21 00:19:39 status unpacked linux-image-4.4.21-custom:amd64 4.4.21-custom-10.00.Custom
2016-10-21 00:19:39 configure linux-headers-4.4.21-custom:amd64 4.4.21-custom-10.00.Custom 4.4.21-custom-10.00.Custom
2016-10-21 00:19:39 status unpacked linux-headers-4.4.21-custom:amd64 4.4.21-custom-10.00.Custom
2016-10-21 00:19:39 status half-configured linux-headers-4.4.21-custom:amd64 4.4.21-custom-10.00.Custom
2016-10-21 00:19:39 status installed linux-headers-4.4.21-custom:amd64 4.4.21-custom-10.00.Custom
2016-10-21 00:19:39 configure linux-image-4.4.21-custom:amd64 4.4.21-custom-10.00.Custom 4.4.21-custom-10.00.Custom
2016-10-21 00:19:39 status unpacked linux-image-4.4.21-custom:amd64 4.4.21-custom-10.00.Custom
2016-10-21 00:19:39 status half-configured linux-image-4.4.21-custom:amd64 4.4.21-custom-10.00.Custom
2016-10-21 00:20:00 status installed linux-image-4.4.21-custom:amd64 4.4.21-custom-10.00.Custom

Понел, спасибо за подсказки.

Кстати только что прилетел какой-то апдейт ядра в моей Бубунте, на 3 Кб. Космонавт обо мне заботится :)

Не не чувак, там самая обыкновенная Убунта 16.04. Ядро я компилил пару дней назад, патчей дополнительных не ставил, так...рутинное прибивание гвоздями дров и отколачивание initrd.

Прошерстил только что еще разок конфиг ядра, вроде никаких новых неизвестных опций не обнаружил. Быть может эта бага в стандартных сборках ? Ну либо космонавт уже давно в курсе про багу, все таки linux-source в репах с патчами от Каноникла.

А какие исходники ты за основу взял?

Отремонтировали ещё в среду:

linux (4.4.0-45.66) xenial; urgency=low

  * CVE-2016-5195
    - SAUCE: mm: remove gup_flags FOLL_WRITE games from __get_user_pages()

  * srcname from mount rule corrupted under load (LP: #1634753)
    - SAUCE: apparmor: fix sleep in critical section

 -- Stefan Bader <email address hidden>  Wed, 19 Oct 2016 11:24:20 +0200

apt-get install linux-source :) Впрочем да, ведерко патченное. Увидел в ченджлоге с urgency-low, что есть странно как по мне.

Видимо 4.4.* не подвержено уязвимости.

https://www.kernel.org/

https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.4.26

commit 1294d355881cc5c3421d24fee512f16974addb6c
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Thu Oct 13 13:07:36 2016 -0700

mm: remove gup_flags FOLL_WRITE games from __get_user_pages()

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

Уязвимость устранена в выпусках ядра Linux 4.8.3, 4.7.9 и 4.4.26.

gentoo-sources-4.4.26 (21 Oct 2016)
21 Oct 2016; Mike Pagano <mpagano@gentoo.org> +gentoo-sources-4.4.26.ebuild:
sys-kernel/gentoo-aources: Linux patch 4.4.26

Правильно ли я понимаю, что 4.4.26 в Генте не подвержено данной уязвимости?

На винде наверняка 10 таких уязвимостей с версии 3.1, и закрывать никто не собирается.

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

C безопасен, говорили они. Rust не нужен, говорили они.

Если вирус это сделал, то ты тащем-то в заднице. Можно, конечно, прицепить антивирус к ядерным вызовам и сделать анализ паттерна вызова, но это все слегка затормозит.

Если вирус сделает фигню, то нормальный антивирус тормозит выполнение программ в которых она произошла не так давно и выбрасывает пользователю окошко с предложением грохнуть их, разрешить фигню один раз или всегда. Ну или убивает подозрительные процессы автоматически, а там пусть хоть всё после этого повисни. Сам вирус при этом обычно не ловится, но прикол в том, что если вирус будет проявлять такую активность слишком часто, то пользователь просканирует все файлы или снесёт систему. Вирусописателю такого не надо, потому правильный вирус будет заниматься подозрительной фигнёй раз в несколько дней, умный пользователь давать антивирю разрешение убивать всех и вся, а в промежутках между атаками нормально пользоваться системой - в общем все почти счастливы. Мощности процессора на это надо не так много, но места на диске антивирусные базы отожрут много.

Я так понял, это говно не вылезает за пределы своего индюшатника. Так что вряд ли. Эдакий wine наоборот.

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

Мощности процессора нужно пропорционально количеству сисколов. Так что на http сервере с миллионами запросов в секунду будет бобо.

Внезапно, ПО работает не только на серверах, но и на не линуксовых десктопах, а там антивирусы научились оптимизировать свою деятельность и что-то при этом ловить/запрещать. В линуксе можно обрабатывать все операции с правами, доступ куда не надо. Например, если программа из вайна полезла изменять исполняемые бинарники, то почему бы антивирусу не посоветоваться с пользователем. Если появится достойный инструмент, тогда появятся и идеи чем его ещё нагрузить и как оптимизировать под такие задачи ядро. А то тот же селинукс - непонятное нечто, делающее непонятно что.

Наличие или отсутствие gcc не спасет. Кто мешает скомпилять у себя, а потом залить туда, или даже залить gcc локально.

А мы им echo отключим, во! Классно я придумал?

лучше из розетки выдернуть

благо такой шляпы нет у FreeBSD

надо переписать на русте

надо: https://github.com/redox-os/kernel

A collaborative effort to rewrite the kernel with focus on correctness and code quality. Why? The kernel code was getting increasingly messy to the point where only the original writer would be able to find and fix bugs.

лол. передай парням, что я пошутил

Вообще спор о том справится или не справится с этим антивирус я считаю неправильным. В том смысле что надо искать и закрывать уязвимости в том числе в ядре. И если мы говорим об антивирусе как о продукте коммерческой компании получающей по сути профит от найденных и предотвращенных уязвимостей, за счет своей коммерческой сути делающей это активно, а не раз в 9 лет - то я думаю было бы неплохо сделать сервис по донату за обнаруженные уязвимости. В такой системе профессиональные кулхацкеры получают сотни нефти за закрытые уязвимости, сообщество получает быструю свободную и защищенную экосистему и не надо тормозить все антивирусом.

Оно сдохло.

Ну и что, что не про винду новость? Весь этот сайт и линукс существуют по причине определенного к ней отношения.

http://i37.tinypic.com/28r34w3.jpg

Мужик на заднем плане от этой вашей венды аж окосел.

Еще одно подтверждение, что монолитное ядро гуано.

В ядре Linux обнаружена критическая уязвимость у меня дежавю

Ещё страницу до «Похожие темы» прокрути, ШОК ВИДЕО.

«Еще одно подтверждение, что X гуано», где X что-либо хоть отдалённо использующееся в ядре

Это ужасно. Почему никто не перепишет линукс?

Фуллтайм аутистов обеспеченых мамкой не хватает?

Как же сдохло, когда ссылка как раз о том, как оно корчится?)

Как же сдохло, когда ссылка как раз о том, как оно корчится?)

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

http://bfy.tw/8K8s

нет, там божатся что ни строчки кода ядра linux внутри нет.

race condition («состояние гонки»)

В скобочках для тех кто вовсе не знает english’а и тех кто не знает про онлайнтрансляторы что ли?

Что там?

Что там?

Палец Торвальдса.

Эпичная фотка была, когда появилась. Линус тогда еще доставлял.

Говорят патч исправляющий был отправлен давным-давно

Но его было решено «попридержать»
И после этого вы говорите что в винде зонды?

Говорят патч исправляющий был отправлен давным-давно

Если он был отправлен, то есть ссылка на lkml/mail-archive/spinics/marc.info/gmane/...? Или везде потёрли? Может, archive.org успел заархивировать? или и туда добрались? (А, кстати, где расположены его сервера? Если в штатах, то, всё ясно.)