Ralph Aichinger <ralph@pi.h5.or.at> wrote:

Hallo alle, kann man folgendes machen:

https://pi.h5.or.at/mockturtle.txt

ist ein Python-Skript mittels des Moduls "cmd", das ein CLI implementiert, quasi ohne sinnvolle Funktion einstweilen ;)

Ich habe dieses Skript in /etc/shells eingetragen, und als Login-Shell eines Users "admin".

In /etc/ssh/sshd_config habe ich folgende Zeilen eingefügt:

Match User admin X11Forwarding no AllowTcpForwarding no ForceCommand /usr/local/bin/turtle

(das Skript hab ich "turtle" genannt nach dem Beispielskript von cmd, von dem es abgewandelt wurde)

Wer mag und IPv6 hat, kann es ausprobieren:

ssh -l admin probe.aisg.at password: admin

Kann man sowas machen, ein Python-Skript als Login-Shell verwenden, oder ist man da einen Schritt vor dem Gehackt werden? Irgendwelche offensichtlichen Probleme mit meinem oben verlinkten Skript, vor allem bezüglich Sicherheit? Auf den ersten Blick kommt es mir sicher vor. Ich habe keine offensichtliche Möglichkeit gefunden, auszubrechen. IMO wäre allerdings eine chroot Umgebung bzgl. der Sicherheit noch günstiger. https://www.tecmint.com/restrict-ssh-user-to-directory-using-chrooted-jail/ zeigt die notwendigen Schritte. Da die Thematik nicht Python spezifisch ist, wäre eine Anfrage in einer Linux Group evtl. zielführender.

-- Dipl.-Inform(FH) Peter Heitzer, peter.heitzer@rz.uni-regensburg.de

On 2024-02-19 11:49, Ralph Aichinger wrote:

https://pi.h5.or.at/mockturtle.txt

ist ein Python-Skript mittels des Moduls "cmd", das ein CLI implementiert, quasi ohne sinnvolle Funktion einstweilen ;) [...]

Ich bin kein IT-Security-Experte, aber ein paar Gedanken dazu: - Was passiert, wenn jemand eine Eingabezeile von einigen GB schickt? Ich vermute mal, das würde auf einen DoS hinauslaufen. - Davon abgesehen, ist mir wie Peter auch nichts an deinem Code aufgefallen, womit man aus deiner Shell ausbrechen könnte. - Man kann das mit dem Chroot noch weiter treiben und den Shell-Prozess in einen Podman- oder Docker-Container oder eine VM einsperren. Auf der anderen Seite beziehungsweise zusätzlich kannst du die Rechte des Users möglichst weitgehend einschränken durch entsprechende Wahl der User-Id, Gruppen und gegebenenfalls SELinux/AppArmor-Policy. - Laut https://docs.python.org/3/library/cmd.html verwendet das Modul für die Verarbeitungen der Eingabezeile die readline-Bibliothek. Je nachdem, welche Konfigurations-Einstellungen (z. B. in der `.inputrc` oder per Default) gelten, könnte das die Angriffsfläche vergrößern. Konkret ist mir gerade dieser Absatz aus der Doku aufgefallen:

If the readline module is loaded, input will automatically inherit bash-like history-list editing (e.g. Control-P scrolls back to the last command, Control-N forward to the next one, Control-F moves the cursor to the right non-destructively, Control-B moves the cursor to the left non-destructively, etc.).

Das heißt, wenn sich mehrere Nutzer einen Account teilen, verstehe ich das so, dass sie die History anderer Nutzer sehen können. Keine Ahnung, ob das für deine Anwendung ein Problem ist. Eventuell hat die Verwendung der Readline-Bibliothek noch viel mehr Folgen. - Auch wenn in deinem Code keine Sicherheitslücken zu erkennen sind, ist mir nicht klar, ob bestimmte Funktionalität im `cmd`-Modul, die bei "normaler" Nutzung kein Problem ist, in deinem Anwendungs-Kontext doch ein Problem sein könnte. Und selbst wenn du jetzt einen Audit des `cmd`-Moduls durchführen würdest und das Modul für sicher befinden würdest, könnte es sein, dass ein Update auf eine neue Python-Version das ändert. - Ob du den Ansatz mit der `cmd`-Shell trotz dieser Randbedingungen verfolgen willst, hängt davon ab, welche Angriffs-Szenarien du siehst und was die möglichen Folgen wären. Viele Grüße Stefan