Qu'est-ce que, le cas échéant, les vulnérabilités d'injection sont là en bash et comment puis-je protéger contre eux?

Question

J'ai un script bash que je suis le coup d'envoi via procmail. Procmail passe dans le sujet et à partir d'un e-mail comme arguments au script bash. Étant donné que ces valeurs sont assainies en aucune façon, j'essaie de savoir s'il y a des vulnérabilités d'injection dans bash que quelqu'un pourrait tirer profit et si oui ce que je peux faire pour protéger contre ces derniers. Voici quelques exemples de code pour illustrer ce qui se passe:

#!/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

Ce script bash serait appelé par procmail avec un script .procmailrc comme ceci:

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

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

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

Les deux domaines que je me demande sur les vulnérabilités d'injection sont pour l'instanciation du script:

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

et l'utilisation des variables dans le script.

/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

Si votre curieux,

Était-ce utile?

Nous faire parvenir

La solution

Pour éviter les problèmes d'injection, vous pouvez aussi tout simplement conduit tous les messages à l'adresse que vous aimez dans un script qui lit le message hors de stdin et Parsis en mode natif sur les en-têtes qui vous intéressent.

Vous pouvez ensuite utiliser les bibliothèques disponibles dans le langage de script que vous avez choisi de parler SMTP sur votre serveur de messagerie en cours d'exécution au niveau local.

De cette façon, il n'y a pas de commande d'exécution, et il y a pas besoin de se soucier de l'entrée hygiénisées utilisés comme arguments à un programme.

Answer 1

Pour éviter les problèmes d'injection, vous pouvez aussi tout simplement conduit tous les messages à l'adresse que vous aimez dans un script qui lit le message hors de stdin et Parsis en mode natif sur les en-têtes qui vous intéressent.

Vous pouvez ensuite utiliser les bibliothèques disponibles dans le langage de script que vous avez choisi de parler SMTP sur votre serveur de messagerie en cours d'exécution au niveau local.

De cette façon, il n'y a pas de commande d'exécution, et il y a pas besoin de se soucier de l'entrée hygiénisées utilisés comme arguments à un programme.

Answer 2

Je ne suis pas un expert en sécurité, mais les vulnérabilités d'injection dans une entrée existe d'utilisateur non aseptisé - surtout si vous envoyez cette entrée premières aux commandes du système qui peuvent avoir un accès privilégié. Vérifiez toujours votre entrée avant de le faire.

Vérifiez $1 et $2 pour vous assurer qu'ils ne contiennent que des caractères imprimables et sont une longueur raisonnable, comme en 1000 caractères, avant de les envoyer à votre système de messagerie.

Ce n'est pas trop difficile à faire, et il vous empêche d'être frappé d'une certaine inconnue Exploita.

L'une des choses que je aime Perl est le taint mode qui vous empêche de faire des choses comme ça, sauf si vous avez nettoyé les données en premier.

Answer 3

Le script shell en lui-même est assez sûr. La plupart vulnérables d'un courrier est l'en-tête, et vous ne laissez pas l'expéditeur du courrier à quoi que ce soit de changement en elle.

La seule façon que je vois dans le script est que quelqu'un pourrait passer d'un point sur une seule ligne, ce qui mettrait fin à la poste prématurément. Et il peut y avoir le cas d'incorporation des pièces jointes à l'aide uuencode comme ceci:

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

Je suis inquiet au sujet de la ligne du .procmailrc, puisque je ne connais pas les règles de cotation. Cela pourrait être un point où un attaquant pourrait injecter du code, de sorte que vous devez rechercher les règles dans le manuel et les tester pour être sûr. Certains caractères que vous devez tester sont $, ", \, les nouvelles lignes.