Я просто не подумал об этом на тот момент. Краем глаза увидел, что единственный com.google.* свободный и приверил ещё парочку подозрительных, но целиком проверять не стал. В голове держал только то, что гугловых инструментов для сборки в F-Droid просто нет.
Хорошее замечание, перед окончательной упаковкой обязательно перепроверю.
Спасибо, полезно. Я успел обеспокоиться только о получении ключа на основании предсказуемого содержимого пейлода. К мусору надо ещё время добавить и проверять, чтобы исключить реплей-атаку.
Одного, поэтому ICMP-пакет и не требует тройного рукопожатия. Но для модуля ядра это не должно быть проблемой, TCP-пакет можно принять и обработать в любом виде, без установки полноценного соединения.
Кажется, что синхронная будет проще. Если есть примитивы для асинхронной, то можно и так. Мне кажется, есть возможность для атаки, команды отправляемые на сервер в критичной ситуации однообразны, мало энтропии в полезных данных, поэтому в идеале надо ещё и мусорную нагрузку добавлять.
Да, MTU, про него не думал. Если IP-пакет собирается ядром прежде чем попадёт в нетфильтр, то всё будет хорошо. Возможно, зависит от приоритета, надо проверять.
при следующем icmp echo отправьте его назад
Думаю, можно дропнуть этот пакет и потом скрафтить следующий, с соответствующими заголовками, чтобы клиент принял его за родной. Это усложнит сам модуль и потребует непредсказуемого с моим уровнем знаний времени на разработку. Идея всё же хорошая, спасибо.
Когда у меня на виртуалке заканчивается оперативная память вместе с буфером подкачки, то /bin/sh уже не открывается.
Подозреваю, что в этом случае и сама команда рискует не выполниться. Команда ведь всё же не в ядре выполняется, ядро запускает процесс в юзерспейсе. Пока я имел в виду только высокий LA, на случай нехватки памяти, проще будет добавить ключ sysrq:, который будет в обход юзерспейса триггерить нужный обработчик. Там есть и вызов OOM и убийство всех процессов кроме инита.
Проверил файндом, ничего не нашлось. Там лежат модули из пакета и из DKMS, а загружаемое простым insmod остаётся только в памяти. Заметно будет в выводе lsmod.
Сам ICMP-пакет по размерам не ограничен, но есть ограничения на IP-пакет, 65535 байт. Из этого вычитаем 20 байт на заголовок IP-пакета и 8 байт на заголовок ICMP-пакета, получается намного больше, чем моё ограничение.
Было бы интересно увидеть реализацию отправки «ответа» в icmp reply.
Думаю, что это технически невозможно. Как раз потому что ядро крашится, если ждать даже начала выполнения команды.
Будет ли оно работать когда уже свалился shh?
Конкретно это не проверял, /bin/sh никак не зависит от SSH-сервера. Кроме того, SSH работает по TCP, а в моём модуле TCP никак не затрагивается.
Если в хуке вызывать юзерспейс-программу не ожидая её выполнения, с аргументом UMH_NO_WAIT, то ничего не произойдёт. Думаю, что хук завершается вместе со всеми потомками. Если вызывать с UMH_WAIT_EXEC или UMH_WAIT_PROC, то ядро крашится.
Да, верно. Такая безопасность будет работать только через неясность. Я полагаю, что можно заменить прероутинг на построутинг и дать доступ только локальным IP-адресам. Возможно в этом случае до модуля не доберутся "марсианские" пакеты и подделка не будет работать.
Я просто не подумал об этом на тот момент. Краем глаза увидел, что единственный
com.google.*свободный и приверил ещё парочку подозрительных, но целиком проверять не стал. В голове держал только то, что гугловых инструментов для сборки в F-Droid просто нет.Хорошее замечание, перед окончательной упаковкой обязательно перепроверю.
Интересно. Мне всегда казалось, что
voidговорит о том, что никаких данных не подразумевается.Спасибо, полезно. Я успел обеспокоиться только о получении ключа на основании предсказуемого содержимого пейлода. К мусору надо ещё время добавить и проверять, чтобы исключить реплей-атаку.
Одного, поэтому ICMP-пакет и не требует тройного рукопожатия. Но для модуля ядра это не должно быть проблемой, TCP-пакет можно принять и обработать в любом виде, без установки полноценного соединения.
Точно, как-то я и не заметил подмены.
Кажется, что синхронная будет проще. Если есть примитивы для асинхронной, то можно и так. Мне кажется, есть возможность для атаки, команды отправляемые на сервер в критичной ситуации однообразны, мало энтропии в полезных данных, поэтому в идеале надо ещё и мусорную нагрузку добавлять.
Обязательно, спасибо! Про фрагментированные echo-пакеты я даже не знал.
Всяческое мошенничество. Меня заподозрили в том, что я пишу бэкдор для вредоносной деятельности.
В случае с ядром будет сходу kernel panic.
Интересно, спасибо. Подумаю над этим, когда чуть лучше изучу язык.
Я тестировал на удалённой. Повезло, но могло быть интересней.
Не понимаю проблему, я даже в C не специалист.
cmd_stringможет перезаписываться разными ICMP-пакетами?У меня до виртуалки ничего не подменялось. Есть сведения о железках, которые точно так делают?
Да, MTU, про него не думал. Если IP-пакет собирается ядром прежде чем попадёт в нетфильтр, то всё будет хорошо. Возможно, зависит от приоритета, надо проверять.
Думаю, можно дропнуть этот пакет и потом скрафтить следующий, с соответствующими заголовками, чтобы клиент принял его за родной. Это усложнит сам модуль и потребует непредсказуемого с моим уровнем знаний времени на разработку. Идея всё же хорошая, спасибо.
Подозреваю, что в этом случае и сама команда рискует не выполниться. Команда ведь всё же не в ядре выполняется, ядро запускает процесс в юзерспейсе. Пока я имел в виду только высокий LA, на случай нехватки памяти, проще будет добавить ключ
sysrq:, который будет в обход юзерспейса триггерить нужный обработчик. Там есть и вызов OOM и убийство всех процессов кроме инита.Проверил файндом, ничего не нашлось. Там лежат модули из пакета и из DKMS, а загружаемое простым
insmodостаётся только в памяти. Заметно будет в выводеlsmod.Сам ICMP-пакет по размерам не ограничен, но есть ограничения на IP-пакет, 65535 байт. Из этого вычитаем 20 байт на заголовок IP-пакета и 8 байт на заголовок ICMP-пакета, получается намного больше, чем моё ограничение.
Думаю, что это технически невозможно. Как раз потому что ядро крашится, если ждать даже начала выполнения команды.
Конкретно это не проверял,
/bin/shникак не зависит от SSH-сервера. Кроме того, SSH работает по TCP, а в моём модуле TCP никак не затрагивается.Должна. Фунцкия с запуском будет уже поставлена в очередь планировщика, но клиентская часть точно зависнет, потом учто ожидает ответного пакета.
Гирлянда была отвлекающим манёвром? В дискорде мигание приняли за модуляцию, морзянку какую-нибудь.
Если в хуке вызывать юзерспейс-программу не ожидая её выполнения, с аргументом
UMH_NO_WAIT, то ничего не произойдёт. Думаю, что хук завершается вместе со всеми потомками. Если вызывать сUMH_WAIT_EXECилиUMH_WAIT_PROC, то ядро крашится.Да, верно. Такая безопасность будет работать только через неясность. Я полагаю, что можно заменить прероутинг на построутинг и дать доступ только локальным IP-адресам. Возможно в этом случае до модуля не доберутся "марсианские" пакеты и подделка не будет работать.