Hallo,

ich habe eine Frage an die (bash) Shell-Script-Profis:

Folgende Varianten von apt - Kommandos habe ich in einem Script gefunden:

apt update -q4 & CrI

apt install -yq4 & CrI

Kann mir jemand erklären, was der Parameter q4 und das CrI nach dem & bezwecken?

Viele Grüße

Barny

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Moin dug!

dug@pn.coretrust.de schrieb am Donnerstag, den 20. Januar 2022:

Folgende Varianten von apt - Kommandos habe ich in einem Script gefunden:

apt update -q4 & CrI

apt install -yq4 & CrI

Kann mir jemand erklären, was der Parameter q4 und das CrI nach dem & bezwecken?

für apt (aktuelle Version) gibts -q nicht; apt ist aber quasi nur ein
wrapper für apt-get und anderes. Mit apt-get kann man -q aufrufen,
aber nicht in der Form wie es da steht. Dort würde es für "quiet"
stehen und es wird davor gewarnt das einfach zu machen weil apt-get
sonst Sofware installiert bzw. Konfigurationen ändert ohne dass man
das mitbekommt.

Das & sagt dass der Prozeß in den Hintergrund geschickt werden soll.
In diesem Fall soll das apt ausgeführt werden. CrI ist kein
Standard-Kommando, das muss in diesem Script definiert werden. Es ist
zumindest mehr als ungewöhnlich ein Kommando so aufzurufen, ohne
Pfadangabe oder ähnliches; das läd zu unerwünschtem Verhalten ein.

best regards, Hanno Wagner
--
| Hanno Wagner | Member of the HTML Writers Guild | Rince@IRC |
| Eine gewerbliche Nutzung meiner Email-Adressen ist nicht gestattet! |
| 74 a3 53 cc 0b 19 - we did it! | Generation @ | Fachbegriffe der Informatik : Plattformunabhängig

Wenn Du GWBASIC im Dos-Emulator laufen läßt bist Du auch plattformunabhängig!

Du brauchst nur einen Dos-Emulator!
Bodo Eggert

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

* dug@pn.coretrust.de <dug@pn.coretrust.de> wrote:

Hallo,

ich habe eine Frage an die (bash) Shell-Script-Profis:

Folgende Varianten von apt - Kommandos habe ich in einem Script gefunden:

apt update -q4 & CrI

apt install -yq4 & CrI

Kann mir jemand erklären, was der Parameter q4 und das CrI nach dem & bezwecken?

Was das -q Quiet bedeutet hat dir Hanno ja schon gesagt.

Aber darf man mal fragen aus welchem Zusammenhang dieses Skript kommt?

Ich persönlich würde ja um ein Skript das mir mit unterdrückter Ausgabe
des apt Kommandos ein 'update' und ein 'install' mit '-y assume yes'
ausführt, aus Sicherheitsgründen einen ganz ganz weiten Bogen machen.
Das kryptische 'CrI' macht das Ganze überhaupt nicht besser.


--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

dug@pn.coretrust.de <dug@pn.coretrust.de> (Do 20 Jan 2022 10:53:55 CET):

Hallo,

ich habe eine Frage an die (bash) Shell-Script-Profis:

Folgende Varianten von apt - Kommandos habe ich in einem Script gefunden:

apt update -q4 & CrI

Da gibt es eine Manpage zu apt(8), in der wird dann erwähnt, dass Du die Manpage zu apt-get(8) konsultieren sollst. Dort steht dann was über
„-q“.

Das Ampersand ist Dir schon von anderen erklärt worden. Das ist in der Bash-Manpage nicht so leicht zu finden, ohne Shell-Vorkenntnisse. Aber
wenn man nach „backround“ sucht, geht es schnell.

CrI: mach mal auf der Kommandozeile „type -a CrI“, vermutlich wirst Du nichts finden. Dann bau dieses „type…“ mal in den Script ein:


type -a CrI
exit
apt update -q4 …

Da wirst Du sehen, was es ist. Vermutlich eine Shell-Funktion die vorher definiert wurde, im Script, oder in Script-Fragmenten, die per „source“ oder „.“ eingelesen wurden. Oder ein externes Tool, das über einen manipulierten PATH gefunden wird.

Lt. apt-file gibt es keine Datei CrI in einem Debian-Paket. Also
vermutlich eine Funktion.

Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de ---------------------------- internet & unix support -
Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
gnupg encrypted messages are welcome --------------- key ID: F69376CE -

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEE0L/WueylaUpvFJ3Or0zGdqa2wUIFAmHqWJ8ACgkQr0zGdqa2 wUICIggAl1unCLe9hnBDJsKDTMxFQ9/LV8wJTsXz/pk+Gzb2aPQR/gwA6D6OkIq6 0kp3Ep3ZZF8s2vu0b7CgniKa5hNF2juWYDlv9Y+BpW/dd8PmubOCpFAiQFVoLP8R s4to4mUS4fyzAGW3JY1ywqjM69C0QbB9uY2c/oWZ+R1I9GteZgyDO+57c7NLamqR e/QC4A0GkUXs32dfo9p6beW3VQPIKBckoQpP+G2utYTM9ikbG09Kny38VvMl0taC idHyVuEoTdSXhqXRsA8onuugUARH9oxlSlcZciQjJZV5NUj9glx2RramvcYRmG52 ReR+CNErhxmNyL4OPEh/6Az9dsK4SA==
=Tsmu
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hanno 'Rince' Wagner <wagner@rince.de> (Do 20 Jan 2022 11:27:44 CET):

Standard-Kommando, das muss in diesem Script definiert werden. Es ist zumindest mehr als ungewöhnlich ein Kommando so aufzurufen, ohne
Pfadangabe oder ähnliches; das läd zu unerwünschtem Verhalten ein.

Kommandos in Scripten mit grundlos mit vollem Pfad aufzurufen ist eine furchtbare Unart. Der Script-Autor sollte es dem lokalen Admin
überlassen, per PATH zu steuern, wo die Standardkommandos rumliegen.

Warum? Möglicherweise habe ich einen Verzeichnisbaum, der ein
komplettes Root-Dateisystem enthält und ich möchte (ohne chroot) die
Tools innerhalb dieses Root-FS aurufen, dann würde ich das so machen:

PATH=/rootfs/bin:/rootfs/sbin:… script …

Wären die Kommandos festgenagelt, ginge das nicht.


Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de ---------------------------- internet & unix support -
Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
gnupg encrypted messages are welcome --------------- key ID: F69376CE -

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEE0L/WueylaUpvFJ3Or0zGdqa2wUIFAmHqWo0ACgkQr0zGdqa2 wUIZbwgAy3DB+cAO9AXCrdaT1Xm9kzimal+it0h2K4BD7WAUNAYtz9RLSP9KtGan LK6sa4LpU1h4QOOXq9fcWnfLXHbbT/st4eSouqkaGJuNnkuJGyH6LF7/GPXTOKGG 7thHRBQATZIKNNKhUzEvP8OQEo5LZDM5aRkhFWGPUqAksVb+umcfnPmfb0T0SJU3 NxTqguMTrxWOrkTOyvvmfFh+ZD1Ds1/Ui03/V1yRFUWHl2d9+hua1HCmB5Fvy2xG eLbNnqrK4/QZluzEqDj8BswneAVlv53vF0hGNgJMlIzUmMkuAwv39vblD8sa3NmG Sbzo3tnIPG6EEacB/ShPeikI59dM+Q==
=E5gj
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Heiko!

On Fri, 21 Jan 2022, Heiko Schlittermann wrote:

Kommandos in Scripten mit grundlos mit vollem Pfad aufzurufen ist eine furchtbare Unart. Der Script-Autor sollte es dem lokalen Admin
überlassen, per PATH zu steuern, wo die Standardkommandos rumliegen.

Grundlos nicht. Aber ich als Script-Autor weiss welche Tools ich
aufrufe - mit welchen Parametern. Wenn ich da aber statt einem gnu-tar
ein sco-tar habe oder ein bsd-tar oder so, sind die Parameter leicht
anders. genauso bei cp, rm, younameit.

Zusätzlich kann ein Angreifer an eine Stelle die auch via $PATH
aufgerufen wird ein Programm hinlegen dass genauso heisst - und
welches dann _statt_ dem eigentlichen Programm aufgerufen wird. Wenn
das auch noch mit Root-Rechten passiert (was in diesem Fall sicher ist
da apt direkt aufgerufen wird und nicht sudo apt) ist das schon
gefährlich.

Allerdings würde ich auch zu Beginn des Scripts die Programme
definieren (also RM=/bin/rm); die könnte dann der lokale Admin
entweder ändern oder durch eigene Übersteuerung korrigieren
${RM:=/bin/rm}.

Mit freundlichen Grüßen, Hanno Wagner
best regards, Hanno Wagner
--
| Hanno Wagner | Member of the HTML Writers Guild | Rince@IRC |
| Eine gewerbliche Nutzung meiner Email-Adressen ist nicht gestattet! |
| 74 a3 53 cc 0b 19 - we did it! | Generation @ |
#"In Frankreich zum Beispiel ist Verschluesselung verboten. Seitdem gibt es
# in Frankreich keine organisierte Kriminalitaet und keine terroristischen
# Anschlaege mehr."

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hanno 'Rince' Wagner <wagner@rince.de> (Fr 21 Jan 2022 09:23:40 CET):

Hi Heiko!

On Fri, 21 Jan 2022, Heiko Schlittermann wrote:

Kommandos in Scripten mit grundlos mit vollem Pfad aufzurufen ist eine furchtbare Unart. Der Script-Autor sollte es dem lokalen Admin
überlassen, per PATH zu steuern, wo die Standardkommandos rumliegen.

Grundlos nicht. Aber ich als Script-Autor weiss welche Tools ich
aufrufe - mit welchen Parametern. Wenn ich da aber statt einem gnu-tar
ein sco-tar habe oder ein bsd-tar oder so, sind die Parameter leicht
anders. genauso bei cp, rm, younameit.

Wenn Du gnu-tar brauchst, rettet Dich der explizite Pfad auch nicht.

Zusätzlich kann ein Angreifer an eine Stelle die auch via $PATH
aufgerufen wird ein Programm hinlegen dass genauso heisst - und
welches dann _statt_ dem eigentlichen Programm aufgerufen wird.

Dann ist der Angreifer sicher privilegiert. Und dann hat er andere Möglichkeiten.

Sollten in PATH relative Pfade wie z.B. „.“, dann ist der Aufrufer
selbst schuld. Die Pfad-Variable ist unter seiner Kontrolle.

Allerdings würde ich auch zu Beginn des Scripts die Programme
definieren (also RM=/bin/rm); die könnte dann der lokale Admin
entweder ändern oder durch eigene Übersteuerung korrigieren
${RM:=/bin/rm}.

Sicher machbar, wenn es um 1…3 Tools geht, die aufgerufen werden sollen.
Aber IMHO skaliert das schlecht für etwas komplexere Aufgaben.

Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de ---------------------------- internet & unix support -
Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
gnupg encrypted messages are welcome --------------- key ID: F69376CE -

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEE0L/WueylaUpvFJ3Or0zGdqa2wUIFAmHqdxYACgkQr0zGdqa2 wUL6nQgA4cKq+QM/6FrARTL8aqa1VZduBAVzBbUjzmfe/lyeo/gQMjIUSZb9y6z9 RfpmdcwufAZKH2P6MLwhwnQauNR42W5LYhHzjEVkC6n4vLzhqPKz3DMrbvJGhPyY cGkudzfCs++cIUL5UeOhsG56VC+5hmKv49Z9qgCqdGB5nlA9DZux2ob0sN6bVUrM pVSGZJNbkn4W81Be/rzpFQ7bwRGUEqxxql6IudJhXeeHq683nne3tMPKWSDZ/W6Y D8HadKwpIiygryRoRARPfsyszncVWCy1IvKaNYDNtrvG5MPnCSPFYBkmGwvSPUCm ojQvPMqRwlcKMVxRx4U7pylC9GSOzw==
=AlN9
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)