Уязвимости ядра
-
Нет. Займёшься?Сделаем мир лучше!
Я и не прочь. Первую уязвимость я уже исправлял после того, как её обнаружил (года полтора назад). Решение было простым: каждый раз при записи файла на ram-диск ядро проверяло не установлен ли флаг защиты файла ядра, которая по умолчанию была включена и отключить её можно было в синем загрузочном меню системы. Если флаг был сброшен ядро продолжало запись обычным образом, в противном же случае ядро проверяло имя файла в который программа хотела записать и если оно соответствовало kernel.mnt, то ядро ничего не писало и возвращало ошибку фс ОТКАЗ В ДОСТУПЕ (код не помню). Таким образом защита работала почти безупречно и её можно было всегда отключить, если пользователю нужно было, например, перезаписать файл ядра. Эти изменения я не стал вносить в транк, так как посчитал свою реализацию костылем.CleverMouse wrote:Нет. Займёшься?
Что, если программа пишет не в файл kernel.mnt, а в файл demos/../kernel.mnt?
Что, если программа создаёт два потока, в одном потоке вызывает функцию записи, передавая имя lernel.mnt, в другом потоке параллельно модифицирует первую букву на k? Если проделать такое в цикле достаточно много раз, то на какой-то итерации проверка увидит старое имя lernel.mnt и пропустит дальше, а процесс записи увидит уже новое имя kernel.mnt и запишет туда.
Что, если программа не гордая и вполне удовольствуется записью в какой-то из драйверов, подгружаемых при загрузке системы?
Такие вопросы решаются системой разделения прав. Для Колибри пока никто такой не написал.
Логин/пароль на svn напомнить?
Что, если программа создаёт два потока, в одном потоке вызывает функцию записи, передавая имя lernel.mnt, в другом потоке параллельно модифицирует первую букву на k? Если проделать такое в цикле достаточно много раз, то на какой-то итерации проверка увидит старое имя lernel.mnt и пропустит дальше, а процесс записи увидит уже новое имя kernel.mnt и запишет туда.
Что, если программа не гордая и вполне удовольствуется записью в какой-то из драйверов, подгружаемых при загрузке системы?
Такие вопросы решаются системой разделения прав. Для Колибри пока никто такой не написал.
Логин/пароль на svn напомнить?
Сделаем мир лучше!
Многие проблемы решились бы разделением прав. Для этого нужно решить бюрократические вопросы: как хранить информацию о пользователях, и какие именно права возможны и необходимы. Верно?
Все почему-то скромно умалчивают про самый главный вопрос - где найти достаточно упоротого программиста готового взяться за этот адский рефакторинг?
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Прежде чем фейсконтроль вводить надо дыры в заборе заделать.
Прежде чем дыры в заборе заделывать, нужно этот забор построить.
Сделаем мир лучше!
Обожаю, когда пишут афоризмами
Из хаоса в космос
К сожалению исходники этой фигни умерли (как и все мои проекты/исходники и файлы), в тот момент когда меня долгое время не было дома. Так что если делать, то нужно будет писать всё с нуля. Вторая проблема: у меня сейчас нет под рукой ПК, но как только эта проблема исчезнет, то я буду готов начать работу.CleverMouse wrote:Что, если программа пишет не в файл kernel.mnt, а в файл demos/../kernel.mnt?
Что, если программа создаёт два потока, в одном потоке вызывает функцию записи, передавая имя lernel.mnt, в другом потоке параллельно модифицирует первую букву на k? Если проделать такое в цикле достаточно много раз, то на какой-то итерации проверка увидит старое имя lernel.mnt и пропустит дальше, а процесс записи увидит уже новое имя kernel.mnt и запишет туда.
Что, если программа не гордая и вполне удовольствуется записью в какой-то из драйверов, подгружаемых при загрузке системы?
Такие вопросы решаются системой разделения прав. Для Колибри пока никто такой не написал.
Логин/пароль на svn напомнить?
Ни логина, ни пароля старых мне не нужно, спасибо, ибо Nasarus больше не существует, а вот от нового аккаунта на свн я бы не стал отказываться, но опять же я сейчас им воспользоваться не смогу.
В ревизииях #8160 и #8216 уязвимость системной функции 26.2, которую эксплуатировал 2nd.kex, окончательно устранена.
In revisions #8160 and #8216 vulnerability in sysfn 26.2 (2nd.kex used it) finally fixed.
In revisions #8160 and #8216 vulnerability in sysfn 26.2 (2nd.kex used it) finally fixed.
Last edited by rgimad on Mon Nov 23, 2020 10:18 pm, edited 2 times in total.
The best way to predict the future is to create it.
В ревизии #8246 устранена уязвимость системной функции 9 .
In revision #8246 fixed vulnerability in sysfn 9 .
In revision #8246 fixed vulnerability in sysfn 9 .
The best way to predict the future is to create it.
Bug in subfunction 4 of system call 69. You can stop the system process thereby freezing the entire system!
- Attachments
-
-
exploit.kex (53 Bytes)Downloaded 253 times
-
exploit.asm (211 Bytes)Downloaded 255 times
-
Изобретайте колёса каждый раз, когда хотите написать новую программу.
Fixed in revision #8534. Please testing, including 'stop' command in mtdbg (which makes a system call 69.4).superturbocat2001 wrote:Bug in subfunction 4 of system call 69. You can stop the system process thereby freezing the entire system!
Now I will check and unsubscribe
Изобретайте колёса каждый раз, когда хотите написать новую программу.
You didn’t fix but broke the freezing function altogether. Now neither user applications nor system applications are frozen!Coldy wrote:Fixed in revision #8534. Please testing, including 'stop' command in mtdbg (which makes a system call 69.4).superturbocat2001 wrote:Bug in subfunction 4 of system call 69. You can stop the system process thereby freezing the entire system!
Изобретайте колёса каждый раз, когда хотите написать новую программу.
Who is online
Users browsing this forum: No registered users and 2 guests