slacky.eu

samiel ha scritto:Scusate l'ignoranza, ma una volta scaricato il workaround
che mi pare un file .c come lo uso? Va aggiunto semplicemnte
nella dir dei sorgenti prima di ricompilare? Ma in quale sub/sub/dir?

Non è una patch, ma un programma che impedisce l'uso della system call incriminata. Credo che vada avviato ad ogni riavvio.
Ma qui http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464953 parlano di strani freeze del sistema.
IMHO meglio aggiornare il kernel, tra l'altro se non si vuole passare al 2.6.24.2 è uscito anche il 2.6.23.16 per correggere tale bug

JohnnyMnemonic ha scritto:samiel, posto che il file si chiami bug.c ti basta compilarlo con

Codice: Seleziona tutto

gcc bug.c

e poi eseguirlo con

Codice: Seleziona tutto

./a.out

A questo punto si dovrebbe aprire una shell di root

OPS scusa avevo letto male il messaggio

Lui parla del workaround, cioè della soluzione temporanea, non dell'exploit, o ho capito male io?

Io mi riferivo all'utilizzo corretto del workaround.
Pensavo, come in altri casi, che si dovesse aggiungere
in una dir dei sorgenti del kernel e poi ricompilarlo.
Ma, almeno dal sito da cui lo ho scaricato, non si capisce
dove andrebbe messo. DIci che ogni volta andrebbe
lanciato? Certo, a questo punto diventa "obbligatorio"
passare al 2.6.24.2...

M.

conraid ha scritto:

samiel ha scritto:Scusate l'ignoranza, ma una volta scaricato il workaround
che mi pare un file .c come lo uso? Va aggiunto semplicemnte
nella dir dei sorgenti prima di ricompilare? Ma in quale sub/sub/dir?

Non è una patch, ma un programma che impedisce l'uso della system call incriminata. Credo che vada avviato ad ogni riavvio.
Ma qui http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464953 parlano di strani freeze del sistema.
IMHO meglio aggiornare il kernel, tra l'altro se non si vuole passare al 2.6.24.2 è uscito anche il 2.6.23.16 per correggere tale bug

Segnalo anche il rilascio di 2.6.22.18 per risolvere lo stesso bug (testato con successo), per chi usa il ramo 2.6.22.

su debian è stato fissato il problema.
ricevo questa emeil che dice:
---------------------------------------------------------------------
Debian Security Advisory DSA-1494-1 security@debian.org
http://www.debian.org/security/ Florian Weimer
February 11, 2008 http://www.debian.org/security/faq
----------------------------------------------------------------------

Package : linux-2.6
Vulnerability : missing access checks
Problem type : local
Debian-specific: no
CVE Id(s) : CVE-2008-0010 CVE-2008-0163 CVE-2008-0600

The vmsplice system call did not properly verify address arguments
passed by user space processes, which allowed local attackers to
overwrite arbitrary kernel memory, gaining root privileges
(CVE-2008-0010, CVE-2008-0600).

In the vserver-enabled kernels, a missing access check on certain
symlinks in /proc enabled local attackers to access resources in other
vservers (CVE-2008-0163).

For the stable distribution (etch), this problem has been fixed in version
2.6.18.dfsg.1-18etch1.

In addition to these fixes, this update also incorporates changes from the
upcoming point release of the stable distribution.

The old stable distribution (sarge) is not affected by this problem.

The unstable (sid) and testing distributions will be fixed soon.

We recommend that you upgrade your linux-2.6 package.

Upgrade instructions
--------------------

wget url
will fetch the file for you
dpkg -i file.deb
will install the referenced file.

If you are using the apt-get package manager, use the line for
sources.list as given below:

apt-get update
will update the internal database
apt-get upgrade
will install corrected packages

You may use an automated update by adding the resources from the
footer to the proper configuration.


Debian GNU/Linux 4.0 alias etch
-------------------------------

Stable updates are available for alpha, amd64, i386, ia64 and s390.
The remaining updates will follow.

Source archives:

edit seguono link anche per le altre versioni e architetture, se vi servono ditelo

ma quindi l'upgrade al 2.6.24.2 risolve il problema?

Vito ha scritto:ma quindi l'upgrade al 2.6.24.2 risolve il problema?

si

danix85 ha scritto:in effetti anche io non ho troppa voglia di ricompilare il kernel, mi chiedevo piuttosto, come si può sfruttare una vulnerabilità del genere senza presupporre un uso windowsiano (mi sia concesso il termine) del pc??
Voglio dire, non è che si tratta di un .exe che tu rinomini in .gif e lo metti su un sito web, io ci clicco sopra e lo eseguo, no??
Mi domando queste cose non conoscendo totalmente la materia in questione, ma immagino che per poter sfruttare la vulnerabilità serva quantomeno ottenere l'accesso remoto al pc su cui si vogliono ottenere i privilegi di root... questo allora mi fa pensare che serva una connessione tramite ssh o qualcosa del genere, no?? quindi per sfruttare la vulnerabilità bisogna ottenere la password dell'utente semplice, loggarsi in remoto e sfruttare l'exploit... il tutto non avendo sshd attivo è quantomeno difficile, giusto??

Chiaritemi questo punto per favore, perchè almeno vedo cosa posso fare per mettermi un po' più al sicuro...

Grazie mille...

anche nei sistemi con utente singolo è lo stesso.
non serve ne l'utente e ne la pass.
basta che si abbia un exploit che ATTACCA un demone preciso.
se tul tuo pc giara apache, un lamer qualsiasi fa un port scan su range predefiniti sulla porta 80, becca il tuo ip con 80 open, esegue l'exploit ed ottiene una shell, poi da li esegue l'exploit locale e diventa l'amministratore del tuo sistema.
famossimi furono gli exploit per samba che dava direttamente i privilegi di root, come quelli per telnet su SUNOS e Solaris.
quelli hanno infettato milioni di sistemi.
ovviamente un admin attento che mantiene le versioni dei prog che girano sulla sua makkina aggiornata (soprattutto ssh, apache, telnet, ftp, imap, considerato che 22, 80, 23, 21, 25 sono le porte preferite dai lamer da inserire nei portscan visto che restituiscono maggiori ip)sta + tranquillo, ma molte vulnerabilità vengono scoperte in ritardo quando l'exploit privato circola tra i lamer/hackers maggiori,ed a quel punto passa un pò prima che venga reso publico e quindi fixato il bug e rilasciata la patch/aggiornamento.

aLvArO ha scritto:

danix85 ha scritto:in effetti anche io non ho troppa voglia di ricompilare il kernel, mi chiedevo piuttosto, come si può sfruttare una vulnerabilità del genere senza presupporre un uso windowsiano (mi sia concesso il termine) del pc??
Voglio dire, non è che si tratta di un .exe che tu rinomini in .gif e lo metti su un sito web, io ci clicco sopra e lo eseguo, no??
Mi domando queste cose non conoscendo totalmente la materia in questione, ma immagino che per poter sfruttare la vulnerabilità serva quantomeno ottenere l'accesso remoto al pc su cui si vogliono ottenere i privilegi di root... questo allora mi fa pensare che serva una connessione tramite ssh o qualcosa del genere, no?? quindi per sfruttare la vulnerabilità bisogna ottenere la password dell'utente semplice, loggarsi in remoto e sfruttare l'exploit... il tutto non avendo sshd attivo è quantomeno difficile, giusto??

Chiaritemi questo punto per favore, perchè almeno vedo cosa posso fare per mettermi un po' più al sicuro...

Grazie mille...

anche nei sistemi con utente singolo è lo stesso.
non serve ne l'utente e ne la pass.
basta che si abbia un exploit che ATTACCA un demone preciso.
se tul tuo pc giara apache, un lamer qualsiasi fa un port scan su range predefiniti sulla porta 80, becca il tuo ip con 80 open, esegue l'exploit ed ottiene una shell, poi da li esegue l'exploit locale e diventa l'amministratore del tuo sistema.
famossimi furono gli exploit per samba che dava direttamente i privilegi di root, come quelli per telnet su SUNOS e Solaris.
quelli hanno infettato milioni di sistemi.
ovviamente un admin attento che mantiene le versioni dei prog che girano sulla sua makkina aggiornata (soprattutto ssh, apache, telnet, ftp, imap, considerato che 22, 80, 23, 21, 25 sono le porte preferite dai lamer da inserire nei portscan visto che restituiscono maggiori ip)sta + tranquillo, ma molte vulnerabilità vengono scoperte in ritardo quando l'exploit privato circola tra i lamer/hackers maggiori,ed a quel punto passa un pò prima che venga reso publico e quindi fixato il bug e rilasciata la patch/aggiornamento.

Quintessenza: vinci la pigrizia, aggiorna il kernel.

Anche sul 2.6.24.2 sussistono dubbi, il minore dei mali.

Mario Vanoni

comunque col 2.6.24.2: Per cui risolve!
M.

cosa di cui non ero a conoscenza, grazie a tutti per la discussione interessante, piena di info tecniche e suggerimenti, come sempre ragazzi siete preparatissimi e puntuali ,la via più breve per fixare il problema? passare al nuovo kernel 2.6.24.2, okay messaggio ricevuto

WOO I GOT MY (OWN) ROOT!

Ma sto coso è comodissimo!

beh comunque pure questi sono sfiziosi, giusto un po' stagionati...
Raga, comunque, aparte gli scherzi, ste cose aprono nuovi orizzonti, di voglia di scoprire ma anche di insicurezza profonda...

http://www.slackware.com/security/viewe ... ity.562341

Grazie Pat

Non era male se Pat avesse rilasciato anche l'aggiornamento per la Slack 11... ho un serverino che non ho ancora aggiornato.

Qualcuno ha provato ad installare l'aggiornamento della 12 nella 11 ?