Bash: Perché il sourcing di un file dovrebbe essere meno sicuro rispetto al bashing (esecuzione in un'altra sessione)?

Question

Bash: Perché il sourcing di un file dovrebbe essere meno sicuro rispetto al bashing (esecuzione in un'altra sessione)?

#1 da (4 voti)
#2 da (0 voti)

2

Bash: perché l'individuazione di un file è meno sicura rispetto al bashing (esecuzione in un'altra sessione)?

È il caso o ho completamente frainteso?

Ho sentito nel contesto del sourcing di un sub-script da uno script master. Ad esempio, tu curl e source script remoto che invia uno o più script (per il gusto della domanda, assumiamo che tutti questi script siano sicuri e corretti).

Quello che cerco di capire è perché qualcuno dovrebbe pensare che sia meno sicuro procurarsi lo script interno, piuttosto che eseguirlo ( ~/sub-script.sh o bash ~/sub-script.sh ).

Se tutta questa domanda sembra improbabile o assurda, per favore non essere sarcastico, ma per favore assicurati di votare per chiuderlo se puoi perché potrebbe essere solo basato su un malinteso da parte mia, o su una citazione errata di qualcosa di più profondo intenzione dell'uomo che l'ha detto.

bash code-execution

posta user9303970 09.02.2018 - 17:38

fonte

2 risposte

0

L'origine dello script altera / altera il tuo ambiente attuale. Potrebbe avere effetti di sessione futuri su tutta la linea. Per un semplice esempio, immagina il seguente scenario.

I (l'attaccante) fornisce alcuni script utili che fanno qualcosa che vuoi. Ma in aggiunta, il mio script rilascia un eseguibile chiamato "sudo" in una directory nascosta da qualche parte. Questo eseguibile raccoglie e manda a casa me, i suoi argomenti, e chiama il comando "sudo" del sistema. Il mio script regola anche la variabile $ PATH inserendo per prima la mia directory nascosta.

Se esegui il mio script nella sua shell, ottieni l'utile effetto che pensavi di ottenere e il mio wrapper nascosto caduto, ma nient'altro.

Se hai eseguito il sourcing del mio script nel tuo ambiente corrente, la prossima volta che digiti "sudo foo" chiamerai il mio script wrapper ostile, che chiamerà il vero sudo per tuo conto, ma ricevo le tue informazioni. Forse giorni o settimane dopo.

Questo è un esempio forzato, ma il punto è che l'origine delle modifiche cambia l'ambiente dopo che il lavoro è terminato. L'esecuzione nella propria shell limita le modifiche al lavoro eseguito dallo script.

Gli effetti collaterali possono essere sfruttati dagli aggressori.

risposta data 09.02.2018 - 19:40

fonte

Leggi altre domande sui tag bash code-execution

È pericoloso ricevere la posta come root? Perché / dev / random è così lento su Linux? [duplicare]

score 4 · Accepted Answer

Non conosco la dichiarazione esatta e il suo contesto, quindi posso solo intuire cosa si intende: se uno script viene originato invece di essere eseguito in una shell separata, tutte le variabili o funzioni definite in questo script o eventuali modifiche alle variabili essere visibile nella shell dopo che lo script è stato eseguito. Questo potrebbe essere inteso in alcuni casi (ed è per questo che è possibile creare uno script) ma potrebbe anche essere un inquinamento involontario dell'ambiente corrente della shell con effetti collaterali indesiderati.

Quindi, a meno che non si voglia esplicitamente consentire allo script di apportare modifiche al proprio ambiente bash locale, è necessario eseguirlo come script di shell (ovvero shell separata) e non fornirlo.

Si noti che questo non è in realtà un problema di sicurezza delle informazioni: dal punto di vista della sicurezza, lo script originario e lo script eseguito in una shell separata possono eseguire codice dannoso con le autorizzazioni dell'utente.