[.net] - Compilazione dinamica e DEP

[gugoXX]

A chiunque possa darmi una mano relativamente a questo dubbio.
Ho ben presente la possiblita' sotto .net di scrivere una stringa di codice, di compilarla al volo e di eseguirla successivamente.
Riassumendo si ha la possibilita' di partire da un dato (la stringa) di cucinarla e di ottenerne il codice, e poi di saltarci dentro in esecuzione.

Come funziona a basso livello questa parte? in pratica c'e' qualcosa che chiede al sistema operativo di ottenere un nuovo segmento di dato, di riempirlo a runtime con il risultato della compliazione e poi di saltarci dentro in esecuzione.

Ora, non e' che questa parte puo' soffrire del solito annoso problema di attacco da parte dei virus?
E' stato inventato apposta il bit NX (o ND) per implementare il DEP sui selettori di segmento di tipo dato, per evitare l'esecuzione di opcode scritti sulle parti di memoria dedicate ai dati,
ma sbaglio o si e' creata una qualche possibilita', sfruttata almeno da quella parte di Framework, di bypassare la restrizione?
In pratica, come puo' il framework trasformare quello che e' un segmento di tipo dato, riempito con il risultato di una compilazione, in un segmento di tipo codice, oppure anche solo di disabilitare il bit NX del selettore, tutto a ring utente? O mi volete dire che la funzione di compliazione di un pezzo di C# (o vb.net, o altri) messa dentro il framework non gira a ring utente ma a ring Kernel? Mi sembra una porcata...

[^TiGeRShArK^]

Originariamente inviato da gugoXX

A chiunque possa darmi una mano relativamente a questo dubbio.
Ho ben presente la possiblita' sotto .net di scrivere una stringa di codice, di compilarla al volo e di eseguirla successivamente.
Riassumendo si ha la possibilita' di partire da un dato (la stringa) di cucinarla e di ottenerne il codice, e poi di saltarci dentro in esecuzione.

Come funziona a basso livello questa parte? in pratica c'e' qualcosa che chiede al sistema operativo di ottenere un nuovo segmento di dato, di riempirlo a runtime con il risultato della compliazione e poi di saltarci dentro in esecuzione.

Ora, non e' che questa parte puo' soffrire del solito annoso problema di attacco da parte dei virus?
E' stato inventato apposta il bit NX (o ND) per implementare il DEP sui selettori di segmento di tipo dato, per evitare l'esecuzione di opcode scritti sulle parti di memoria dedicate ai dati,
ma sbaglio o si e' creata una qualche possibilita', sfruttata almeno da quella parte di Framework, di bypassare la restrizione?
In pratica, come puo' il framework trasformare quello che e' un segmento di tipo dato, riempito con il risultato di una compilazione, in un segmento di tipo codice, oppure anche solo di disabilitare il bit NX del selettore, tutto a ring utente? O mi volete dire che la funzione di compliazione di un pezzo di C# (o vb.net, o altri) messa dentro il framework non gira a ring utente ma a ring Kernel? Mi sembra una porcata...

boh...in c# non ho idea di come funzioni, ma in java ad esempio carichi il tutto mediante il classLoder che lo inserisce direttamente nello stack della VM e quindi è pronto per essere eseguito senza problemi....
immagino che sia stata utilizzata qualche tecnica simile....

[cdimauro]

Originariamente inviato da gugoXX

A chiunque possa darmi una mano relativamente a questo dubbio.
Ho ben presente la possiblita' sotto .net di scrivere una stringa di codice, di compilarla al volo e di eseguirla successivamente.
Riassumendo si ha la possibilita' di partire da un dato (la stringa) di cucinarla e di ottenerne il codice, e poi di saltarci dentro in esecuzione.

Come funziona a basso livello questa parte? in pratica c'e' qualcosa che chiede al sistema operativo di ottenere un nuovo segmento di dato, di riempirlo a runtime con il risultato della compliazione e poi di saltarci dentro in esecuzione.

Ora, non e' che questa parte puo' soffrire del solito annoso problema di attacco da parte dei virus?
E' stato inventato apposta il bit NX (o ND) per implementare il DEP sui selettori di segmento di tipo dato, per evitare l'esecuzione di opcode scritti sulle parti di memoria dedicate ai dati,
ma sbaglio o si e' creata una qualche possibilita', sfruttata almeno da quella parte di Framework, di bypassare la restrizione?
In pratica, come puo' il framework trasformare quello che e' un segmento di tipo dato, riempito con il risultato di una compilazione, in un segmento di tipo codice, oppure anche solo di disabilitare il bit NX del selettore, tutto a ring utente? O mi volete dire che la funzione di compliazione di un pezzo di C# (o vb.net, o altri) messa dentro il framework non gira a ring utente ma a ring Kernel? Mi sembra una porcata...

Non conosco i dettagli, ma non vedo alcun problema di sicurezza in quello che scrivi, per lo meno con codice managed, che viene già "controllato" dal compilatore JIT.

D'altra parte credo che il runtime di .NET non possa essere considerato alla stregua di una normale applicazione: penso abbia il controllo del bit NX (e quindi, almeno la parte di gestione delle risorse, dovrebbe funzionare a ring 0), perché altrimenti il codice compilato non potrebbe venir eseguito, appunto.

L'importante è che l'esecuzione arbitraria di codice da segmenti dati venga inibita a livello di applicazione (cioé se è l'applicazione stessa che prova a fare porcate).

Quindi se lo fa il runtime a ring 0 quando compila l'IM personalmente non ci vedo nulla di male (poi potrebbe anche essere che dopo aver pranzato io non ragioni tanto bene ).