Esistono delle violazioni note dell'isolamento di .NET AppDomain?

Question

Esistono delle violazioni note dell'isolamento di .NET AppDomain?

#1 da (4 voti)

3

.NET AppDomains fornisce diversi livelli di isolamento per codice non attendibile o parzialmente attendibile. La sandbox AppDomain è ampiamente distribuita in ASP.NET e Silverlight, sebbene solo quest'ultima sia progettata per isolare codice completamente non attendibile dal resto del sistema operativo.

Esistono fughe note di sandbox basate su AppDomain? Non sono stato in grado di trovare alcun consiglio di sicurezza relativo a questo in una ricerca superficiale. Ovviamente questo non significa che la sandbox sia sicura; potrebbe semplicemente essere poco usato. Ma è un inizio.

Mi sto chiedendo perché la documentazione di MSDN sul fatto che si possa fare affidamento sulla sandbox sembra essere contraddittoria. C'è questa pagina che dichiara "che sconsigliamo caricamento ed esecuzione di codice di origini sconosciute senza mettere in atto misure di sicurezza alternative ". E poi c'è questo articolo il cui intero titolo è "Come ospitare in modo sicuro le aggiunte non attendibili ins ".

.net sandbox

posta RomanSt 28.04.2015 - 00:41

fonte

1 risposta

Leggi altre domande sui tag .net sandbox

VeraCrypt sicuro in pubblico? Come configurare iptables per le porte di apertura obbligatorie?

score 4 · Accepted Answer

Sì, ci sono molti esempi.

MS14 -072 è uno dei più diretti. Un utente malintenzionato può dirottare una chiamata remota per elevare i privilegi ad altri AppDomain in esecuzione nello stesso contesto di esecuzione. Praticamente tutti gli errori di esecuzione diretta del codice funzionano anche come esempi, perché una volta che si esce dall'ambiente sicuro dal tipo, è possibile effettuare chiamate API dirette sul sistema che violano tutte le garanzie di sicurezza.

Esistono anche bug a livello di applicazione che possono violare le restrizioni di AppDomain. Ad esempio, un bug di scrittura di file arbitrario potrebbe causare un AppDomain secondario per caricare una DLL o un altro oggetto eseguibile, con conseguente compromissione di entrambe le parti dell'applicazione.

Per quanto riguarda l'hosting di codice non attendibile, tieni presente che l'ultimo articolo che hai collegato è molto vecchio. Generalmente è considerato insicuro ospitare qualsiasi tipo di codice non attendibile. Code Access Security (CAS) è diventato obsoleto in .NET a causa della sua inefficacia e difficoltà di implementazione. Microsoft fornisce consigli nel caso in cui assolutamente sia necessario ospitare codice non affidabile, ma generalmente questo è più focalizzato sull'uso di librerie di terze parti a codice chiuso per le quali non sono disponibili metriche di sicurezza, piuttosto che "caricare un eseguibile .NET e lo eseguirò ".