Jeder Befehl kann sein eigenes Environment ändern - und weitere Subprozesse anstossen, für die er das Environment frei definieren kann. Viele Befehle haben das nötige Rüstzeug gleich fix und fertig mit eingebaut und sehen den Aufruf einer Shell aus dem laufenden Programm heraus vor. Das geht mit Kommandos wie vi, less, und eben auch mit telnet.Trapper schrieb:
Der Befehl "telnet" ist in dieser Hinsicht "unsicher", weil er -durch ein manipuliertes Zeichenecho vom Host der Gegenstelle aus initiiert- ein solches "Shell-Out" grundsätzlich erlaubt.
Das heisst, dass du denkst du hättest die Telnet-Sitzung beendet, aber sie läuft im Hintergrund weiter und wurde nur gestoppt. Du befindest dich dann in einer Subshell, für die jemand anders die Parameter zum Aufruf gesetzt hat - einschliesslich der Umgebungsvariablen. Es ist zwar nach wie vor "deine" Shell, d.h. sie nimmt Remote keine Befehle entgegen, sondern nur interaktiv von dir - aber sie ist evtl. auf eine Art und Weise konfiguriert, die du so nicht erwartest.
Dieses Risiko wäre vermeidbar, wenn du die "alte" Übertragungsmethode in der Konfigurationsdatei ~/.telnetrc sperrst - aber wer macht das?
Rufst du telnet über eine im strikten POSIX-Modus laufende Subshell auf (sh), würdest du diese Form von Manipulation sofort bemerken - das Eingabeprompt wäre plötzlich nicht mehr dein gewohntes. Du könntest daran sofort sehen, dass da irgendwas "nicht normal" ist.
), aber mit ANSI.SYS kam ich direkt nie in Berührung.
