As I understand it, you did this: the application ignores the system call 69, 4. if launched without the debug flag?
This contradicts: All subfunctions except 4 and 5 apply only to processes / threads started from the current function 70 with the debug flag set. Debugging of multithreaded programs is not yet supported.
Уязвимости ядра
-
Изобретайте колёса каждый раз, когда хотите написать новую программу.
Exception for 69.4 is possibly wrong. What's problem use 70.7 before? What for use 69.4 and 69.5 directly?
Критическая уязвимость ядра при запуске программ. Заключается в использовании неправильных значений в заголовке исполнимого файла формата MENUET0x:
1. Если в заголовке указать некорректные адреса для буферов, куда должны быть записаны командная строка и путь к исп. файлу, можно записывать произвольные данные во все участки памяти доступные ядру, а значит иметь полный доступ к системе и запускать код с привилегиями ядра.
2. Если в заголовке исполняемого файла указать некорректный размер требуемой приложением памяти (например больше 0x80000000), ядро упадёт, а при меньших размерах (меньших 0x80000000, но больших по всей видимости, чем доступная физическая память) упасть с undefined exception может либо само приложение, либо процесс, запускающий его, либо случайный процесс, либо несколько таких процессов.
1. Если в заголовке указать некорректные адреса для буферов, куда должны быть записаны командная строка и путь к исп. файлу, можно записывать произвольные данные во все участки памяти доступные ядру, а значит иметь полный доступ к системе и запускать код с привилегиями ядра.
2. Если в заголовке исполняемого файла указать некорректный размер требуемой приложением памяти (например больше 0x80000000), ядро упадёт, а при меньших размерах (меньших 0x80000000, но больших по всей видимости, чем доступная физическая память) упасть с undefined exception может либо само приложение, либо процесс, запускающий его, либо случайный процесс, либо несколько таких процессов.
Ещё одна уязвимость. Тоже критическая. Если в заголовке файла скина указать неправильные указатели params/buttons/bitmaps произойдёт kernel crash. В зависимости от адреса указателя ядро падает по-разному, но обычно с page fault. Если использовать правильные указатели можно читать память ядра и прочие системные данные.
Уязвимость (серьёзная, к сожалению) ядра при работе с форматом KPCK:
- Если в заголовке указать неправильный размер исходного файла (dword по смещению +4), произойдёт kernel crash
- Если повредить содержимое файла (т.е. всё, что идёт после заголовка), ядро также упадёт
Пожалуйста прикрепляйте файлы эксплуатирующие уязвимость. Так будет проще проверять исправлена ли она.Kenshin wrote:Уязвимость (серьёзная, к сожалению) ядра при работе с форматом KPCK:
- Если в заголовке указать неправильный размер исходного файла (dword по смещению +4), произойдёт kernel crash
- Если повредить содержимое файла (т.е. всё, что идёт после заголовка), ядро также упадёт
Изобретайте колёса каждый раз, когда хотите написать новую программу.
Ну вот, например, два эксплойта - сам kpack, запакованный самим собой, - в каждом из которых умышленно повреждён один (всего лишь) из байтов в начале файла (честно говоря, чёрт знает, где там кончается заголовок и начинаются данные, никакой документации по формату пока не попадалось):
https://habr.com/ru/company/kolibrios/b ... nt_8793311Kenshin wrote:честно говоря, чёрт знает, где там кончается заголовок и начинаются данные, никакой документации по формату пока не попадалось
The best way to predict the future is to create it.
Весьма полезная ссылка. Спасибо.
Fixed in rev 8593Kenshin wrote:Критическая уязвимость ядра при запуске программ. Заключается в использовании неправильных значений в заголовке исполнимого файла формата MENUET0x:
1. Если в заголовке указать некорректные адреса для буферов, куда должны быть записаны командная строка и путь к исп. файлу, можно записывать произвольные данные во все участки памяти доступные ядру, а значит иметь полный доступ к системе и запускать код с привилегиями ядра.
The best way to predict the future is to create it.
Круто, отличная работа! Теперь система стала чуточку надёжнееrgimad wrote:Fixed in rev 8593
![Smile :)](./images/smilies/icon_smile.gif)
rev 8598 : fixed vulnerabilities in sysfn 18.11 and 36, now user applications cannot corrupt kernel memory via invalid buffer address
rev 8599 : fixed same vulnerability in sysfn 48.3
rev 8599 : fixed same vulnerability in sysfn 48.3
The best way to predict the future is to create it.
уязвимость в 30 сисфункции подфункции 2
если указать вместо буфера адрес 0x80003000 ядро падает
часть кода вызвавшая проблему:
mov eax,30
mov ebx,2
mov ecx,0x80003000
mov edx,255
int 0x40
аналогичная уязвимость в 74 сисфункции
если указать вместо буфера адрес 0x80003000 ядро падает
часть кода вызвавшая проблему:
mov eax,30
mov ebx,2
mov ecx,0x80003000
mov edx,255
int 0x40
аналогичная уязвимость в 74 сисфункции
нашёл уязвимости в сисфункциях:
30.5 перезапись системной области памяти с последующим падением ядра
70.0 перезапись системной области памяти с последующим падением ядра
70.5 перезапись системной области памяти с последующим падением ядра
//Везде вместо указателя на буфер ставил 0x80003000
70.3 чтение системной области памяти и запись этого в файл
70.2 тоже самое
//Везде вместо указателя на буфер ставил 0x80003000
70.1 программа начинает сильно грузить процессор(на 100%), после её отключения система зависает намертво
54.2 запись в буфер обмена данных по адресу 0x80003000
//но при попытке получить указатель на эти данные программа падала
все данные по этому в беседе вк "KolibriOS чат", поиск по #БАГИ
30.5 перезапись системной области памяти с последующим падением ядра
70.0 перезапись системной области памяти с последующим падением ядра
70.5 перезапись системной области памяти с последующим падением ядра
//Везде вместо указателя на буфер ставил 0x80003000
70.3 чтение системной области памяти и запись этого в файл
70.2 тоже самое
//Везде вместо указателя на буфер ставил 0x80003000
70.1 программа начинает сильно грузить процессор(на 100%), после её отключения система зависает намертво
54.2 запись в буфер обмена данных по адресу 0x80003000
//но при попытке получить указатель на эти данные программа падала
все данные по этому в беседе вк "KolibriOS чат", поиск по #БАГИ
#8675 fixed vulnerability (reading kernel memory from userspace) in sysfn25
The best way to predict the future is to create it.
Who is online
Users browsing this forum: No registered users and 23 guests