wrapper di script Set-uid, shell (system) (3) e Bash Function Import from Environment

Naviga le tue risposte
3

Dato che è un requisito frequente per consentire agli utenti non privilegiati l'accesso limitato alle funzioni privilegiate: Talvolta gli amministratori di sistema Jobbing lo forniscono sotto forma di script di shell, che vengono quindi richiamati tramite un wrapper setuid , come così: 

int main()
{
   setuid( 0 );
   system( "/path/to/script.sh" );

   return 0;
}

(Le prove per questa asserzione possono essere trovate cercando setuid script non funziona sul tuo motore di ricerca preferito o su overflow dello stack . No, non dovrebbero farlo, ma lo sono. Quando i consigli sulla sicurezza sono troppo difficili, o troppo oscuri, per gli amministratori di sistema da seguire, è necessaria un'altra soluzione.)

Si noti che questo non può essere semplicemente ignoranza. Chi si aspetterebbe che uno script contenente solo questo sarebbe pericoloso? 

#!/bin/bash
kill -HUP $(< /var/run/demonname.pid)

Ovviamente l'intento è chiedere a demonname di rileggere il suo file di configurazione. Non chiama nient'altro che bash built-in (quindi non dovrebbe usare il percorso) e non consulta l'ambiente una sola volta. A mio parere, anche un amministratore di sistema esperto potrebbe essere perdonato per aver pensato che un sottotitoli era OK in questo caso .

Come precedentemente scoperto, Shellshock e (anche senza di esso) la funzione Importa funzione da ambiente (FIE) di bash, pongono vulnerabilità di escalation dei privilegi.

Supponendo che:

  • tali cose esistono nell'installazione, e tu non sai che lo fanno, e
  • puoi assumere in modo affidabile che ne verranno creati di nuovi ...

Sarebbe consigliabile:

  • scaricare bash e usare qualcos'altro per sempre e sempre?
  • patch bash per estrarre completamente la FIE (l'opzione "nuke from orbit") ?
  • patch bash per autorizzare i percorsi completi degli script che sono autorizzati a utilizzare questa funzione?
  • patch system e popen per cancellare l'ambiente per impostazione predefinita se eseguito come root? (Le persone non dovrebbero usare queste funzioni).
  • Invia l'amministratore ogni volta che qualcuno chiama system come utente root? O avvia uno script di shell come root?
  • o cosa?

In altre parole, FIE è utilizzato nella produzione per scopi diversi dallo sfruttamento di sistemi? Se è così possiamo autorizzare tali usi e vietarlo ovunque? Se no, non possiamo semplicemente strappare la funzionalità ?

    
posta Ben 03.10.2014 - 15:01
fonte

2 risposte

5

Tali wrapper setuid sono pericolosi indipendentemente dal fatto che l'interprete di script sia una bash fissa, una bash non fissata o qualche altra shell. La ragione è che gli interpreti di sceneggiatura sono influenzati da molte variabili d'ambiente. Gli autori di reato citati sono PATH e IFS. Questo è il motivo per cui sudo reimposta l'intero ambiente a valori sensati (poiché gli autori di shell sono invariabilmente creativi, non è possibile ottenere la sicurezza con una lista nera su alcune variabili di ambiente "conosciute e pericolose", è necessario uccidere tutto).

Per abusare di una metafora abusata, la FIE è solo la punta dell'iceberg, non l'effettivo blocco di ghiaccio che squarcia lo scafo della nave. Le variabili di ambiente sono il problema, perché sono un canale indiretto nascosto che si propaga attraverso le chiamate e possono avere un impatto sulla funzionalità in molti modi (ad esempio, è possibile modificare il comportamento delle routine di allocazione della memoria attivando la "modalità di debug" attraverso l'ambiente). Per i binari setuid, il kernel cancella il caso peggiore (LDPRELOAD) ma, in realtà, tutte le variabili d'ambiente dovrebbero essere cancellate, con la possibile eccezione delle variabili LC_ * (per impostare il comportamento dipendente dalla locale - e anche questo è altamente discutibile) .

Ovviamente, il patching del kernel per cancellare l'ambiente ogni volta che viene invocato un binario setuid è destinato a rompere le cose ... Persino OpenBSD, nonostante la loro posizione di "tutta la sicurezza ci appartiene", ha evitato di implementare effettivamente tale cambiamento drastico. Invece, si affidano alla documentazione :

Don't trust your environment ! This involves simple things such as your PATH (never use system with an unqualified name, avoid execvp), but also more subtle items such as your locale, timezone, termcap, and so on. Be aware of transitivity: even though you're taking full precautions, programs you call directly won't necessarily. Never use system in privileged programs, build your command line, a controlled environment, and call execve directly. The perlsec man page is a good tutorial on such problems.

    
risposta data 03.10.2014 - 15:19
fonte
0

Il mio wrapper ha un aspetto così: 

int main()
{
   setuid( 0 );
   execve("/path/to/script.sh", "/path/to/script.sh", NULL );

   return 0;
}

Impossibile shellshock anche se / bin / sh è bash.

    
risposta data 03.10.2014 - 19:36
fonte

Leggi altre domande sui tag

Cosa succede se si carica il codice con un'estensione di file consentita da un sito Web (PNG per ex)? Perché i server Web sono ubiquamente configurati inserendo nella blacklist file inaccessibili invece di inserire nella whitelist quelli accessibili?