Category: Computer Science

Address Space Layout Randomization: an Overview

Posted by frag – September 18, 2008

Internet and the proliferation of opensource programs that have given source code informations to exploit vulnerabilities of applications, made buffer overflow attacks more common and insidious methods to compromise software security.
Since these attacks require knowledge of the memory layout schema, the basic idea to design a countermeasure is to randomize locations of target memory areas. Address Space Layout Randomization is a method for randomizing the address space layout of a program. An analysis of benefits and drawbacks of the method is provided in order to discuss possible choices to avoid or reduce the risk of attacks.

Download full paper here

const pointer vs. pointer to const

Posted by frag – June 27, 2008


/*
ex. usage of a constant pointer to a (variable integer)
ex. how to fuck a pointer to a constant variable

*/
#include

int main(void)
{
const int c=0;
// constant pointer to a (variable) integer: can change the value of the var but not the pointer
int* const ptr1 = malloc(sizeof(int));
*ptr1 = 10;
*ptr1 = 100;

int t;
/* pointer to a constant integer: can change the pointer but not the variable (whatever is pointed to by ptr2 must be treated as a const, that’s why cannot change var value here). But of course if there are other pointers that point to the same area and are *not* const, var value can be changed. So, basically, with a const int* ptr2; we cannot change the area pointed to by ptr2 through ptr2 itself. But if *ptr2 (the value) is pointed to by another pointer… we can change it (*ptr2, the value)
*/

const int* ptr2 = malloc (sizeof(int));
int modvar = 10;

ptr2 = &modvar;
modvar = 100;

printf(“%d\n”, *ptr2);
return 0;
}

Veritas Cluster Script

Posted by frag – February 3, 2007

I cluster Veritas hanno maggiore flessibilità rispetto ai cluster commerciali proprietari delle varie software house (IBM, HP ecc).
Purtroppo le esigenze in ambito enterprise non possono essere soddisfatte da prodotti general purpose, tra l’altro molto costosi, a cui non è possibile chiedere modifiche “a misura di cliente”.
Lavorando sui cluster Veritas in ambito enterprise si è rivelata indispensabile l’esigenza di permettere agli utenti responsabili degli applicativi da clusterizzare, di gestire il cluster senza concedere permessi di amministratore che, spesso e volentieri, hanno portato l’utente a commettere errori disastrosi sull’intera architettura. La business continuity e il parallellismo attivo-passivo vengono seriamente messi a rischio se non si predispone di una gestione corretta dei permessi.
Veritas non ha pensato a tante situazioni, all’ordine del giorno per le aziende medio-grandi. Per esempio:

  • un utente deve poter gestire gli applicativi clusterizzati ad esso associati, senza poter controllare tutto il resto
  • le dipendenze dell’applicativo in cluster devono essere gestite dal cluster in modo automatico, in maniera verticale sia dal basso che dall’alto (e non in una sola direzione).

VCS РVeritas Cluster Script Р̬ un programma in Perl che si aggancia ai tool della riga di comando per la gestione di un cluster, che permette delle personalizzazioni a basso livello e risolve i problemi tipici delle dipendenze e dei permessi.
Offre una shell testuale molto semplice e UNIX compliant.

Per ulteriori informazioni contatta qui

Benchmark cpu

Posted by frag – December 3, 2006

Lo strumento di benchmark in questione è ubench scaricabile da http://www.phystech.com/download/ubench.html

Riporto i risultati del benchmark per CPU e memoria effettuato su:

bi-processore PIII con 1Gb di RAM

./ubench
Unix Benchmark Utility v.0.3
Copyright (C) July, 1999 PhysTech, Inc.
Author: Sergei Viznyuk
http://www.phystech.com/download/ubench.html
Linux 2.6.18 #6 SMP Sat Dec 2 17:22:33 CET 2006 i686
Ubench CPU: 79675
Ubench MEM: 88041
--------------------
Ubench AVG: 83858

Monoprocessore PIII Coppermine 256 Mb di RAM
./ubench
Unix Benchmark Utility v.0.3
Copyright (C) July, 1999 PhysTech, Inc.
Author: Sergei Viznyuk

http://www.phystech.com/download/ubench.html

Linux 2.6.18 #1 PREEMPT Mon Oct 9 22:22:18 CEST 2006 i686
Ubench CPU: 46855
Ubench MEM: 40090
--------------------
Ubench AVG: 43472

Tutorial postgresql: gestione rapida

Posted by frag – December 2, 2006

Una volta installato Postgresql (installazione dipendente dal sistema operativo e dal gestore dei pacchetti) il numero dei comandi che si possono impartire alla nostra base di dati è enorme.
Prima di tutto, se non è stato già fatto durante l’installazione, bisogna creare l’utente che accederà direttamente alla base di dati per evitare che lo faccia root, con ovvi rischi di sicurezza.

Le operazioni che seguono vengono solitamente effettuate durante l’installazione.
E’ bene fare un controllo prima di proseguire.

Creiamo l’utente con
$ adduser postgres

Creiamo la directory data, la directory dove Postgresql memorizzerà le tabelle

$ mkdir /usr/local/pgsql/data
Quindi assegniamo i permessi all’utente appena creato
$ chown postgres /usr/local/pgsql/data

Le operazioni che seguono invece sono tipicamente eseguite dopo l’installazione standard

Loggarsi come utente postgres, che in realtà è il root del database ed inizializziamo la directory “data” appena creata
$ su - postgres
$ /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data

ATTENZIONE: se la fase di installazione ha già creato questa directory, il sistema ritorna un errore quando si cercherà di re-inizializzarla. Se si vogliono fare le cose in modo pulito dovremmo rimuovere il contenuto della /usr/local/pgsql/data e ripetere initdb come nell’ultimo comando.

Per avviare il database all’avvio del sistema consultare la documentazione del proprio sistema operativo o distribuzione GNU/Linux.

Database di test
Una volta installato è saggio creare un database di prova per controllare che tutto sia al posto giusto


$ su - postgres
$ /usr/local/pgsql/bin/createdb test
$ /usr/local/pgsql/bin/psql test
Welcome to psql 8.1.3, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g or terminate with semicolon to execute query
\q to quit
test=#

Un modo per controllare la base di dati senza ricorrere alla shell interattiva o al php via web consiste nell’installare pgadmin, un magnifico gestore per postgresql.

Creare utenti
Per creare utenti per il DBMS è necessario lanciare un createuser da postgres in modo che il nuovo utenti potrà creare database ma non creare nuovi utenti.

postgres@localhost:~$ createuser nuovoutente
Shall the new user be allowed to create databases? (y/n) y
Shall the new user be allowed to create more new users? (y/n) n
CREATE USER
postgres@localhost:~$

Cambiare la password
Se ci colleghiamo al database come utente postgres, possiamo modificare la password di accesso dell’utente proprietario del database:

postgres@localhost:~$ psql nomedatabase
Welcome to psql 7.4.8, the PostgreSQL interactive terminal.
...
nomedatabase=# alter user nomeutente password 'nuovapassword';
ALTER USER
nomedatabase=#

In questo modo nuovoutente può essere utilizzato da script accessibili da Internet. Per permettere connessioni TCP/IP bisogna modificare pg_hba.conf e riavviare il PostgreSQL server per attivare le modifiche:


#TYPE DATABASE USER IP-ADDRESS IP-MASK METHOD
host web webuser 127.0.0.1 255.255.255.255 md5

Creare un db al volo
Per creare una base di dati da linea di comando

postgres@localhost:~$ createdb -h localhost -U utenteweb -W base-dati-web

Con l’opzione -W si forza la richiesta della password
con l’opzione -h si forza l’utilizzo di una connessione TCP/IP.

Connessione
Per connettersi alla base di dati appena creata:

utente@localhost:~$ psql nome-database nome-utente

Dump del database
pg_dump dbname > file.dmp

I dump creati con pg_dump sono consistenti.
Tutti gli aggiornamenti della base di dati durante l’esecuzione di pg_dump non saranno memorizzati nel file.dmp creato.
pg_dump non blocca le altre operazioni in esecuzione sul database, ad eccezione delle operazioni che devono operare in modalità esclusiva, come per esempio il VACUUM FULL per la manutenzione).

Restore del database
psql nomedatabase < infile

nomedatabase non viene creato. Bisogna crearlo prima di fare il restore (per esempio con createdb -T template0 nomedatabase)

Una volta eseguito il restore si consiglia di eseguire un ANALYZE su ogni database in modo che l’optimizer abbia statistiche valide.
Eseguire quindi vacuumdb -a -z to VACUUM ANALYZE all databases; oppure manualmente VACUUM ANALYZE.

E’ possibile anche fare il dump di un database remoto, da una macchina all’altra con
pg_dump -h host1 dbname | psql -h host2 dbname
(esegue il dump del dbname sull’host1 sull’host2).

Per fare il backup dell’intero cluster si usa il comando
pg_dumpall > cluster.dmp

e per il restore dell’intero cluster
psql -f cluster.dmp template1

Ovviamente bisogna essere il superuser del database dovendo fare il dump di tutti i db e di tutti gli utenti ad essi associati.

Usare dump compressi
Per comprimere il dump di un database molto grande
pg_dump dbname | gzip > data.dmp.gz

e il comando duale per ricaricare (dopo aver creato il database)
createdb dbname
gunzip -c data.dmp.gz | psql dbname oppure cat data.dmp.gz | gunzip | psql dbname