viklog

Questa volta Vista l’ha fatta grossa! Dopo una pulizia del disco era scomparsa la modalità ibernazione e tutte le opzioni associate ad essa. È vero, la pulizia del disco elimina i file di ibernazione, ma non avrei mai immaginato che avrebbe disabilitato tali file necessari all’ibernazione o alla sospensione ibrida.

Il bug è noto, la soluzione si trova sul sito della Microsof stessa: apriamo il Propt di comandi come amministratori (è sufficiente cliccare sul destro sull’icona del Prompt dei comandi e scegliere Esegui come amministratore) e da li digitiamo:

powercfg -h on

Controllate: l’ibernazione sarà nuovamente selezionabile. C’è da notare che il SP1 l’ho scaricato ma non ancora installato, per cui non so se questo bug esiterà ancora dopo l’aggiornamento.

Vista, ibernazione, sospensione ibrida, scomparsa, bug

Popularity: 44% [?]

Nell’ambito dello sviluppo di sistemi software mi è sembrato molto interessante il modello denominato eXtreme Programming (XP), un modello di sviluppo agile molto meno rigido rispetto ad altri metodi si sviluppo. Le parole chiave di questo questo approccio sono: semplicità, comunicazione e semplicità. In realtà, la prima volta che ho sentito parlare di eXtreme Programming mi sono immaginato a programmare con il portatile legato alla cintura mentre scalavo una parete…

extreme programming 5 by exacq

Per capire di cosa stiamo parlando, vi elenco in breve alcune delle pratiche che caratterizzano XP.

XP pratices

• Planning game: è la pratica che trasforma la classica analisi dei requisiti in un “gioco”. Si basa sulle user stories, descrizioni in linguaggio naturale di ciò che l’utente vuole che il software faccia.
  • Ad ogni user story gli utenti stessi assegnano una priorità, mentre gli sviluppatori un costo.
  • Ovviamente si tratta di una pianificazione informale
• Small release: si sviluppa i vari moduli del sistema software in modo incrementale, ad ogni ciclo si fanno piccole release.
• Whole team: tutto il team partecipa a ciascun aspetto dello sviluppo software in qualche modo.
• Collettive ownership: deriva dalla pratica precedente; la proprietà intellettuale del codice appartiene a tutto il gruppo.
• Metaphore: per descrivere una funzionalità del sistema software nel gruppo si usa una metafora. Ad esempio, per descrivere un gruppo di agenti software in azione “lo sciame di piccole api volano sui fiori e rientrano all’alveare solo una volta terminato il loro compito”. Aiuta a far sì che il team usi un sistema comune di nomi di entità, tale che sia immediato trovare, per uno sviluppatore, una certo modulo in base al nome, o sia chiaro dove inserire le nuove funzionalità appena sviluppate.
• Test-Driven Development: si scrive il codice sulla base dei test stessi. In poche parole si scrivono prima i test, poi si sviluppa l’applicazione finché non supera positivamente il test.
  • Questo processo è sempre accompagnato da xUnit (jUnit, cUnit, …)
• Refactoring del codice senza pietà! Uno dei motti del XP è “se un metodo necessita di un commento, riscrivilo!” (codice auto-esplicativo).
• Pair programming: si programma in coppia, il driver scrive il codice mentre il navigatore controlla il lavoro del suo compagno in maniera attiva.
  • Statisticamente è risultato un ottimo approccio nello sviluppo software, nonostante possa sembrare uno spreco di risorse umane
• Coding standard: a causa del Pair programming e Whole team si è reso necessario il raggiungimento di convenzioni di codifica fra gli sviluppatori.
• Idealmente il cliente è sempre disponinibile, in ogni fase del processo di sviluppo. Se gli sviluppatori hanno un dubbio, si rivolgono direttamente a lui.

Follia o realtà?

Posso dire, per esperienza diretta, che alcune di queste pratiche (come Test-Driven Development e Coding standard) sono delle ottime linee guida per scrivere codice di qualità. Altre, invece, mi sembrano delle vere e proprie follie. Basti pensare al 13^o principio: a inizio di ogni giornata si svolge una riunione di 15 minuti fra tutti i componenti del team di sviluppo, in cui ognuno espone cosa ha fatto il giorno prima, cosa pensa di fare quel giorno e le problematiche affrontate. Questa riunione si svolge rigorosamente in piedi, in modo tale che nessuno di dilunghi in inutili chiacchiere. Evidentemente questo sembra più una sorta di terapia di gruppo.

Negli USA questo modello di sviluppo software sta riscontrando grande successo, sopratutto nelle software house che dispongono di “carne fresca”. In Italia, invece, non credo esista un azienda che utilizzi questo modello, come sono pochissime le aziende che lo fanno in tutta Europa.

pair programming with duck by ysano

Vi lascio un paio di link sull’argomento:

• XProgramming.com - an Agile Software Development Resource
• Extreme Programming: A Gentle Introduction

- Warning: Divide by zero.

eXtreme Programming, modelli di sviluppo, programmazione agile, software, sviluppo, XP

Popularity: 40% [?]

Un mio amico che insegna alle medie mi ha detto di aver usato questa “lavagna magica” per insegnare la fisica e la matematica a 3 ragazzini che abitano in un paese sperduto della Sardegna, ragazzini impossibilitati a raggiungere la più vicina scuola.

A parte il fattore educativo, io dico: lo voglio!!! Voi no?

- Warning: Divide by zero.

Technorati tag: Fattore umano, interazione uomo-macchina, video, scuola

Popularity: 31% [?]

In ritardo di più di una settimana ecco a voi il secondo episodio della serie Vista features, episodio in cui vi parlerò di ASLR: Address Space Load Randomization.

L’argomento, però, richiede alcune conoscenze più o meno tecniche, come il funzionamento della memoria centrale (la RAM) per poi arrivare al “mitico” buffer overflow. Cercherò anche in questo caso di colmare un po’ di lacune in maniera breve e davvero semplice. Chi conosce già l’argomento salti direttamente a Obiettivi di ASLR.

La RAM

La RAM (Random Access Memory) è la memoria centrale del nostro PC, dove vengono caricati i programmi per essere eseguiti. Il primo requisito della RAM è che l’accesso ai dati presenti al suo interno sia velocissimo: se al Sistema Operativo interessa una certa informazione deve poter accedere direttamente a essa, senza dover scorrerne altre mille prima di trovare quella richiesta. Per adempire al suo dovere la RAM è divisa in “celle” di dimensione prefissata, solitamente 512 byte. Ognuna di queste celle ha un indirizzo (indirizzo di memoria), grazie al quale è possibile alla CPU raggiungere direttamente quella cella. Per cui nella RAM troviamo diversi applicativi, ognuno dei quali è salvato in una o più celle e l’accesso ai dati di una singola cella è diretto. Immaginate la RAM come una lunghissima via, dove ogni cella ha un proprio numero civico. Se, per arrivare al numero 1042 dovessimo scorrere tutti i portoni precedenti la velocità di un PC sarebbe l’1% di quella attuale. Invece ogni numero civico è raggiungibile in maniera semplice perché il “postino” sa quanti metri (o kilometri) deve saltare per arrivare direttamente al 1042.

Nell’esempio Firefox ha indirizzo di memoria 00000003 e occupa 2 celle, mentre Messenger ha indirizzo 0000FFFE e occupa 4 celle. Gli indirizzi normalmente sono espressi in esadecimale per poterli mantenere in forma compatta. In realtà, di solito in alto si trovano gli indirizzi più elevati e in basso quelli minori, io ho invertito per comodità di rappresentazione.

Buffer Overflow

Buffer overflow (in breve BOF) letteralmente significa “trabocco del buffer”. Cosa succede: un programma riceve in input una quantità di dati superiori a quelli attesi. Ora, se il programma implementa un controllo dell’input probabilmente verrà semplicemente sollevato un errore. Se questo controllo non c’è, o non è ben strutturato, allora si incappa proprio in un buffer overflow. Per cui il risaltato è che questi dati in eccesso possono finire in zone della memoria dove sono presenti altri dati sovrascrivendoli: questo è il primo passo verso un attacco. Ovviamente esistono diverse forme di questo tipo di exploit, ma non starò qui a divulgarmi. E’ sufficiente capire che in questo modo è possibile inserire del codice maligno all’interno del nostro sistema e farlo eseguire.

Obbiettivi di ASLR

Ammettendo che un programmatore mal intenzionato sia riuscito a individuare delle vulnerabilità sfruttabili attraverso un attacco di tipo buffer overflow, il malware da esso scritto ha bisogno delle librerie di Windows (Windows API) per potersi insidiare in maniera (più o meno) permanente all’interno della macchina. Il fatto che, queste librerie, avevano un indirizzo in memoria più o meno fisso in ambiente XP, ha sempre permesso agli attaccanti alcune assunzioni sull’indirizzo stesso. L’obiettivo di ASLR è proprio quello di rendere difficile la localizzazione delle Windows API in una maniera molto semplice: caricando le DLL di sistema ed eseguibili annessi, a indirizzi diversi ad ogni avvio.

Soluzioni implementate

All’avvio tutti processi dell’utente vengono allocati in memoria a partire da un certo indirizzo. Mentre con l’introduzione di ASLR l’indirizzo di partenza viene scelto in maniera casuale fra 256 possibili indirizzi all’interno dei primi 16 MB assegnati all’utente. Per quanto riguarda le librerie di sistema il meccanismo è lo stesso: c’è un indirizzo di partenza che si trova nella parte “bassa” della memoria, le librerie vengono allocate dal basso verso l’alto e il reale indirizzo di partenza è scelto all’interno dei 16 MB precedenti all’indirizzo di partenza prestabilito. Se questo non bastasse, le varie DLL di sistema conosciute vengono allocate in ordine casuale. Infine, ci sono altri componenti della memoria il cui indirizzo viene scelta in maniere più o meno casuale, e sono:

• l’User stack, dove risiedono le strutture dati relative ai processi dell’utente;
• i driver dei vari dispositivi;
• (persino) l’immagine del kernel.

Quello che succede si vede bene nella prossima immagine:

Due PC in cui è presente Windows XP hanno immagine di memoria praticamente uguale. Questo implica due cose: la prima è che nell’implementare un attacco di tipo buffer overflow, il programmatore può fare diverse ipotesi a priori sugli indirizzi da colpire. La seconda cosa è che un attacco riuscito su una macchina, facilmente funzionerà anche sulla seconda, ovvero in una rete di computer si può puntare a colpire diverse macchine.

Mentre i due computer con Vista, non solo hanno i vari processi o servizi shiftati uno rispetto all’altro, ma l’ordine delle componenti fondamentali del sistema è anche esso diverso.

Vedere ASLR in azione

Per vedere ASLR in azione sul proprio PC è necessario Process Explorer (chi ha Vista deve assolutamente averlo!), una evoluzione del classico Task Manager di Windows. E’ sufficiente guardare l’indirizzo di memoria di una DLL, ad esempio kernel32.dell e verificare che alla prossima sessione quell’indirizzo sarà diverso. Nel mio caso prima era 0×77c10000, al successivo riavvio era 0×770f0000.

Conclusioni

Ci sarebbe ancora molto da dire su ASLR e sulla sua implementazione. Ad esempio nel mio articolo non ho fatto alcuna differenza fra la memoria virtuale e quella reale: il mapping degli indirizzi di memoria dal “punto di vista del Sistema Operativo” nella reale memoria hardware non è così semplice che può apparire leggendo questo articolo. Andare al fondo dell’argomento, però, avrebbe reso il post una guida di programmazione C/C++/.Net, cosa che non mi interessa. Inoltre trovare materiale su ASLR si è rilevato più difficile di quanto mi aspettassi, in italiano c’è il nulla.

Concluderei con due note:

1. Questo meccanismo per la protezione dalle vulnerabilità di tipo buffer overflow è già stato implementato nel kernel Linux da diversi anni. Questo, a mio avviso, non sminuisce lo sforzo implementativo della Microsoft.
2. ASLR non risolve il problema ma rende il compito decisamente più difficile all’attaccante.

Link sull’argomento

• Attacchi alle applicazioni basate su Buffer Overflow | InTiLinu, in questo articolo viene spiegato in maniera davvero efficace e comprensibile a tutti che cosa è un BOF.
• Random Access Memory su Wikipedia.
• Address Space Layout Randomization in Windows Vista, dal blog di un personaggio autorevole sull’argomento!
• Funny Vista Tricks with ASLR, per chi vuole mettere le mani in pasta in ASLR

Vi saluto, ci vediamo fra qualche tempo per l’Episodio 3.

– Warning: Divide by zero.

Technorati tag: Vista, Vista features, ASLR, Address Space Load Randomization, RAM, memoria, informatica, rubriche

Popularity: 23% [?]

Ne ho sentito parlare prima da Emanuele e poi da Nicopi, sicché ho deciso di aderirvi anch’io nella speranza di aumentare la visibilità del mio blog. Il Bloggatore è un idea semplice quanto funzionale: aggregare feed di blog italiani che parlano di informatica e dintorni. Ora tutti i miei post della categoria informatica (che ho dovuto creare appositamente…) saranno pubblicati sul Bloggatore.

Donkeys with computers in Greece by davesag

Per iscriversi ci vuole un attimo: segnalate il vostro blog con l’apposito form, dopodiché sarà sufficiente inserire l’antipixel nel proprio blog e il gioco è fatto.

Visto che mi trovo voglio comunque dire 2 cose alla redazione de Il Bloggatore:

1. Un maggiore controllo sulla presenza di articoli non inerenti all’informatica. Ne ho visti un paio.
2. Da quando esiste Internet per antipixel si intende un immagine di 80×15 pixel. Per questo ne ho disegnate due mentendo i colori di quello già esistente: , . Se vi piacciono potete farne l’uso che preferite.

In bocca al lupo a tutta la redazione de Il Bloggatore.

- Warning: Divide by zero.

Technorati tag: Il Bloggatore, web, feed, informatica

Popularity: 26% [?]