Board.KolibriOS.org

Нет. Займёшься?

CleverMouse wrote:Нет. Займёшься?

Я и не прочь. Первую уязвимость я уже исправлял после того, как её обнаружил (года полтора назад). Решение было простым: каждый раз при записи файла на ram-диск ядро проверяло не установлен ли флаг защиты файла ядра, которая по умолчанию была включена и отключить её можно было в синем загрузочном меню системы. Если флаг был сброшен ядро продолжало запись обычным образом, в противном же случае ядро проверяло имя файла в который программа хотела записать и если оно соответствовало kernel.mnt, то ядро ничего не писало и возвращало ошибку фс ОТКАЗ В ДОСТУПЕ (код не помню). Таким образом защита работала почти безупречно и её можно было всегда отключить, если пользователю нужно было, например, перезаписать файл ядра. Эти изменения я не стал вносить в транк, так как посчитал свою реализацию костылем.

Что, если программа пишет не в файл kernel.mnt, а в файл demos/../kernel.mnt?
Что, если программа создаёт два потока, в одном потоке вызывает функцию записи, передавая имя lernel.mnt, в другом потоке параллельно модифицирует первую букву на k? Если проделать такое в цикле достаточно много раз, то на какой-то итерации проверка увидит старое имя lernel.mnt и пропустит дальше, а процесс записи увидит уже новое имя kernel.mnt и запишет туда.
Что, если программа не гордая и вполне удовольствуется записью в какой-то из драйверов, подгружаемых при загрузке системы?
Такие вопросы решаются системой разделения прав. Для Колибри пока никто такой не написал.

Логин/пароль на svn напомнить?

Многие проблемы решились бы разделением прав. Для этого нужно решить бюрократические вопросы: как хранить информацию о пользователях, и какие именно права возможны и необходимы. Верно?

Все почему-то скромно умалчивают про самый главный вопрос - где найти достаточно упоротого программиста готового взяться за этот адский рефакторинг?

Прежде чем фейсконтроль вводить надо дыры в заборе заделать.

Прежде чем дыры в заборе заделывать, нужно этот забор построить.

Обожаю, когда пишут афоризмами

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.

В ревизии #8246 устранена уязвимость системной функции 9 .
In revision #8246 fixed vulnerability in sysfn 9 .

Bug in subfunction 4 of system call 69. You can stop the system process thereby freezing the entire system!

superturbocat2001 wrote:Bug in subfunction 4 of system call 69. You can stop the system process thereby freezing the entire system!

Fixed in revision #8534. Please testing, including 'stop' command in mtdbg (which makes a system call 69.4).

Now I will check and unsubscribe

Coldy wrote:

superturbocat2001 wrote:Bug in subfunction 4 of system call 69. You can stop the system process thereby freezing the entire system!

Fixed in revision #8534. Please testing, including 'stop' command in mtdbg (which makes a system call 69.4).

You didn’t fix but broke the freezing function altogether. Now neither user applications nor system applications are frozen!