Большинство утилит/программ/скриптов и т.п. работают с временными файлами. Сначала они создают этот временный файл, пишут в него какие-то данные, а на выходе отдают готовый результат, будь то файл с выгрузкой либо что-то другое. А временный файл с которым производилась работа, естественно зачищается.
Наша задача на сегодня, перехватить этот временный файл, до того как он удалится. А для чего? Ситуации разные бывают.
Недавно я дебажил проблему с выгрузкой, которая годами работала, а потом сломалась, на выходе я получал пустой файл. Эту выгрузку делал как раз бинарник неизвестного происхождения. Отследить логику работы само собой не представлялось возможным.
Этот случай я успешно отдебажил. Временный файл удалялся ДО того как стать файлом выгрузки. Почему? Потому что процесс удаления временного файла работал в отдельном потоке (thread) и удалял временный файл спустя 30 секунд.
А так как выгрузка с каждым годом становилась все больше, 30ти секунд стало мало. По итогу временный файл удалялся, а на выходе создавался пустой файл без каких либо данных. Естественно никакой обработки эксепшенов в бинарнике не было, вечный статус - завершено успешно! Файл же есть на выходе, значит успешно. Не поспоришь.
На такие ёбнутые случаи и нужен strace, чтобы хоть немного понять, что происходит.
Короче расчехляем нашу лабораторию и создаем скрипт. Бинарники мучить не будем, bash скрипта будет достаточно для понимания.
1. Записываем во временный файл /tmp/test.txt этот самый UID.
2. Удаляем временный файл.
Почему не rm а unlink? Потому что в моём случае это был именно unlink, который я нашел просматривая лог strace. Чем отличается unlink от rm, расскажу в следующих постах.
Так, подопытный скрипт есть. Запускаем так:
В тот момент когда скрипт попытается удалить временный файл, наша инъекция не даст ему это сделать и завершит скрипт с ошибкой:
По умолчанию инъекция будет сделана всем системным вызовам unlink, но есть возможность указать диапазон или конкретный индекс срабатывания. В этом посте можешь глянуть как узнать конкретный индекс (смотри строчку с when=4+).
В моем случае я увидел кусок своей выгрузки, которая резко прерывалась. Ну а дальше всё стало очевидным, что-то где-то не успевает. Включил таймер и нашел закономерность в 30 секунд, посмотрел дочерние процессы которые плодились и обнаружил активность этой зачищалки.
Отдал результаты дебага разработчикам, фиксить это конечно никто не стал, такой гемор никому не нужен. По итогу ребята с нуля переписали на golang и сразу чудным образом нашлась документация. Жиза.
Вот такие приключения порой случаются. Изучай. Хорошего дня!
tags: #linux #debug #bash
—
💩 @bashdays
Наша задача на сегодня, перехватить этот временный файл, до того как он удалится. А для чего? Ситуации разные бывают.
Недавно я дебажил проблему с выгрузкой, которая годами работала, а потом сломалась, на выходе я получал пустой файл. Эту выгрузку делал как раз бинарник неизвестного происхождения. Отследить логику работы само собой не представлялось возможным.
Этот случай я успешно отдебажил. Временный файл удалялся ДО того как стать файлом выгрузки. Почему? Потому что процесс удаления временного файла работал в отдельном потоке (thread) и удалял временный файл спустя 30 секунд.
А так как выгрузка с каждым годом становилась все больше, 30ти секунд стало мало. По итогу временный файл удалялся, а на выходе создавался пустой файл без каких либо данных. Естественно никакой обработки эксепшенов в бинарнике не было, вечный статус - завершено успешно! Файл же есть на выходе, значит успешно. Не поспоришь.
На такие ёбнутые случаи и нужен strace, чтобы хоть немного понять, что происходит.
Короче расчехляем нашу лабораторию и создаем скрипт. Бинарники мучить не будем, bash скрипта будет достаточно для понимания.
#!/bin/bashUID обозначает идентификатор пользователя, то есть номер, назначенный каждому пользователю Linux.
echo $UID > /tmp/test.txt
unlink /tmp/test.txt
1. Записываем во временный файл /tmp/test.txt этот самый UID.
2. Удаляем временный файл.
Почему не rm а unlink? Потому что в моём случае это был именно unlink, который я нашел просматривая лог strace. Чем отличается unlink от rm, расскажу в следующих постах.
Так, подопытный скрипт есть. Запускаем так:
strace -yfe inject=unlink:error=EACCES ./script.shВ этой конструкции мы говорим strace, чтобы проинжектил наш системный вызов unlink и передал ему насильно ошибку EACCES (Permission denied).
В тот момент когда скрипт попытается удалить временный файл, наша инъекция не даст ему это сделать и завершит скрипт с ошибкой:
[pid 677954] unlink("/tmp/test.txt") = -1 EACCES (Permission denied) (INJECTED)
А сам временный файл останется на диске. Открываем его и смотрим, что же там внутри происходит.По умолчанию инъекция будет сделана всем системным вызовам unlink, но есть возможность указать диапазон или конкретный индекс срабатывания. В этом посте можешь глянуть как узнать конкретный индекс (смотри строчку с when=4+).
В моем случае я увидел кусок своей выгрузки, которая резко прерывалась. Ну а дальше всё стало очевидным, что-то где-то не успевает. Включил таймер и нашел закономерность в 30 секунд, посмотрел дочерние процессы которые плодились и обнаружил активность этой зачищалки.
Отдал результаты дебага разработчикам, фиксить это конечно никто не стал, такой гемор никому не нужен. По итогу ребята с нуля переписали на golang и сразу чудным образом нашлась документация. Жиза.
Вот такие приключения порой случаются. Изучай. Хорошего дня!
tags: #linux #debug #bash
—