Угроза безопасности со сценариями та запись к/sys/class

Question 1

Я искал способ заставить специальные ключи моего ноутбука работать с i3-wm. Я столкнулся с этим сообщением и использовал сценарий там для создания моего собственного.

Это - то, что я придумал для яркости экрана (на моей машине, допустимые значения, кажется, между 0 и 937 - что-либо еще дает ошибку при записи):

#!/bin/bash
#
# Usage:  lcd_bright.sh <U|D> <value>
#

MODE=`echo $1 | tr '[a-z]' '[A-Z]'`
BRIGHTNESS='/sys/class/backlight/intel_backlight/brightness'
LCDVALUE=`cat $BRIGHTNESS`

if [ "$MODE" = "U" ]
then
  NEWVALUE=$(( $LCDVALUE + $2 ))
  if [ $NEWVALUE -le 937 ]
  then
      echo $NEWVALUE > $BRIGHTNESS
  else
      echo 937 > $BRIGHTNESS
  fi
else
  NEWVALUE=$(( $LCDVALUE - $2 ))
  if [ $NEWVALUE -ge 0 ]
  then
      echo $NEWVALUE > $BRIGHTNESS
  else
      echo 0 > $BRIGHTNESS
  fi
fi

И для подсветки клавиатуры (это имеет 4 уровня):

#!/bin/bash
#
# Usage:  kbd_bright.sh <U|D>

MODE=`echo $1 | tr '[a-z]' '[A-Z]'`
BRIGHTNESS='/sys/class/leds/asus::kbd_backlight/brightness'
KBDVALUE=`cat $BRIGHTNESS`

if [ "$MODE" = "U" ]
then
  NEWVALUE=$(( $KBDVALUE + 1 ))
  if [ $NEWVALUE -le 3 ]
  then
      echo $NEWVALUE > $BRIGHTNESS
  else
      echo 3 > $BRIGHTNESS
  fi
else
  NEWVALUE=$(( $KBDVALUE - 1 ))
  if [ $NEWVALUE -ge 0 ]
  then
      echo $NEWVALUE > $BRIGHTNESS
  else
      echo 0 > $BRIGHTNESS
  fi
fi

Я включил правила sudoers.d/ таким образом, сценарии не требуют пароля, и сценарии принадлежат root и установите полномочия на 0754.

Моя i3 конфигурация для них следующие:

# screen brightness control
bindsym XF86MonBrightnessUp exec sudo /home/ioana/.config/i3/lcd_bright.sh U 100
bindsym XF86MonBrightnessDown exec sudo /home/ioana/.config/i3/lcd_bright.sh D 100

# keyboard brightness control
bindsym XF86KbdBrightnessUp exec sudo /home/ioana/.config/i3/kbd_bright.sh U
bindsym XF86KbdBrightnessDown exec sudo /home/ioana/.config/i3/kbd_bright.sh D

При выполнении этого я видел, что кто-то упомянул, что такие сценарии излагают угрозу безопасности, особенно если они используют вход (который мои делают). Я хотел бы знать больше о том, что определенные угрозы безопасности на самом деле с моими сценариями и что они подразумевают.

Question 2

Существует несколько способов значительно уменьшить поверхность атаки Ваших сценариев. Обратите внимание, что я не эксперт по Bash, таким образом, это не исчерпывающий список проблем, всего несколько проблем I видят с Вашим существующим кодом.

Обработайте ошибки и неожиданные исходные данные и условия! Ваш код предполагает, что все будет работать как запланировано.
Не требуйте или обращайте внимание на ввод данных пользователем, если можно избежать его. Можно сделать это легко путем создания двух сценариев для яркости клавиатуры (например, kbd_brighter и kbd_dimmer). Можно также сделать два сценария, чтобы повысить и понизить жидкокристаллическую яркость на 100.
Сделайте проверку работоспособности на /sys файл прежде, чем записать в него. Это существует? Это содержит только единственное целое число? Что мы должны сделать, если то целое число неожиданно является отрицательным целым числом? Обработайте все возможные случаи правильно.
Всегда помещайте двойные кавычки вокруг любых выражений с переменной в них для предотвращения проблем с переменными, заполненными пустой строкой ([ $1 -eq 5 ] становление [ -eq 5 ] просто напрашивается на неприятности) и гарантировать, что переменные, содержащие специальные символы как пробелы или новые строки, обрабатываются правильно.
Используйте полный путь для команд для предотвращения PATH нападения. Например, /bin/cat вместо cat. Вы видите путь с type cat.
Используйте функции Bash вместо внешних команд. Например, VARIABLE=`< filename` вместо VARIABLE=`cat filename`. Кроме того, используйте echo вместо /bin/echo использовать встроенный Bash echo команда. Вы видите, что встроенная команда доступна с type echo.
Разделите логику модификации от пишущей файл логики, чтобы избежать необходимости осматривать несколько местоположений для пишущих файл ошибок, особенно при внесении изменений в файл.

При подведении, вот пример kbd_brighter сценарий. Обратите внимание, что я не протестировал его, так как у меня нет Asus. Это могло бы также все еще иметь проблемы безопасности, так как я не эксперт.

#!/bin/bash

BRIGHTNESS_FILE="/sys/class/leds/asus::kbd_backlight/brightness"

if [ ! -e "$BRIGHTNESS_FILE" ]; then
    >&2 echo 'ERROR: Asus keyboard backlight brightness file not found.'
    exit 1
fi

BRIGHTNESS="$( < "$BRIGHTNESS_FILE" )"

if [ "$BRIGHTNESS" -eq "$BRIGHTNESS" ] 2>/dev/null; then
    if [ "$BRIGHTNESS" -lt "1" ]; then
        BRIGHTNESS="1"
    elif [ "$BRIGHTNESS" -lt "3" ]; then
        BRIGHTNESS="$(( "$BRIGHTNESS" + 1 ))"
    else
        BRIGHTNESS="3"
    fi
else
    >&2 echo 'ERROR: Asus keyboard backlight brightness is not an integer.'
    exit 1
fi

echo "$BRIGHTNESS" > "$BRIGHTNESS_FILE"

Question 3

Question 4

Что на самом деле было сказано, и его значение

Цитата из Связанного поста :

Установите права доступа 755, принадлежащие пользователю root. Затем либо отредактируйте файл sudoers, чтобы он мог запускаться от имени пользователя root, либо используйте chmod + s, чтобы установить их SUID.

Такого рода вещи считаются угрозой безопасности, кстати, поэтому убедитесь, что права доступа установлены правильно.

Это говорит о двух случаях:

установочный скрипт и позволяет запускать его как root без запроса пароля

установка SUID немного о скриптах

В чем проблема со скриптами в целом? Перефразируя ответ Стефана Чазелаза (который я настоятельно рекомендую прочитать), сценарии оболочки могут быть проблемой, если они запускаются либо на веб-серверах, либо когда привилегированный сценарий выполняет что-то еще. Для обычного пользователя, у которого только есть рабочий стол - это означает, что в большинстве случаев разрушенная система - возможно, злоумышленник куда-то ввел rm -rf / - или компьютер перегружен вредоносным ПО и является частью ботнета для атаки на коммерческие серверы. Но для коммерческих серверов это может означать что угодно - от кражи информации с кредитных карт клиента до разрушения систем, что приводит к потере денег из-за того, что система не работает, а клиенты уходят куда-то еще. Поэтому, когда что-то считается проблемой безопасности, вам нужно знать, что это значит для вас. Вы также должны знать, кто может быть вашим возможным злоумышленником - это определяет, какой подход они могут использовать для взлома вашей системы, и для тех, кто интересуется информацией о вашей кредитной карте или беседой с людьми, они, скорее всего, будут использовать сетевой трафик, а не сценарий, что означает, что они, скорее всего, пойдут с атакой MITM, а не сценарием.

В чем может быть проблема в вашем конкретном случае?

Ваш скрипт выполняет 3 команды: echo $1 | tr и cat. Если злоумышленник заменяет cat или tr вредоносными программами, это может означать либо разрушение системы, либо утечку информации при каждом выполнении этих команд. А поскольку ваш сценарий запускается с привилегиями корневого уровня, эти команды также запускаются с привилегиями корневого уровня. Поскольку echo является встроенной оболочкой, она защищена от атак, когда заменяется /bin/echo (если вы не запустите env echo вместо этого - это вызовет /bin/echo). Возможно, если у вас есть кто-то, способный заменить двоичные файлы системного уровня, это означает, что они уже имеют root-доступ, что является более важной проблемой, чем просто ваш скрипт.

Скрипты живут в /home/ioana/.config/i3/ с разрешениями 0754. ОК, хорошо. Если ваша учетная запись взломана, злоумышленнику не нужен root - он будет использовать вашу учетную запись для перезаписи содержимого сценария. Как насчет разрешений каталога /home/ioana/.config/i3/? Удаление файла требует наличия разрешений на запись в каталог, в котором находится файл, поэтому, если у вас есть другой пользователь в вашей системе, и у него нет разрешений на запись в самом сценарии, если у них есть разрешения для записи в каталог, они могут удалить сценарий (не совсем проблема безопасности, но мини-DoS для кораблей и хихиканья).

Другая проблема в теории может быть связана с параметрами командной строки. У вас есть echo $1 | tr '[a-z]' '[A-Z]'. Скажем, злоумышленник использует /*/*/*/*/../../../../*/*/*/*/../../../../*/*/*/* как $1, упомянутый в ответе Стефана. Оболочке нужно будет конвертировать эти * в реальные файлы, и все эти расширения дороги для процессора. Это небольшой способ заставить ваш компьютер зависать, опять же, мини-DoS.

Если вы используете устаревшую версию bash, она может быть уязвима для произвольного внедрения кода через экспортные функции - aka shellsock . Таким образом, можно выполнить экспорт вредоносной функции перед запуском вашего сценария prvileged.

Если злоумышленник любит жестокое обращение с животными, он может злоупотреблять cat

Конечно, все эти вещи могут быть объединены с 1116], чтобы загрузить что-то еще, что является вредоносным, на ваш компьютер и выполнить с правами суперпользователя.

В конце концов, тот факт, что вы работаете с каталогом /sys/class/, не является проблемой. Проблема заключается в уровне возможностей сценариев оболочки и в том, что в сценариях оболочки есть механизмы, которые не идеальны. Но давайте не будем чрезмерно параноидальными. Как я уже сказал, если кто-то получил доступ к вашей учетной записи (которая имеет sudo привилегии) или учетной записи root - этого уже достаточно.

См. Также

Почему SUID отключен для сценариев оболочки, но не для двоичных файлов?

Chai T. Rex · Accepted Answer · 27 October 2019 в 10:14

Существует несколько способов значительно уменьшить поверхность атаки Ваших сценариев. Обратите внимание, что я не эксперт по Bash, таким образом, это не исчерпывающий список проблем, всего несколько проблем I видят с Вашим существующим кодом.

Обработайте ошибки и неожиданные исходные данные и условия! Ваш код предполагает, что все будет работать как запланировано.
Не требуйте или обращайте внимание на ввод данных пользователем, если можно избежать его. Можно сделать это легко путем создания двух сценариев для яркости клавиатуры (например, kbd_brighter и kbd_dimmer). Можно также сделать два сценария, чтобы повысить и понизить жидкокристаллическую яркость на 100.
Сделайте проверку работоспособности на /sys файл прежде, чем записать в него. Это существует? Это содержит только единственное целое число? Что мы должны сделать, если то целое число неожиданно является отрицательным целым числом? Обработайте все возможные случаи правильно.
Всегда помещайте двойные кавычки вокруг любых выражений с переменной в них для предотвращения проблем с переменными, заполненными пустой строкой ([ $1 -eq 5 ] становление [ -eq 5 ] просто напрашивается на неприятности) и гарантировать, что переменные, содержащие специальные символы как пробелы или новые строки, обрабатываются правильно.
Используйте полный путь для команд для предотвращения PATH нападения. Например, /bin/cat вместо cat. Вы видите путь с type cat.
Используйте функции Bash вместо внешних команд. Например, VARIABLE=`< filename` вместо VARIABLE=`cat filename`. Кроме того, используйте echo вместо /bin/echo использовать встроенный Bash echo команда. Вы видите, что встроенная команда доступна с type echo.
Разделите логику модификации от пишущей файл логики, чтобы избежать необходимости осматривать несколько местоположений для пишущих файл ошибок, особенно при внесении изменений в файл.

При подведении, вот пример kbd_brighter сценарий. Обратите внимание, что я не протестировал его, так как у меня нет Asus. Это могло бы также все еще иметь проблемы безопасности, так как я не эксперт.

#!/bin/bash

BRIGHTNESS_FILE="/sys/class/leds/asus::kbd_backlight/brightness"

if [ ! -e "$BRIGHTNESS_FILE" ]; then
    >&2 echo 'ERROR: Asus keyboard backlight brightness file not found.'
    exit 1
fi

BRIGHTNESS="$( < "$BRIGHTNESS_FILE" )"

if [ "$BRIGHTNESS" -eq "$BRIGHTNESS" ] 2>/dev/null; then
    if [ "$BRIGHTNESS" -lt "1" ]; then
        BRIGHTNESS="1"
    elif [ "$BRIGHTNESS" -lt "3" ]; then
        BRIGHTNESS="$(( "$BRIGHTNESS" + 1 ))"
    else
        BRIGHTNESS="3"
    fi
else
    >&2 echo 'ERROR: Asus keyboard backlight brightness is not an integer.'
    exit 1
fi

echo "$BRIGHTNESS" > "$BRIGHTNESS_FILE"

Sergiy Kolodyazhnyy · Answer 2 · 27 October 2019 в 10:14

Что на самом деле было сказано, и его значение

Цитата из Связанного поста :

Установите права доступа 755, принадлежащие пользователю root. Затем либо отредактируйте файл sudoers, чтобы он мог запускаться от имени пользователя root, либо используйте chmod + s, чтобы установить их SUID.

Такого рода вещи считаются угрозой безопасности, кстати, поэтому убедитесь, что права доступа установлены правильно.

Это говорит о двух случаях:

установочный скрипт и позволяет запускать его как root без запроса пароля

установка SUID немного о скриптах

В чем проблема со скриптами в целом? Перефразируя ответ Стефана Чазелаза (который я настоятельно рекомендую прочитать), сценарии оболочки могут быть проблемой, если они запускаются либо на веб-серверах, либо когда привилегированный сценарий выполняет что-то еще. Для обычного пользователя, у которого только есть рабочий стол - это означает, что в большинстве случаев разрушенная система - возможно, злоумышленник куда-то ввел rm -rf / - или компьютер перегружен вредоносным ПО и является частью ботнета для атаки на коммерческие серверы. Но для коммерческих серверов это может означать что угодно - от кражи информации с кредитных карт клиента до разрушения систем, что приводит к потере денег из-за того, что система не работает, а клиенты уходят куда-то еще. Поэтому, когда что-то считается проблемой безопасности, вам нужно знать, что это значит для вас. Вы также должны знать, кто может быть вашим возможным злоумышленником - это определяет, какой подход они могут использовать для взлома вашей системы, и для тех, кто интересуется информацией о вашей кредитной карте или беседой с людьми, они, скорее всего, будут использовать сетевой трафик, а не сценарий, что означает, что они, скорее всего, пойдут с атакой MITM, а не сценарием.

В чем может быть проблема в вашем конкретном случае?

Ваш скрипт выполняет 3 команды: echo $1 | tr и cat. Если злоумышленник заменяет cat или tr вредоносными программами, это может означать либо разрушение системы, либо утечку информации при каждом выполнении этих команд. А поскольку ваш сценарий запускается с привилегиями корневого уровня, эти команды также запускаются с привилегиями корневого уровня. Поскольку echo является встроенной оболочкой, она защищена от атак, когда заменяется /bin/echo (если вы не запустите env echo вместо этого - это вызовет /bin/echo). Возможно, если у вас есть кто-то, способный заменить двоичные файлы системного уровня, это означает, что они уже имеют root-доступ, что является более важной проблемой, чем просто ваш скрипт.

Скрипты живут в /home/ioana/.config/i3/ с разрешениями 0754. ОК, хорошо. Если ваша учетная запись взломана, злоумышленнику не нужен root - он будет использовать вашу учетную запись для перезаписи содержимого сценария. Как насчет разрешений каталога /home/ioana/.config/i3/? Удаление файла требует наличия разрешений на запись в каталог, в котором находится файл, поэтому, если у вас есть другой пользователь в вашей системе, и у него нет разрешений на запись в самом сценарии, если у них есть разрешения для записи в каталог, они могут удалить сценарий (не совсем проблема безопасности, но мини-DoS для кораблей и хихиканья).

Другая проблема в теории может быть связана с параметрами командной строки. У вас есть echo $1 | tr '[a-z]' '[A-Z]'. Скажем, злоумышленник использует /*/*/*/*/../../../../*/*/*/*/../../../../*/*/*/* как $1, упомянутый в ответе Стефана. Оболочке нужно будет конвертировать эти * в реальные файлы, и все эти расширения дороги для процессора. Это небольшой способ заставить ваш компьютер зависать, опять же, мини-DoS.

Если вы используете устаревшую версию bash, она может быть уязвима для произвольного внедрения кода через экспортные функции - aka shellsock . Таким образом, можно выполнить экспорт вредоносной функции перед запуском вашего сценария prvileged.

Если злоумышленник любит жестокое обращение с животными, он может злоупотреблять cat

Конечно, все эти вещи могут быть объединены с 1116], чтобы загрузить что-то еще, что является вредоносным, на ваш компьютер и выполнить с правами суперпользователя.

В конце концов, тот факт, что вы работаете с каталогом /sys/class/, не является проблемой. Проблема заключается в уровне возможностей сценариев оболочки и в том, что в сценариях оболочки есть механизмы, которые не идеальны. Но давайте не будем чрезмерно параноидальными. Как я уже сказал, если кто-то получил доступ к вашей учетной записи (которая имеет sudo привилегии) или учетной записи root - этого уже достаточно.

См. Также

Почему SUID отключен для сценариев оболочки, но не для двоичных файлов?

Угроза безопасности со сценариями та запись к/sys/class

2 ответа

Что на самом деле было сказано, и его значение

См. Также

Другие вопросы по тегам:

Похожие вопросы: