Мой VPS с 2016 года !
✅ Виртуальные от 300 ₽/месяц, RAM 1-10GB, DISK 20-360 GB;
✅ Выделенные от 3000 ₽/месяц. RAM 4-64GB, DISK до 4TB;
✅ Intel Xeon, SSD, XEN, iLO/KVM, Windows/Linux, Администрирование;
✅ Бесплатно Full Backup и Anti-DDoS.
Спонсор проекта
Лучший вариант для анонимности купить прокси на выделенном сервере IPANN.NET.
Рекламки



Авторизация






Для восстановления доступа пишите на E-mail stoplinux@yandex.ru.
Последние комментарии
#1
A_L_M пишет: » Обычных пользователей вводят в заблуждение обещани... (22.06.2020)
// Экзорцизм
#2
watersoda пишет: »
Цитата:
... сделать хоть совсем немного полезного ...
(16.06.2020)
// Переход с Windows на Linux - ГЛУПОСТЬ
#3
roblox robux пишет: » I just love what you said. If you like free roblox... (07.06.2020)
// Риски безопасности в Red Hat Enterprise Linux
#4
Spotter пишет: » когда первый раз писал тот лонгрид, имел надежду. ... (03.06.2020)
// Экзорцизм
#5
admin пишет: » Spotter, попробуй корпоративную десятку. (02.06.2020)
// Экзорцизм
Цитаты
Руткиты в линуксе работают с ядром напрямую ;)
Наши сайты.
Наши другие сайты, которые всё ещё в сети:
1. Архив форума СЛОРа
2. Архив linexp.ru
3. Архив bitomatics.ru



В Linux исправили уязвимость 9-летней давности | автор: admin | 21 октября 2016

Категория: Security


Причина уязвимости — race condition («состояние гонки») при обработке подсистемой управления памяти copy-on-write операций для частных маппингов памяти, доступной только для чтения. Непривилегированный пользователь может воспользоваться этим для повышения своих привилегий и получения возможности записи в память, размеченную только для чтения.

Патч, устраняющий уязвимость, просуществовавшую в ядре девять лет (начиная с linux 2.6.22), уже представлен.




Некоторые эксперты назвали проблему одной из наиболее опасных уязвимостей в ядре, для эксплуатации которой есть надёжный рабочий прототип эксплоита на github, не зависящий от особенностей окружения, что упрощает атаку.

-----
Линус Торвальдс пишет: это древний баг, который я плох исправил одиннадцать лет назад в коммите 4ceb5db9757a ("Fix get_user_pages() race for write access"), но это исправление тогда отменили из-за проблем с s390 в коммите f33ea7f404e5 ("fix get_user_pages bug").

Ситуацию на s390 давно исправили, и теперь мы можем исправить это путём проверки pte_dirty() bit properly . Грязный бит в s390 был реализован в abf09bed3cce ("s390/mm: implement software dirty bits") , которые сделали его в v3.9. Более ранние ядра будут должны смотреть на саму страницу состояния.

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

Чтобы исправить это, мы вводим новый внутренний флаг FOLL_COW, чтобы отметить "yes,
мы уже сделали FOLL_COW" , а не играть гоночные игры с FOLL_WRITE , что
очень фундаментален, а затем использовать грязный флаг PTE, чтобы подтвердить, что
флаг FOLL_COW остается в силе.

https://lkml.org/lkml/2016/10/19/860
https://www.linux.org.ru/news/security/12959067

      ВНИМАНИЕ !
Возможно что-то уже неактуально. Обращайте внимание на даты !
Эта статья опубликована 21 октября 2016 года !



Голосов: 0


Прочитано 89739 раз и оставлено 2 комментариев.

Мой VPS с 2016 года !

Этот сайт размещён на мощностях компании Айпи Сервер с 2016 года. Стабильность проверена временем !






Комментарии посетителей

#1. watersoda

А рабочие эксплойты вообще под эту уязвимость были?

#2. admin

watersoda, есть надёжно работающий прототип:
www.opennet.ru/opennews/art.shtml?num=45354
github.com/dirtycow/dirtycow.github.io/blob/master /dirtyc0w.c

Добавление комментария:

Имя:
Пароль: (если зарегистрирован)
Email: (обязательно!)

теги форматирования

добавить смайлы


Правила комментирования >>