=== Виртуальная память в Linux. Часть 1.1 ===

Давным давно системы были однозадачными и вся память была доступна одному процессу. Не надо было беспокоиться о приватности данных и безопасности. Потом наступила эра многозадачности: компьютером стали пользоваться одновоременно несколько человек. Каждый запускает свои программы. Ранние реализации просто отдавали всю память процессу, а когда приходил другой процесс - содержимое памяти первого сбрасывалось на диск и в неё загружались данные нового процесса.

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

#OS #OSTEP #memory #vm

=== Виртуальная память в Linux. Часть 1.2 ===

Этот процесс называется Sharing. Это использование одной физической памяти одновременно несколькими процессами. У каждого процесса есть своё адресное пространство

Адресное пространство (Address Space) - память, которую видит процесс. В 32 разрядных системах это 2^32 байт (4 ГБ), в 64 разрядных 2^64 Б (16 ЭБ). Очевидно, что физическая память не имеет отношения к объёму адресного пространства. Не у каждого из нас ведь есть 16 ЭБ RAM. Это всего лишь абстракция, предоставляемая операционной системой

Сам Address Space делится на три части:
- Code. Код процесса

- Heap. Куча. Начинается сразу после кода и растет вниз (от stack к 2^32 в 32-разрядных системах)

- Stack. Стек. Начинается с конца адресного простарнства и растет вверх (с 2^32 в 32-разрядных системах до конца кучи)

#OS #OSTEP #memory #vm

=== Виртуальная память в Linux. Часть 1.3 ===

Как видно на картинке процесс считает, что адресация его памяти начинается с ноля. КАЖДЫЙ процесс так считает. И все они одновременно работают в физической памяти

Как ОС создаёт эту иллюзию приватного огромного адресного пространства, начинающего с нуля для каждого процесса, на единой, не всегда большой физической памяти?

#OS #OSTEP #memory #vm

Перевели официальный FAQ MITRE ATT&CK

(финализировали все формулировки)

Перевод опубликован в статье на Хабр и в разделе Вопросы и ответы на сайте сообщества.

Переводили

— Антон Шипулин, сооснователь RUSCADASEC
— Олег Скулкин, Руководитель лаборатории цифровой криминалистики и исследования вредоносного кода Group-IB
— Илья Енин, SOC Analyst Team Lead, Kaspersky Lab
— Ольга Моск, редактор, переводчик, менеджер проектов Positive Technologies
— Евгений Зудилин
— Даниил Югославский, волонтер Russians for Ukraine

Архив

Оригинальные сообщения доступны в дискуссионной комнате. Веб-версия обсуждения сохранена для индексации поисковыми системами. Zip-архив обсуждения сохранен для обеспечения целостности (неизменности), которая гарантируется хеш-функцией SHA-256:

$ shasum -a 256 archive/dc_4.zip
4b350895f49ffd77018d75e71e83115142b3c7240f80334c2ba4cdb596f7d49c  archive/dc_4.zip

📩 Подписаться 📩

=== Виртуальная память в Linux. Часть 2. Стек, куча и код ===

В прошлый раз мы увидели, что адресное пространство процесса делится на три части: код, куча и стек. Рассмотрим их подробнее.

- Code. Первая часть адресного пространства. Начинается с 0. Тут содержится код исполняемой программы. Эта часть памяти может быть доступна другим процессам. Ведь таким образом мы можем сэкономить память при запуске нескольких идентичных процессов

- Heap. Начинается сразу после кода и растет вниз. Система заранее не знает сколько памяти нужно выделить по heap. Да и это было бы неэффективно. Поэтому под heap выделяется какая-то инициализационнная часть памяти. Когда процессу понадобится больше памяти для heap, он запросит её у ОС через системный вызов malloc(). Heap эксплицитен. Память для него нужно выделять в программе явно и чистить после себя. Освобождается память системным вызовом free(). В heap хранятся связанные списки, хэш таблицы, деревья и другие структуры данных

- Stack. Начинается с конца адресного пространства и растет вверх. Стек управляется компилятором имплицитно. Поэтому он называется автоматической памятью. Когда функция выполнилась, она вернула значение и компилятор деаллоцировал память. В стеке хранятся локальные переменные, параметры функций и возвращаемые адреса


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

Конечно, адресное пространство - всего лишь абстракция, предоставляемая процессам со стороны ОС. Вся память, которую видит процесс - абстракция. Поэтому она и называется виртуальной памятью (Virtual Memory). Адреса виртуальной памяти указывают на память физическую. Преобразованием виртуальных адресов в физические занимается ОС с помощью различных аппаратных ухищрений

#OS #OSTEP #memory #vm

Каждое ядро CPU имеет два регистра: base (базовый) и bound (граничный).

- В base регистре лежит смещение. Физический адрес = виртуальный адрес + base

- bound регистр указывает на границу физической памяти процесса. Если адрес, к которому обращается процесс выходит за границу, указанную в bound регистре, вызывается исключение и процесс завершашется

Пример:

Address Space Size 4 KB
Loaded in phys address 16 KB
• Virtual Address 0 → Physical Address 16 KB
• VA 1 KB → PA 17 KB
• VA 3000 → PA 19384
• VA 4400 → Fault (out of bounds)

Регистры - часть CPU и работу по релокации делает CPU. Часть процессора, которая занимается работой с памятью называется Memory Management Unit (MMU). Чем сложнее эта работа, тем более сложным будет MMU

Проблемы:
- При создании процесса ОС должна найти место в физ памяти для размещения там адресного пространства процесса. То есть нужно иметь список свободного места (free list)

- После завершения процесса нужно освободить его место в физ памяти и записать обратно в free list

- У ЦПУ только одна пара бэйз-баунд регистров. При конекст свитчинге нужно сохранить куда-то бэйз и баунд текущего процесса и считать откуда-то эти регистры нового процесса. Procss Control Block (PCB)

- Доступ к регистрам привилигрованный. Только кернел режим ОС может ими управлять. Если бы это мог делать обычный процесс, он бы мог перезаписать значения регистров и читать/писать чужую память

- Мы смогли создать независимую память для каждого процесса и изолировать её. Но т.к. аллоцируем всё адресное пространство, то аллоцируемое, но неиспользуемое место между хипом и стеком простаивает впустую, как видно на рис. 15.2. Это называется внутренней фрагментацией

В следующей части попробуем решить эти проблемы

#OS #OSTEP #memory #vm

В обзоре KazHackStan я упоминал доклад Вадима Шелест об инфраструктуре для RedTeam.
А сегодня увидел ссылку на детальный пост о деплое инфры в Linode с помощью Terraform. Пост будет полезен как админам/девопсам, так и безопасникам.

- Знакомые с IaC и Terraform могут найти для себя новое про инфру для RedTeam
- А security специалисты поглубже узнают про IaC

#terraform #redteam #security #nebula #cobaltstrike #caddy #iac

IP адреса Google
https://www.gstatic.com/ipranges/goog.txt
#google #ip #network

=== Виртуальная память в Linux. Часть 4. Сегментация ===

Для предовтарщения внутренней фрагментации можно вместо одной пары регистров использовать три. По паре на каждый сегмент адресного пространства: код, стек, хип

Получаем такую структуру в MMU

Segment | Base | Size
---——----|—------|-------
Code | 32K | 2K
Heap | 34K | 2K
Stack | 28K | 2K

Я не буду пересказывать тут как система обращается к разным сегментам памяти. Интересующиеся могут почитать об этом в книге

Иногда требуется шарить некоторые сегменты между адрес спейсами. Например шаринг сегмента с кодом. Для этого используется protection bit. Выставив его в read-only мы позволим читать из сегмента другим процессам

Итак, сегментация позволила нам не расходовать впустую огромные куски памяти с минимальным оверхедом на трансляцию

Проблема заключается в том, что сегментация все еще недостаточно гибкая, чтобы поддерживать наше полностью обобщенное, разреженное адресное пространство. Например, после освобождения памяти от закрытых программ мы получим разреженную память как на картинке слева (это и есть внешняя фрагментация). То есть в памяти появляется много неиспользуемых дырок, которые нужно чем-то занять. Но это будет не всегда возможно из-за того, что программам будет требоваться больше места, чем есть в каждой из дырок

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

#OS #OSTEP #memory #vm

https://habr.com/ru/company/pt/blog/690716/

#security #bughunt

Слышали про honeypot?
Это специально оставленная брешь в системе, которую с большой вероятностью найдет хакер и наследит там. По этим следам мгновенно будет понятно, что система находится под атакой и админы должны усилить бдительность.

canarytokens - генератор артефактов, при открытии которых приходит алерт на электронную почту

Из артефактов:
- URL
- DNS
- AWS key
- MS Office document
- kubeconfig
- PDF
- EXE/DLL
- WireGuard config
- Дампы баз данных
- ...

#honeypot #security

Операционной системе необходимы драйверы для любого устройства, которое потенциально может быть подключено к системе. Неудивительно, что драйверы устройств занимают огромную часть кода ОС. Исследования ядра Linux показали, что 70% кода - драйверы. Когда кто-то говорит, что ОС это миллионы строк кода, это значит, что ОС это миллионы строк кода драйверов. Конечно, для каждой конкретной инсталляции большинство этого кода неактивно.

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

#ostep #linux #os

Оказывается, Большая Медведица - не просто ковш.
Как теперь с этим жить?
https://stellarium-web.org/

== Виртуальная память в Linux. Часть 5. Пейджинг ==

Наша цель - виртуализация памяти. Использовать одну физическую память разными процессами. Безопасно и эффективно. Сегментация решает эти задачи, но имеет ряд проблем: управление свободной памятью сложно, т.к. фрагментация и сегментация не настолько гибки, как хотелось бы. Получаем куски неиспользуемой памяти.

На помощь приходит пейджинг. Вместо деления адресного пространства на три логических сегмента (каждый - динамического размера) делим адресное пространство на фиксированные блоки - страницы

Физическая память тоже делится на страницы. В них будут размещаться страницы адресного пространства. Страницы физической памяти называются page frame

Каждая виртуальная страница (VPN - Virtual Page Number) указывает на физический фрейм (PFN - Physical Frame Number). Для их сопоставления используется Page Table - таблица страниц. Для каждого процесса она своя и находится по адресу /proc/PID/pagemap. Но открывать этот файл бесполезно - каждая страница это 64-битное (для 64-битных систем) значение. Для страниц размером 4 КБ это 2^52 страниц по 8 байт каждая. Это очень много данных и открытие такого файла займет годы. В /proc/PID/maps можно увидеть все используемые страницы.

Сам виртуальный адрес состоит из двух частей: VPN и offset (сдвиг). VPN указывает на страницу, а сдвиг - на смещение байт в этой странице. В трансляции адресов участвует толкьо VPN. Сдвиг остается прежним.

На самом деле в Page Table содержатся не только данные о сопоставлении виртуальных и физических страниц. Например:
- valid bit - указывает на корректность трансляции - что такая страница существует

- protection bits - уровевнь доступа (read/write/executable)

- present bit - есть ли страница в физической памяти или в свопе (swap)

- dirty bit - изменялась ли страница после её помещения в своп

- ...

Пейджинг гибкий, упрощает управление свободным пространством. С ним нет внешней фрагментации, поскольку используются страницы одинакового размера. Освободившийся физический фрейм легко занимается новой страницей того же размера. Однако пейджинг всё ещё дорогая операция и не всегда эффективная (чтобы занять 1 бит в памяти, требуется выделить целых 4 КБ на страницу)

#OS #OSTEP #memory #vm