Что такое уязвимость Read-After-Free (RAF) и как она может проявиться в Go?

Тип вопроса: Безопасность Вероятность: 10% Категория: Golang Разработчик

Ответ

Read-After-Free (RAF) — это не паттерн проектирования, а класс уязвимостей, связанных с некорректной работой с памятью. Суть уязвимости в том, что программа пытается прочитать данные из области памяти, которая уже была освобождена (free).

В языках с ручным управлением памятью (как C/C++) это частая проблема. В Go, благодаря сборщику мусора (GC), эта уязвимость практически не встречается в безопасном коде, так как GC не освободит память, пока на нее есть хотя бы одна ссылка.

Проявление в Go

Однако уязвимость RAF может проявиться в Go в двух основных случаях:

  1. Использование пакета unsafe: Пакет unsafe позволяет обходить гарантии безопасности Go и работать с памятью напрямую через указатели (unsafe.Pointer).
  2. Интеграция с C-кодом через cgo: При вызове функций из C-библиотек, которые возвращают указатели на память, выделенную в C, Go-программа должна явно управлять освобождением этой памяти (C.free). Если этого не сделать или обратиться к указателю после освобождения, возникнет RAF.

Пример опасного кода с unsafe:

import "unsafe"
import "runtime"

func main() {
    var ptr unsafe.Pointer

    func() {
        // Создаем срез в локальной области видимости
        data := []byte("hello world")
        // Получаем небезопасный указатель на его данные
        ptr = unsafe.Pointer(&data[0])
    }()

    // После выхода из функции, 'data' становится недостижимой.
    // GC может в любой момент очистить эту память.
    runtime.GC() // Принудительно вызываем GC для демонстрации

    // Попытка чтения из освобожденной памяти.
    // Это неопределенное поведение (Undefined Behavior - UB).
    // Может привести к панике, чтению "мусора" или уязвимости.
    value := *(*byte)(ptr)
    println(value)
}

Риски и как избежать:

  • Риски: Неопределенное поведение, падение программы (panic), утечка данных, возможность удаленного выполнения кода (RCE).
  • Как избежать:
    • Не используйте пакет unsafe без крайней необходимости и полного понимания последствий.
    • При работе с cgo всегда следуйте документации C-библиотеки по управлению жизненным циклом памяти и своевременно вызывайте C.free.

Ответ 18+ 🔞

Да ты послушай, что за дичь творится в мире программирования! Читать-после-освобождения, блядь! Это ж не какая-то там архитектурная фигня, а самая настоящая дыра, где программа, как последняя дура, лезет читать память, которую уже сама же и похоронила.

В Сишке, понятное дело, это обычное дело — сам выделил, сам забыл, сам прочитал в помойку. А в Go-то, в нашем уютном, вроде как сборщик мусора за всем следит, подметает, не дает наступить в говно. И вправду, в нормальном-то коде этой хуйни почти не встретишь.

Но нет же, находятся умники! Находят два способа, блядь, всё испортить:

  1. Пакет unsafe. Ну, ясное дело, раз он «небезопасный», значит, там можно творить какую-то мудя! Это как дать ребёнку гранату со словами «поиграй, только чеку не дёргай».
  2. Связка с Си через cgo. Тут вообще ад начинается. Сишная функция выдала тебе указатель, а ты в своём гоёвом мире про него забыл. А потом этот указатель, как призрак, всплывает и пытается что-то прочитать из уже освобождённой Сишной памяти. Пиздец и хаос.

Вот смотри, какой идиотский пример можно наколдовать с этим unsafe:

import "unsafe"
import "runtime"

func main() {
    var ptr unsafe.Pointer

    func() {
        // Создаем срез в локальной области видимости
        data := []byte("hello world")
        // Получаем небезопасный указатель на его данные
        ptr = unsafe.Pointer(&data[0])
    }()

    // После выхода из функции, 'data' становится недостижимой.
    // GC может в любой момент очистить эту память.
    runtime.GC() // Принудительно вызываем GC для демонстрации

    // Попытка чтения из освобожденной памяти.
    // Это неопределенное поведение (Undefined Behavior - UB).
    // Может привести к панике, чтению "мусора" или уязвимости.
    value := *(*byte)(ptr)
    println(value)
}

Видал? Указатель сохранили, а данные, на которые он указывал, уже на том свете. И после сборки мусора мы пытаемся прочитать что-то из этого адреса. Это как засунуть руку в могилу и надеяться, что покойник подаст тебе пиво. Результат? Да кто его знает, ёпта! Может, программа рухнет, может, прочитает какой-то старый пароль из соседнего процесса, а может, просто выведет белиберду. Неопределённое поведение, хуле.

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

Как не стать таким мудаком?

  • К unsafe не подходить, блядь, без крайней нужды. Это не игрушка, а хирургический скальпель. Им можно и себе всё отрезать.
  • Работая с cgo, быть внимательнее, чем сыщик. Если Сишная библиотека говорит «вызови free()», значит, надо вызвать, а не надеяться на авось. И следить, чтобы после освобождения никто не тыкался в этот указатель.

Вот так-то. Безопасность — она не просто так придумана. А то потом сидишь и думаешь: «И кто ж это меня, дурака, заложил?».

© ХакСобесов, 2026
support@hacksobesov.com