Newsgroup: it.comp.sicurezza.varie
Titolo: Ascolto su porta auto-costruito pericoloso ?

Salve a tutti,
nel tentativo di costruire un ripetitore di porta alla fine ho tirato fuori
un chat server (forse perche' era tanto che volevo farlo :-), questo
server ascolta sulla porta 3000, riceve stringhe dai client (telnet) e
ogni stringa che arriva da un client la manda a tutti gli altri client.
Vorrei sapere se una volta connesso a internet questa porta aperta
(3000) puo' essere un varco per qualche malintenzionato (bug nella
sicurezza del SO). Uso Win95 4.00.950B, connessione a internet
"normale", ip dinamico.
TIA
Carlo

 wrote:

Si, puo' essere un pericolo:
Al di la del fatto che su Windows ogni porta aperta e' potenzialmente
una fonte di punti di attacco (vedi in passato la storia dei dati
OOB) il problema e' che su Windows i programlmi non hanno limiti
"seri" di accesso alle risorse di sistema.
Se qualcuno trova il modo sfruttando un banale buffer overflow
del tuo programma di fargli eseguire una manciata di istruzioni
mandata da lui.... fa fare quello che vuole al tuo computer
(basta che ci sia una semplice chiamata a gets() e sei fregato..)
Ovviamente tu dirai "Il mio programma e' sicuro, non ci sono buffer
overflow exploitabili", la mia visione del mondo e' che:
- I programmi senza bug non esistono.
- Se per una "cosa" non c'e' un exploit significa semplicemente
  che l'exploit non e' _ancora_ stato trovato, e' questione
  di tempo :)
Ciao,
-- 
Andrea

cabo...@iol.it
 wrote:
 >Vorrei sapere se una volta connesso a internet questa porta aperta
 >(3000) puo' essere un varco per qualche malintenzionato (bug nella
 >sicurezza del SO). Uso Win95 4.00.950B, connessione a internet
Si, basta che il tuo programma abbia problemi di sicurezza (per esempio,
hai sempre accuratamente evitato di usare sprintf?).
-- 
ciao, | [Per rispondere togli "toglimi" dal mio indirizzo.]
Marco | * The Internet is full. Go away.  -- Joel Furr *

"normale", ip dinamico.
Dunque, le regole del gioco sono:
1) Verifica, ogni volta che ricevi dati, di leggere SOLO quelli che ti
   aspetti. Di regola, non usare MAI:
	strcpy
	strcat
	strlen
	strchr  #
	strstr  #
	strrchr	#
	*sprintf
	gets
   # = usabile se prima ci si assicura della lunghezza della stringa. Un
       metodo da baLuba e' per es.
		buffer[sizeof(buffer)-1]='\0';
       e con questo eventuali puttanate da overflow su 'buffer' le togli,
       o almeno togli quelle stupide.
 
2) Ogniqualvolta gestisci dei dati e hai il problema dei caratteri validi,
   fai una lista dei caratteri validi (A-Z, 0-9, a-z, ecc.) e uccidi tutti
   gli altri, sostituendoli con uno *zero* [Nota di Leonardo Macellaio]
3) Non usare mai direttamente i dati inviati dal client
4) TAAB. "There's Always A Bug". Quindi logga anche le cose sospette, e fa
   preparativi per il giorno che ti fottono, perche' quel giorno arrivera'
   (consolati pensando che prima dovranno sputare sangue e veleno :-) ).
Leonardo
".signature": bad command or file name

nu...@tin.it
 wrote:
 >- Se per una "cosa" non c'e' un exploit significa semplicemente
 >  che l'exploit non e' _ancora_ stato trovato, e' questione
 >  di tempo :)
Beh, io su qmail ci scommetterei abbastanza...


hai sempre accuratamente evitato di usare sprintf?).
In realta' uso Delphi 3, comunque non ho usato nessuna funzione analoga
alla sprintf. Qual'e' il problema con questa funzione ?
(conosco abbastanza bene il C ma non riesco a immaginarlo)
Ciao
Carlo

  di tempo :)
E' quello che sospettavo ma e' molto triste ammetterlo....
Ciao
Carlo

   (consolati pensando che prima dovranno sputare sangue e veleno :-) ).
Grazie per i preziosi consigli.
Carlo

cabo...@iol.it
 wrote:
 >In realta' uso Delphi 3, comunque non ho usato nessuna funzione analoga
 >alla sprintf. Qual'e' il problema con questa funzione ?
Che se gli fai scrivere oltre il buffer finisci nello stack. Con un po'
di pazienza si puo` costruire una stringa tale che possa essere
eseguita: basta modificare lo stack in modo che alla fine della funzione
chiamata si salti al tuo codice.


 >3) Non usare mai direttamente i dati inviati dal client
Due domande, una risposta:
sprintf(buffer, formato, a, b, c, d, e, ....)
Uno o piu' dati a, b c d e.. sono forniti, direttamente
o inidrettamente, dal client --> Basta che "metto" dei dati
abbastanza grandi in questi "campi".. e scrivo nello stack.
(Con le conseguenze gia' spiegate per gets).
Sono da anni nel coder-committe di Undernet, scriviamo
e manteniamo il codice per il server IRC che, per vari
motivi "psicologici" credo possa accreditarsi la palma
di servizio di rete piu' "attaccato" di Internet.. quindi
un minimo di esperienza ce l'ho... ciononostante quando
un annetto fa qualcuno mi ha chiesto qui' di buttare giu'
uno stupido "nologin", una cosa che scrive una cosa sul 
video, aspetta un <cr> e poi chiude la connessione... ci
ho pensato su un bel po'.
Ho scritto il codice (15 righe), l'ho riletto, l'ho messo
da parte e riletto il giorno dopo, e poi quello dopo
ancora... al terzo giorno ho trovato un bug di sicurezza
(poteva essere usato per exploitarmi il root !). Fai tu :)
Finche' si lavora con un sistema unix dove tu puoi
associare una porta a un servizio che gira setuid con
privilegi molto ridotti (chroot eccetera) puoi
"proteggere" il grosso della tua macchina da attacchi
di questo tipo.
Nel momento in cui sei su un S.O. _NON_ multiutente come
Windows in cu un processo e' di fatto padrone della macchina
tutto diventa molto piu' difficile.
Ciao,
Andrea
-- 
Andrea

Adesso e' tutto chiaro, grazie a tutti per le risposte.
Carlo