Server socket personalizzato su Internet in esecuzione come root

Che il codice "venga eseguito come root" è per lo più irrilevante. Root o non-root è una distinzione che ha senso solo localmente su una macchina, e solo se si desidera contenere un codice potenzialmente ostile (ad esempio il codice del server dirottato) senza far cadere l'intera macchina. Questo è il modello di mainframe di alcuni decenni fa. A quel tempo, si credeva che potessi avere un sistema Unix (o simile a Unix) in modo tale che il processo non-root potesse essere tenuto separato l'uno dall'altro, senza alcuna possibilità di eludere quel contenimento e raggiungere altro processo sulla stessa macchina.

Questa convinzione difficilmente vale al giorno d'oggi. Le escalation di privilegi locali sono abbondanti; è molto difficile collegarli tutti mantenendo un ambiente completamente funzionale. In generale, è più sicuro assumere che qualsiasi codice ostile in esecuzione sulla macchina, sotto qualsiasi utente, sarà in grado di assumere il controllo dell'intero sistema, a meno che non vengano applicate alcune misure di contenimento più forti, ad esempio (in crescenti livelli di complessità e contenimento). ) chroot , jail , macchine virtuali . In ogni caso, un processo che chiama mmap () su /dev/mem può ottenere il pieno controllo sulla macchina locale (probabilmente la macchina virtuale se si va sulla VM).

La conclusione di tutto questo è che se la tua macchina viene hackerata e far sì che la connessione a Internet aumenti sicuramente tale probabilità, allora dovresti chiederti cosa potrebbe accadere se viene sovvertito da estranei ostili. Cambiare il codice da non eseguire come root e non in mmap /dev/mem non cambia sostanzialmente le cose qui. Ciò che importa è se il codice è stato ben progettato, revisionato, testato, documentato e mantenuto.

Devo dire che un mmap() diretto su /dev/mem invia un segnale strong di "a questi ragazzi non dovrebbe essere permesso di avvicinarsi a una tastiera". Non so perché lo stai facendo nel tuo server (*) ma sembra davvero strano. La mappatura della RAM fisica nello spazio degli indirizzi non è un problema di sicurezza , a meno che non ti aggrappi al modello del mainframe obsoleto; tuttavia, fare cose molto strane è un problema di sicurezza perché rende molto più difficile la progettazione, la revisione, il testing, la documentazione e la manutenzione.

^{(*) La mia ipotesi migliore è che il server interagisca con un hardware personalizzato che non ha uno specifico driver del kernel e fa I / O mappando i suoi circuiti nello spazio degli indirizzi fisico, come, ad esempio, un scheda grafica. Sarebbe più pulito, e quindi più sicuro, scrivere effettivamente un driver del kernel appropriato.}

Francamente, le parole rilevanti sono "codice personalizzato eseguito come root ed esposto al pubblico".

Per giustificare lo sforzo di codifica e i ritardi, dovrai eseguire alcuni calcoli rapidi sull'impatto del codice da sfruttare e un attore malintenzionato che ottiene l'accesso come root al server su cui è in esecuzione. Se il costo di una violazione è superiore al costo dello sforzo di codifica e del ritardo di pianificazione, allora hai una metrica chiara da portare prima del business e possono fare la chiamata sui rischi che sono disposti ad assumere.

Un fattore importante da considerare è la probabilità che un attore malintenzionato ottenga l'accesso root direttamente dal proprio codice personalizzato anziché accedere all'utente non root in cui il codice potrebbe essere eseguito. È inoltre necessario considerare la probabilità di passare alla radice da utente non root. Se ottenere l'accesso all'utente non root ha lo stesso impatto di ottenere l'accesso di root, o se l'inoltro a root da parte dell'utente non root è banale, non c'è alcuna differenza tra i 2 utenti.

Parlare con il business può essere molto difficile perché la loro prospettiva è molto diversa da una prospettiva tecnica e devono bilanciare più problemi che non solo la tecnologia. Trovare un linguaggio comune, come il denaro, tende a fornire un terreno comune.

Potresti provare a dimostrare i problemi del server che si sono verificati in server ben testati e presentare il reclamo "Se dopo tutto il test e l'esame non erano sicuri, come possiamo aspettarci di fare meglio?"

Il primo esempio che mi viene in mente è il bug Shellshock . Quando combinato con CGI dal server Web Apache, consentiva l'esecuzione remota. Questo non era dovuto a un bug in Apache, ma ancora Apache divenne vulnerabile. Se hai seguito le best practice e hai eseguito Apache come utente non privilegiato, questa era solo una brutta vulnerabilità. Se hai eseguito Apache come root, è stata una vulnerabilità fatale che ha seriamente compromesso la sicurezza del tuo server e qualsiasi cosa fosse connessa ad esso.

PS: Sono d'accordo sul dire "questo è fottutamente pazzo". dovrebbe essere più che sufficiente:)

È molto importante fornire soluzioni alternative valide e non solo contare su argomenti che si tratta di una cattiva soluzione tecnica. Ad esempio, potrebbe utilizzare una VPN l'installazione è una scelta migliore piuttosto che ri-sviluppare il codice per utilizzare un non privilegiato utente? Puoi generalizzare la soluzione? Ad esempio, fornirebbe una soluzione VPN funzionalità aumentata e più sicura anche in altre aree. Non limitarti a litigare è una cattiva idea, discutere per un'idea migliore che dia loro una soluzione che vogliono. A fai questo, dovrai capire cosa vogliono realmente, non cosa loro chiesto, ma qual è il driver di base. Spesso troverai quello che loro chiedono è la cosa sbagliata, ma la funzionalità che vogliono è necessario. Capire questo ti permetterà di identificare una soluzione migliore che loro sarà felice con.

L'altra cosa che devi fare è dare la priorità ai costi / rischi aziendali rispetto a quelli tecnici quelli. È possibile includere anche i rischi / i costi tecnici, ma non concentrarsi su loro. Non appena inizi a parlare di escalation dei privilegi, CVE, crittografia dei dati, firewall, porte ecc., perderai l'interesse dei dirigenti aziendali. Anziché, parlare di cose come vendite perse / produttività, danni alla reputazione, furto di commercio segreti o informazioni proprietarie, riduzione della fiducia dei clienti, governo e altro conformità ecc. In sostanza, metti il tuo caso in termini che la direzione può capire - termini commerciali.

Se tutto il resto fallisce, prendere in considerazione la possibilità di sostenere un test di penetrazione o un controllo esterno. Il la sfortunata realtà è che troppo spesso il management non ascolta internamente raccomandazioni tecniche, ma siederà e prenderà nota non appena un rispettabile società esterna o consulente indica i rischi. Questo a volte è dovuto al società esterna / consulente con competenze migliori nel presentare argomenti nel mondo degli affari termini e talvolta è perché sono più disposti a presentare i fatti in a modo chiaro e chiaro che il personale interno può essere riluttante a fare perché potrebbe essere interpretato in modo errato o riflette male su di loro. Spesso questo processo è estremamente frustrante come la società esterna / consulente dirà esattamente le stesse cose voi hanno detto Non preoccuparti: concentrati sull'obiettivo finale, che sta ottenendo a migliore soluzione che sei in grado di gestire e non ti tiene sveglio la notte preoccuparsi di quando la roba marrone colpirà la ventola.

Alla fine della giornata, tutto ciò che puoi fare è identificare e segnalare i rischi e assicurarti sono comunicati il più chiaramente possibile a coloro che fanno il finale decisioni. Vengono pagati i soldi per assumersene la responsabilità quelle decisioni ed è in realtà abbastanza legittimo per loro decidere di accettare il rischi e andare avanti comunque. Potresti ancora pensare che sia una cattiva idea, ma è così in gran parte irrilevante. Per quel che ne sai, potrebbero esserci altre strategie o ragioni che cambia l'equazione del rischio e fa la scelta di continuare con ciò che senti una cattiva soluzione una scelta praticabile dopo tutto. Purché tu abbia fatto ciò che potresti comunicare i rischi e fornire alternative praticabili, hai fatto ciò che è richiesto e ora è necessario implementare la decisione finale nel modo migliore possibile con risorse fornite.