Какие, если таковые имеются, уязвимости внедрения в bash и как я могу защититься от них? - PullRequest
Новая
       6

Какие, если таковые имеются, уязвимости внедрения в bash и как я могу защититься от них?

4 голосов
/ 03 января 2011

У меня есть скрипт bash, который я запускаю через procmail. Procmail передает в поле subject и из сообщения электронной почты в качестве аргументов сценария bash. Поскольку эти значения никак не анализируются, я пытаюсь выяснить, есть ли какие-либо уязвимости в bash, которыми кто-то может воспользоваться, и если да, то, что я могу сделать, чтобы защитить их. Вот пример кода, чтобы проиллюстрировать, что происходит: 

#!/bin/bash
/usr/sbin/sendmail -t <<EOF
From: "myhost Administrator" <admin@myhost.example.com>
To: john_doe@gmail.com
Subject: An email subject

You've received a new email.
It has a subject of "$2"
It was sent from "$1".
EOF

Этот сценарий bash будет вызываться procmail с помощью сценария .procmailrc, например: 

:0
* ^From:\s*\/.*
{
 FROM = "$MATCH"
}

:0
* ^Subject:\s*\/.*
{
 SUBJECT = "$MATCH"
}

:0 c:
* ^To:.*@example.com
| /home/john_doe/examplescript.bash "$FROM" "$SUBJECT"

Две области, для которых я задаюсь вопросом об уязвимостях внедрения, находятся в создании сценария: 

/home/john_doe/examplescript.bash "$FROM" "$SUBJECT"

и использование переменных в скрипте. 

/usr/sbin/sendmail -t <<EOF
From: "myhost Administrator" <admin@myhost.example.com>
To: john_doe@gmail.com
Subject: An email subject

You've received a new email.
It has a subject of "$2"
It was sent from "$1".
EOF

Если вам интересно, вот фактический вариант использования, который напомнил мне этот вопрос

Ответы [ 3 ]

0 голосов
/ 04 января 2011

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

Единственный способ, который я вижу в сценарии, это то, что кто-то может передать точку в одной строке, что приведет к преждевременному завершению письма. И может быть случай вложения вложений с использованием uuencode, например: 

Subject: subject
From: sender@example.com
To: receiver@example.com

text line 1
text line 2

begin 644 file-containing-abc
$86)C"G]_
`
end

Меня беспокоит строка в .procmailrc, так как я не знаю правил цитирования. Это может быть момент, когда злоумышленник может внедрить код, поэтому вам нужно посмотреть правила в руководстве и проверить их, чтобы убедиться в этом. Некоторые символы, которые вы должны проверить: $, ", \, переводы строки.

0 голосов
/ 04 января 2011

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

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

0 голосов
/ 04 января 2011

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

Установите флажки $1 и $2, чтобы убедиться, что они содержат только печатные символы и имеют разумную длину, например, менее 1000 символов, перед отправкой их в почтовую систему.

Это не так уж сложно сделать, и это предотвращает попадание вас от неизвестного эксплойта.

Одной из вещей, которые мне нравятся в Perl, является режим taint , который не позволяет вам делать подобные вещи, если вы сначала не очистили данные.

...