LoryOne

http://seclists.org/fulldisclosure/2010/Jun/205

M$ consiglia un workaround (un aggiramento) alla fonte: Non far eseguire HCP fino al rilascio della patch.
Faccio un sunto per i meno esperti.
Dunque:
L'articolo mostra un debugging in Assembly delle due funzioni API in C UrlUnescapeW() (Ricordate che tutte le funzioni che terminano con W agiscono su stringhe in Unicode che c'entra poco, ma lo ricordo) e HexToNum(). L'una (che richiama l'altra al suo interno) trasforma gli URL in hex (unescape, cioè quei famosi %2d%3e, ecc) in caratteri (codici ASCII ) attraverso sostituzione nella stringa stessa.
Ora, lo scopritore del baco si accorge che sebbene la seconda funzione sia ben programmata (Ci vuole poco d'altronde), la prima non verifica il codice di ritorno della chiamata alla seconda, quindi, come la solito, pensa di utilizzare il classico append di bytes per eseguire codice arbitrario.
Si accorge che l'utilizzo di hcp è fattibile solo passando come parametro (Il classico "?") svr= ecc,ecc. Lui propone svr=

test

Ma non basta perchè è necessario fare ricorso ad un url in hex per sfruttare la falla poc'anzi descritta. Certo, ma cio che segue il parametro DEVE essere eseguito come codice ... Girando un po si imbatte in defer Property e mette il link per far capire a cosa si riferisce.
Bene, avendo trovato cio che fa al caso suo, esegue una prova in locale dalla shell di Windows:

Che farà mai ? Lancia o meglio esegue la classica calcolatrice (ma può fare quello che vuole) da un url in HCP via unescape -> le due funzioni in C
Poi procede con attacchi da rete, ma cercate di capire voi ...

Quali conclusioni si possono ricavare ? Scrivere codice in C spesso non mostra alcune lacune che possono essere evidenziate solo dal debug in Assembly.

LoryOne

Non ho spiegato una cosa importante: se il vostro browser non riconosce hcp://, non esegue un'accidenti. Ecco perchè M$ inibisce alla fonte attraverso la manipolazione del registro.
Buona notte ragazzi e che palle, domani è di nuovo lunedì