Was, wenn überhaupt, Injektionsschwachstellen gibt es in bash und wie kann ich vor ihnen schützen?

Question

Ich habe ein Bash-Skript, das ich über procmail starte. Procmail geht im Thema und aus Feld aus einer E-Mail als Argument für den Bash-Skript. Da diese Werte in keiner Weise unmanipuliert sind, versuche ich herauszufinden, ob es in der bash irgendwelche Sicherheitslücken gibt, die jemand ausnutzen könnte, und wenn ja, was ich dagegen tun kann. Hier ist ein Beispielcode zu veranschaulichen, was los ist:

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

Dieses Bash-Skript würde durch procmail mit einem .procmailrc Skript wie folgt aufgerufen werden:

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

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

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

Die beiden Bereiche, die ich frage mich, über Injection-Schwachstellen für in der Instanziierung des Skripts:

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

und die Verwendung der Variablen im Skript.

/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 

Wenn Ihr neugierig, here is the actual use case that brought this question to my mind

Answer 1

Um die Probleme der Injektion zu vermeiden, könnten Sie auch alle Nachrichten an die Adresse, die Sie interessieren, über ein Skript, das die Nachricht aus stdin liest und nativ analysiert die Header, die Sie interessieren.

Sie könnten dann Bibliotheken in der Skriptsprache von Ihnen gewählten SMTP auf Ihren lokal laufenden Mail-Server zu sprechen.

Auf diese Weise gibt es keine Befehlsausführung, und Sie müssen sich keine Sorgen darüber machen, dass unsanitisierte Eingaben als Argumente für ein Programm verwendet werden.

Answer 2

Ich bin kein Sicherheitsexperte, aber Injection-Schwachstellen existieren in jedem Nicht-hygienisiert Benutzereingaben - vor allem, wenn Sie senden, dass rohe Eingabe an System-Befehle, kann privilegierten Zugang haben. Überprüfen Sie Ihre Eingabe immer, bevor Sie das tun.

Überprüfen Sie $1 und $2, um sicherzustellen, dass sie nur druckbare Zeichen enthalten und eine angemessene Länge von weniger als 1000 Zeichen aufweisen, bevor Sie sie an Ihr Mailsystem senden.

Das ist nicht zu schwierig ist, zu tun, und es verhindert, dass Sie von einem unbekannten getroffen zu nutzen.

Eines der Dinge, die ich an Perl mag, ist die Taint-Modus, die Sie davon abhält, solche Dinge zu tun, wenn Sie die Daten zuerst bereinigt haben.

Answer 3

Das Shell-Skript an sich ist ziemlich sicher. Der am meisten gefährdete Teil einer Mail ist der Header, und Sie erlauben dem Mail-Absender nicht, etwas darin zu ändern.

Die einzige Art, wie ich im Skript sehen ist, dass jemand einen Punkt auf einer einzigen Linie passieren könnte, die die E-Mail vorzeitig beenden würde. Und es kann der Fall sein, Anhänge der Einbettung wie dies mit 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 

Ich mache mir Sorgen um die Linie in der .procmailrc, da ich die zitierte Regeln nicht kennen. Dies könnte ein Punkt sein, an dem ein Angreifer Code injizieren könnte. Daher müssen Sie die Regeln im Handbuch nachschlagen und sie testen, um sicher zu gehen. Einige Zeichen, die Sie testen sollten, sind $, ", \, Zeilenumbrüche.