Il trasferimento di dati sensibili attraverso l'ambiente di processo è sicuro?

Question

Il trasferimento di dati sensibili attraverso l'ambiente di processo è sicuro?

#1 da (19 voti)
#2 da (4 voti)
#3 da (3 voti)

34

Recentemente ho cercato la possibilità di passare informazioni sensibili da un processo a un altro (all'avvio del processo) senza passare attraverso la riga di comando o senza utilizzare una voce del filesystem. Questo su Linux ma le domande si applicano anche ad altri sistemi.

In particolare, la password per accedere a un server MySQL deve essere trasferita da uno script al client MySQL. Per fare ciò, puoi passarlo sulla riga di comando ( -pPASSWORD ), ma questo è sgradevole in quanto una semplice lista di processi rivelerà la password a tutti gli altri. In questo preciso caso, il programma client MySQL è abbastanza amichevole da sovrascrivere il testo della riga di comando, sostituendo la stringa della password visibile con XXX ma questa è una soluzione maleodorante.

Ho pensato di utilizzare invece l'ambiente di processo. Lo script imposta la password nell'ambiente di processo, il sottoprocesso avviato può quindi leggerlo da lì. Infatti, il client MySQL lo consente e cerca la variabile di ambiente MYSQL_PWD . Questo sembra abbastanza sicuro e anche elegante, poiché un ambiente di processo non può essere consultato da nessuno tranne da root e dal proprietario del processo, almeno per quanto ne so.

Tuttavia, il manuale di MySQL 5.1 afferma:

This method of specifying your MySQL password [via the environment] must be considered extremely insecure and should not be used. Some versions of ps include an option to display the environment of running processes. On some systems, if you set MYSQL_PWD, your password is exposed to any other user who runs ps. Even on systems without such a version of ps, it is unwise to assume that there are no other methods by which users can examine process environments."

La domanda quindi è: il passaggio di dati sensibili attraverso l'ambiente di processo è veramente insicuro? Esistono sistemi che consentono la consultazione di un altro ambiente di processo senza alcuna verifica delle autorizzazioni? Chiaramente, il superutente può afferrare la password a piacere, ma poi di nuovo, non ne ha bisogno in primo luogo.

linux unix confidentiality

posta David Tonhofer 22.07.2012 - 17:15

fonte

3 risposte

Leggi altre domande sui tag linux unix confidentiality

Esiste un significato solo nel consentire la porta 80 e 443 oggi? Le chiavi del prodotto 'incrinate' possono danneggiare l'utente in alcun modo?

score 19 · Answer 1

Per rispondere alla mia stessa domanda:

Sembra che alcuni sistemi siano, o piuttosto fossero effettivamente insicuri, che perdono informazioni sull'ambiente ad altri processi.

Un problema simile a quello attuale viene sollevato su github dall'utente "mitchblank" per l'applicazione "mosh" (shell mobile). L'autore scrive:

Background: in the process image argv[] and envp[] are stored in the same way, next to each other. In "classic" UNIXes /usr/bin/ps was typically setgid "kmem" (or similar group), which allowed it to dig around in /dev/kmem to read information about the active processes. This included the ability to read the process arguments AND the environment, of all users on the system.

These days these 'privileged ps hacks' are largely behind us: UNIX systems have all come up with different ways of querying such information (/proc on Linux, etc) I think all(?) of these consider a process's environment only to be readable by its uid. Thus, security-sensitive data like passwords in the environment aren't leaked. However, the old ways aren't 100% dead. Just as an example, here's an example from an AIX 5.2 machine I have access to...."

....

Today, mosh seems to be only on Linux/OSX/FreeBSD but if it catches on I'm afraid it will end up on some platform that still uses the old-school UNIX "everybody can see anybody's environment variables" model.

Non sono stato in grado di confermare l'esistenza di alcun sistema che consentisse la fuoriuscita di variabili ambientali (Un'opera per storici e persone che hanno accesso a vecchie installazioni.)

Guardarsi intorno mostra che nel 2000 le variabili ambientali erano effettivamente considerate sensibili, vale a dire che potenziali problemi sarebbero stati segnalati, vedi Vulnerabilità CERT 22404 . In effetti il suddetto punto debole di AIX 5.2 era un bug (da fisso, purtroppo non ci sono informazioni dettagliate su questo su Internet per quanto posso trovare a parte questo bollettino tecnico IBM )

CERT e Il forum RISCHI non fornisce alcun risultato sulle variabili di ambiente che vengono implementate in modo non sicuro o che vengono sfruttate in qualsiasi momento.

Non sono sicuro che altri programmi trasmettano dati sensibili (GPG no), ma l'ammonimento del manuale MySQL sembra essere esagerato.

score 4 · Answer 2

user@example(pts/1)$ cd /proc/1022 
user@example(pts/1)$ ls -lha environ 
-r-------- 1 root root 0 Jul 22 17:20 environ

Quindi, su Linux è sicuro. Potrebbe non essere sicuro su altri sistemi operativi simili a UNIX ...

A meno che tu non possa fidarti di root , ma tutte le puntate sono disattivate.

score 3 · Answer 3

La vecchia saggezza convenzionale era: No, l'ambiente non è sicuro. Non passare segreti attraverso l'ambiente.

Non so se la vecchia saggezza convenzionale è ancora applicabile. Almeno sulle ultime versioni di Linux, non sembra più possibile per un processo visualizzare l'ambiente di un altro processo (se sono di proprietà di utenti diversi). Tuttavia, non so cosa facciano altri sistemi operativi. Sarei piuttosto curioso di passare dei segreti attraverso l'ambiente; non sembra il tipo di cosa che sono sicuro che tutti i sistemi operativi proteggeranno.

Una soluzione più sicura: configurare una pipe (se i due processi hanno una sorta di relazione figlio-genitore), o usare la comunicazione tra processi (IPC), o memorizzarla in un file privato che nessun altro può leggere. La soluzione migliore dipenderà probabilmente dalle circostanze. Se stai scrivendo il codice dell'applicazione, potresti prendere in considerazione uno dei primi due meccanismi. Se stai scrivendo uno script di shell, il più semplice è probabilmente archiviarlo in un file privato le cui autorizzazioni sono impostate per essere sicuro che nessun altro possa leggerlo. Almeno questo è quello che farei, anche se è sempre possibile che io sia eccessivamente prudente.

Naturalmente, se stai scrivendo uno script che deve funzionare solo su un singolo sistema, puoi testare quel sistema per vedere se qualcun altro può visualizzare l'ambiente. Ma se si sta scrivendo un codice generale per un uso diffuso, mi piacerei indirizzare verso le soluzioni del paragrafo precedente invece di passare i segreti attraverso l'ambiente - anche se ammetto che non posso indicare alcun sistema moderno in cui l'utilizzo dell'ambiente sarebbe davvero pericoloso .