Re: [ml] problema hardware su x86 -> ring zero

Ed3f wrote:
> La causa del problema è principalmente l'architettura del server X Windows, con la necessità di eseguire i driver in user space che quindi richiede accesso ad un ampio range di indirizzi delicati...
>   
il problema è molto simile in Windows, in realtà. L'accesso vero e 
proprio alle risorse hardware è molto ben nascosto in kernel mode dietro 
layer su layer, ma esiste comunque un processo "privilegiato". Inoltre 
c'è il problema delle applicazioni DOS, a cui in modalità schermo intero 
viene dato accesso diretto agli interrupt VGA

E questo è solo per analizzare il lato "vecchio stile" del problema: i 
tanto invidiati driver dei produttori per grafica 3D accelerata sono, 
dal punto di vista della sicurezza, un vero disastro, a causa di codice 
kernel mode che accede a strutture user mode... e NO, per nessuna buona 
ragione, spesso solo per leggere la riga di comando del processo e 
"ottimizzare le prestazioni" per un'applicazione specifica (leggi: 
falsare i benchmark). Quasi tutti consentono *almeno* un DoS locale. I 
driver nVidia senza dubbio i peggiori, con l'uso di *indirizzi 
hard-coded*, ma comunque tutti accedono allegramente a memoria 
controllabile da user mode senza alcun tipo di validazione o protezione 
da eccezioni (argomento AMPIAMENTE documentato)
> http://www.securityfocus.com/print/columnists/402
>   
Aggiungo quello che posso aggiungere:
> [...] But why should it be so? After all the superuser is only a user 
> (with other privileges than normal users) on the system. So why should 
> he need to modify the inner structure of the operating system? The 
> superuser could for instance only be authorized to modify some system 
> settings.
ma in qualche modo deve essere possibile installare nuovi driver. A meno 
il sistema non sia completamente headless, avviato da un'immagine in 
sola lettura preparata su un'altra macchina, un certo livello di 
estensibilità del sistema deve esserci. E finchè i driver saranno 
scritti in linguaggi di basso livello, difficilmente analizzabili 
staticamente (ma so che quelli di FreeBSD stanno lavorando ad un 
meta-linguaggio di alto livello per lo sviluppo kernel mode), rimarrà 
sempre questa fondamentale finestra di vulnerabilità. L'alternativa è la 
firma digitale con chiave hardware, ma quello più che un problema 
tecnologico è diventato un problema politico, e non ne voglio discutere...
> Is Windows vulnerable too?
>
> Loïc Duflot: Windows NT, XP, Vista are not vulnerable to this attack 
> scheme since there seems to be no way for ring 3 code to request PIO 
> access privileges.
il modo c'è, ma richiede privilegi di servizio di sistema. Ma è inutile 
dire che una volta in esecuzione come servizio di sistema non c'è 
praticamente limite a quello che possiamo fare (incluso caricare driver, 
ma anche cose molto più creative come rimappare gli scancode della 
tastiera e intercettare Control-Alt-Del)... e questo vettore di attacco 
"fantascientifico" è una preoccupazione in senso molto relativo