Re: weird Windows 2000/XP bug [identificata possibile causa?]

At 05.55 03/11/2001 +0100, you wrote:

>Il Bug colpisce il Command Prompt di Windows NT/2000/XP. Il CMD.EXE e il 
>Command.com crashano se una stringa contenente almeno un carattere di 
>tabulazione (ASCII/HEX 09), seguito da una sequenza di backspaces 
>(ASCII/HEX 08) e da un carattere casuale viene visualizzata sullo standard 
>output o lo standard error. In questo caso Windows NT4 si blocca con la 
>classica schermata blu, mentre 2000 e XP si riavviano immediatamente.

Vedo un po' di confusione. Buono lo spirito di fondo, ma esecuzione 
confusionaria.
Primo: improbabile, impossibile che un normalissimo programma causi uno 
schermo blu. cmd.exe e command.com sono due programmi come tanti altri, 
senza nulla di speciale
Secondo: la finestra di console, a differenza di quanto sostengono diffuse 
credenze popolari, non è creata da cmd.exe o command.com, ma:
  - in Windows 95 e 98: le finestre fanno parte del processo kernel32, che 
però si limita ad ospitarle nel suo spazio di indirizzamento, il vero 
codice (nonchè la dialog da cui viene generata la finestra) si trova in 
winoa386.mod, libreria a 16 bit. Inoltre, ad ogni console corrisponde 
un'istanza di una V86 (sempre, anche per programmi a 32 bit)
  - in Windows NT/2000/XP: le finestre di console sono gestite da un 
processo, csrss.exe, che svolge anche, tra le altre, funzioni di gestione 
della tabella dei processi. Nonostante il suo ruolo sia stato notevolmente 
ridimensionato in NT 4, gode comunque di diritti superiori al normale: non 
può essere agganciato dai debugger, non può essere terminato (nemmeno 
modificandone la ACL), e soprattutto si registra all'avvio come il gestore 
degli errori critici (è lui ad esempio a mostrare le finestre di messaggio 
in caso di un GPF), cosa che gli permette, credo unico tra tutti i processi 
in user mode, di mandare il sistema in bugcheck (schermo blu o reset a 
seconda della configurazione)

(riguardo a Cygwin, ricordo che l'I/O su console è pesantemente filtrata, 
passa tutto prima per un'emulazione di termcap con emulazione ANSI. Un test 
potrebbe essere l'esecuzione del file batch della morte all'interno della 
shell 4NT, che quasi sicuramente - a giudicare da quello che riesce a fare 
- usa l'I/O di basso livello, e vedere se intercetta i backspace o se li 
lascia gestire al sistema)

Ricapitoliamo:
  - si tratta di un errore di puntatore nullo nel gestore delle finestre di 
console. DOS non ne è affetto. Windows 98 nemmeno. Tutta la famiglia NT lo è
  - si verifica nella fase di sganciamento, dopo la chiamata ad 
ExitProcess. Ebbene, una delle primissime cose (la prima è una chiamata a 
LdrShutdownProcess, per scaricare le dll) fatte da ExitProcess è comunicare 
a csrss tramite funzioni della famiglia Csr* che un processo è terminato 
(ricordate? mantiene una tabella dei processi attivi)
  - un solo programma ha il potere di mandare in halt il kernel

Tutti gli indizi sembrano puntare il dito contro un unico colpevole: csrss.exe.

Tutto questo ovviamente IMHO e dal basso di una crassa e abissale ignoranza 
in qualsiasi cosa che esuli dai sistemi operativi NT

La mia "scommessa" è che ExitProcess crasha prima di ritornare da 
CsrClientCallServer; cosa avvenga realmente in csrss è un vespaio da 
debuggare perchè CsrClientCallServer alla fine si risolve in una chiamata a 
NtRequestPort o NtRequestWaitReplyPort, comunque in un context switch che 
trasferisce il controllo a csrss, che come ho già detto non è (normalmente) 
debuggabile

Ora comunque lo provo, voglio almeno vedere di che errore si tratta


________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List