Ce ver ne représente pas une énorme menace car il n'est que peu répandu. Mais comme il profite de 3 failles de sécurités différentes pour se propager, il faut y faire attention. Les 3 failles concernent (plus de détails dans l'article complet) :
1- XML-RPC for PHP Code Execution Vulnerability
2- AWStats Input Validation Vulnerability
3- WebHints Shell Command Injection Vulnerability
Le ver, une fois le système infecté, va ouvrir une trappe (ou porte dérobée) sur le port UDP 27015.
Des correctifs sont accessibles en ligne :
1- XML-RPC 1.1.1 est couvert [2]
2- AWStats 6.4 est couvert [3]
3- Il n'y aurait pas encore de patch disponible pour Webhints
Mettez à jour vos systèmes, si ce n'est pas déjà fait. Les 3 failles de sécurité sont :
1- XML-RPC for PHP Code Execution Vulnerability
Secunia Advisory : SA15852
Lien : http://secunia.com/advisories/15852/
XML-RPC est utilisé dans plusieurs outils de Weblog (ou Blog) comme NucleusCMS, postNuke, WordPress, etc, et dans bien d'autres applications orientés Web. Vérifier que votre outil a bien été mis à jour pour utiliser XML-RPC 1.1.1 ou ultérieur. Ou simplement, désactiver cette fonction si vous ne l'utilisez pas !
2- AWStats Input Validation Vulnerability
Secunia Advisory : SA14299
Lien : http://secunia.com/advisories/14299/
Cette faille permet, en forgeant des adresses de fichiers de log et en les passant au script awstats.pl, de pouvoir lancer des commandes à distance et de récupérer le contenu de certains fichiers de log. AWStats 6.4 corrige ce problème.
3- WebHints Shell Command Injection Vulnerability
Secunia Advisory : SA15652
Lien : http://secunia.com/advisories/15652/
Peu d'information sur celle-ci, si ce n'est que l'utilisateur peut rentrer des informations et que Webhints n'est que peu soucieux de ces entrées. Ainsi un utilisateur mal-intentionné pourrait abuser du système pour forger des entrées permettant l'exécution de commandes à distance.
Le vers, une fois le système infecté, va ouvrir une trappe (ou porte dérobée) sur le port UDP 27015.
Par cette trappe un attaquant distant pourra avoir accès à la machine. Le vers tentera ensuite de se propager vers d'autres systèmes à infecter en forgeant de nouvelles adresses IP à aller attaquer. Il tente ensuite de télécharger des fichiers dans le répertoire /tmp/.temp, et ouvre 2 trappes une avec un SHELL sur une adresse IP spécifique sur le port 8080, et l'autre sur un canal IRC.
Je me permets d'ailleurs de vous renvoyer à ce journal où les premières variantes de ce virus étaient décrites : http://linuxfr.org/~b_adele/20314.html
Aller plus loin
- [1] Alerte Symantec Plupii.C (2 clics)
- [2] XML-RPC advisory (1 clic)
- [3] AWStats 6.4 (1 clic)
- [4] Alerte Symantec Plupii (1 clic)
# Un commentaire en alexandrins
Posté par Olivier Serve (site web personnel) . Évalué à 10.
Voilà, c'est fait.
[^] # Re: Un commentaire en alexandrins
Posté par totof2000 . Évalué à 10.
Je suis l'avocat des éditions Albert René.
Vous avez utilisé une phrase de notre bande dessinée "Astérix et Cléopatre" pour aubgmenter l'audience de votre site.
Par conséquent, nous vous remercions de nous verser 20 euros par visite sur votre site sinon nous serons contraints de vous trainer en justice et nous ferons fermer votre site (vous connaissez Mobilix?)
Cordialement.
[^] # Re: Un commentaire en alexandrins
Posté par tontonflingueur . Évalué à 10.
Je pense que la phrase en question rentre dans le cadre du "droit de courte citation".
http://fr.wikipedia.org/wiki/Droit_de_citation
Il est vrai que le nom de l'oeuvre et de l'auteur n'ont pas été cités, mais vous avez rectifié vous même cette oubli.
Très cordialement,
[^] # Re: Un commentaire en alexandrins
Posté par Mickaël Sibelle (site web personnel) . Évalué à -1.
C'est la classe 8)
Bonne journée _o/
[^] # Re: Un commentaire en alexandrins
Posté par Prae . Évalué à 8.
[^] # Re: Un commentaire en alexandrins
Posté par Olivier Serve (site web personnel) . Évalué à 10.
Vers -> Alexandrin, poésie, toussa...
[^] # Re: Un commentaire en alexandrins
Posté par Prae . Évalué à 9.
(parce que ca m'intéresse grave là !)
[^] # Re: Un commentaire en alexandrins
Posté par Yannick P. . Évalué à 0.
[^] # Re: Un commentaire en alexandrins
Posté par dab . Évalué à 4.
[^] # ses petits alexandrins pour commentaires
Posté par Mouns (site web personnel) . Évalué à 10.
Or ton unique vers connait un seul déboire.
Mobilix en débuta ce grand réservoir,
Malsain Copyright construit son promontoire.
Ehonté, ce détournement débonnaire
Nuira largement a ton maigre salaire
Tuant tout espoir a ton charmant commentaire
A gagner ces clics pertinent si précaire.
Iras tu, notre ministre, seulement voir
Rasserénant DADVSI comme grand pouvoir
Etre l'unique risée de tout un par-terre ?
Ses petits alexandrins pour commentaires.
[^] # Re: ses petits alexandrins pour commentaires
Posté par Jean Parpaillon (site web personnel) . Évalué à 1.
"Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier
[^] # Re: ses petits alexandrins pour commentaires
Posté par Mouns (site web personnel) . Évalué à 10.
- a un sens
- fait office de commentaire répondant à une autre personne
- est en alexandrin
- a des rimes en 4-4-2-2 ( choix délibéré )
- cache une accrostiche qui fait exactement 12 lettres
- a le titre et le dernier vers qui sous entendent cette accrostiche
- et a d'autres choses
écrire ce petit commentaire m'a fait plaisir et je me suis amusé à improviser cela. je n'y place aucune fierté, aucun orgueil, mais m'entendre dire que c'est facile par une personne qui n'essaie meme pas de répondre sur le même plan, je trouve cela un peu faiblard ( meme si seule phrase se veut être un alexandrin ).
[^] # Re: ses petits alexandrins pour commentaires
Posté par Cereal Killer . Évalué à 7.
Chapeau bas. Je l'ai lu et j'étais loin de m'imaginer qu'il y avait autant de trucs dans ton mini-poème improvisé.
Respect.
[^] # Re: ses petits alexandrins pour commentaires
Posté par Mouns (site web personnel) . Évalué à 1.
parmi mes commentaires "étranges", celui dont je suis le plus fier est ma réponse à une bourde de modération sur un journal qui me plaisait : j'ai osé détourné la scene IV de l'acte I du Cid ( http://linuxfr.org/comments/552196.html#552196 ).
pour faire une lecture comparative avec le texte originale http://perso.wanadoo.fr/jmpetit/cours/lem12.htm . par contre, apres relecture, il y a plein de coquille orthographique qui rendent sa lecture difficile :/
[^] # Re: ses petits alexandrins pour commentaires
Posté par Valdenaire Denis (site web personnel) . Évalué à 3.
Evidemment, il dira lui-même, je pense, ce qu'il a voulu dire, (si ça se trouve j'ai tout faux) mais je voulais préciser ce qu'un tiers aurait compris.
Et encore bravo pour ces alexandrins :)
[^] # Re: ses petits alexandrins pour commentaires
Posté par Mouns (site web personnel) . Évalué à 2.
Maintenant, j'ai l'impression que certains détails parurent au grand jour avec mon commentaire.
[^] # Re: ses petits alexandrins pour commentaires
Posté par be_root . Évalué à 1.
Il se prend pour Napoléon, son état empire.
[^] # Re: ses petits alexandrins pour commentaires
Posté par imalip . Évalué à 1.
Le fait que tu repondes (et la facon dont tu reponds) a sa remarque prouve le contraire. Si c'etait le cas, tu aurais remarque que c'etait de l'humour.
[^] # Re: ses petits alexandrins pour commentaires
Posté par Mouns (site web personnel) . Évalué à 2.
Si je me suis trompé, je lui présenterais mes excuses.
Maintenant, que le doute me tiraille, je sens très con.
[^] # Re: ses petits alexandrins pour commentaires
Posté par Alex G. . Évalué à 2.
Le besoin de reconnaissance est normal et il ne faut pas le nier. Pour ce qui est du commentaire incriminé je pense aussi que c'était de l'humour mais effectivement un petit smiley n'aurait pas fait de mal. Enfin, ça a permis à Moun's de mettre en exergue les qualitées de son poème qui m'étaient passées inaperçues (finallement je pense que c'est ce qu'il aurai du faire dès le début avec simplicité).
[^] # épigramme
Posté par spart . Évalué à 3.
C'est bien mieux odorant. J'explique aux malandrins
ayant pour tout bagage un ou deux Astérix,
Considérez, messieurs, les vers quatre, cinq, six
Ainsi que huit et douze: en quoi d'alexandrins
Ont ils acquis le titre, eux qui ne comptent qu'onze ?
La métrique assassine enseigne qu'à la rime
Ce faquin d'e muet ne vaut pas un centime !
:-)
[^] # Re: ses petits alexandrins pour commentaires
Posté par fenril . Évalué à 1.
"Dis chéri, tu viens déjeuner ?"
Mine de rien, ça me fait des rimes croisées
Je sais, je suis déja sorti.
[^] # Re: ses petits alexandrins pour commentaires
Posté par fenril . Évalué à 6.
Ce modeste post avait pour but premier
Outre de me fendre d'un malheureux quatrain
Navrant, et d'un niveau assurément moyen
Ne vous en déplaise, de jadis, retrouver
Aussi, les trentenaires, ou plus se souviendront
Ravis de retrouver leur jeunesse passée
D'une pub*, où un homme, déclamant d'un ton
Sûr et grandiloquent, fut rondement mouché.
----------
*C'était la réclame pour la moutarde maille, où cet homme récitant des vers devant son miroir fut ramené sur terre par sa femme qui lui hurlait "Dis chéri, tu viens déjeuner?"
# developpeurs web et securité
Posté par jmny . Évalué à 10.
Pour les dev php qui veulent se renseigner sur le sujet, c'est ici (phpsec.org).
[^] # Re: developpeurs web et securité
Posté par jmny . Évalué à 9.
[^] # Re: developpeurs web et securité
Posté par Brice Carpentier . Évalué à -2.
La plupart des autres ont bien conscience de la problématique de sécurité. Que ce soit avec perl, avec Java, avec python ... mais effectivement pas avec php.
Oups, j'ai marché dedans.
[^] # Re: developpeurs web et securité
Posté par Raphaël G. (site web personnel) . Évalué à 0.
Il est vrai que pas mal de monde as écris en php porcui (mais on vois ça aussi en C/C++/etc...).
Je pense qu'il ne faut pas tout généraliser, des programmes écris comme des cons y en a plein.
Un exemple de truc débile (ou dérivés) :
include "{$_POST['sechole']}";
Des truc comme ça, c'est pas chose rare, mais bon y a pas mal de monde qui débute en php et qui n'imagine pas que des petits truc comme ça puisse être exploités...
Je ne parle pas des registrer_globals qui sont pour moi un insecure globals...
[^] # Re: developpeurs web et securité
Posté par jmny . Évalué à 2.
peut être que des personnes familières avec perl et le langage utilisé pour développer awstats pourraient donner des infos sur la conduite à suivre avec ces langages au niveau sécurité ?
[^] # Re: developpeurs web et securité
Posté par Anonyme . Évalué à 1.
Mais le problème de sécurité générale des applis web concerne de toute façon tout les vieux programmes, ceux d'une époque où internet était suffisement peu fréquenté pour que seuls les trous gigantesques posent problème.
De nos jours, tout peut-être source de problème, du coup le seul principe valable est de tout restreindre et de n'autoriser qu'au cas par cas. Les vieilles applis web doivent en ce sens faire marche arrière et tout reprendre, ce qui n'est pas toujours facile.
En ce sens, ça touche bien évidemment aussi des programmes perl comme awstats qui sont bien vieux.
Ceci étant dit, un programme perl qui utilise "use strict;" et qui par conséquent initialize bien ses variables et les chopes proprement avec les modules qui vont bien sont facilement sauf.
C'est bien plus compliqué pour une application PHP qui idéalement devrait fonctionner avec register_globals déactivé, idéal dur à atteindre avec des vieilles applis ou la progression doit se faire petit à petit. Bien plus compliqué avec PHP d'autant que selon quelques options de la conf, beaucoup de choses changent (magic_quotes etc) et que ce qui était recommandé il y a peu est officiellement proscrit ensuite (le problème général de PHP reste celui de l'incohérence de son développement, qui rend les choses compliquées pour les dev ; rien que la différente manière de nommer les fonctions implique de tout le temps en revenir au manuel, cf http://tnx.nl/php ).
[^] # Re: developpeurs web et securité
Posté par Anonyme . Évalué à 1.
Il l'est :
http://cvs.sourceforge.net/viewcvs.py/awstats/awstats/wwwroo(...)
[^] # Re: developpeurs web et securité
Posté par Pierre Tramo (site web personnel) . Évalué à 1.
# Logs apache
Posté par Prosper . Évalué à 10.
http://pschit.net/logspourris.txt
[^] # Re: Logs apache
Posté par Jérôme Pinot (site web personnel) . Évalué à 4.
X - - [16/Dec/2005:22:07:35 +0900] "POST /xmlrpc.php HTTP/1.1" 404 216 "-" "X"
X - - [16/Dec/2005:22:07:36 +0900] "POST /blog/xmlrpc.php HTTP/1.1" 404 221 "-" "X"
X - - [16/Dec/2005:22:07:38 +0900] "POST /blog/xmlsrv/xmlrpc.php HTTP/1.1" 404 228 "-" "X"
X - - [16/Dec/2005:22:07:39 +0900] "POST /blogs/xmlsrv/xmlrpc.php HTTP/1.1" 404 229 "-" "X"
X - - [16/Dec/2005:22:07:40 +0900] "POST /drupal/xmlrpc.php HTTP/1.1" 404 223 "-" "X"
X - - [16/Dec/2005:22:07:42 +0900] "POST /phpgroupware/xmlrpc.php HTTP/1.1" 404 229 "-" "X"
X - - [16/Dec/2005:22:07:43 +0900] "POST /wordpress/xmlrpc.php HTTP/1.1" 404 226 "-" "X"
Ca semblait toujours venir d'un Windows
[^] # Re: Logs apache
Posté par theocrite (site web personnel) . Évalué à 5.
Un ptit coup de mod_rewrite est le bienvenu (ça n'allège pas les logs cependant).
<IfModule mod_rewrite.c>
RewriteEngine on
RedirectMatch permanent (.*)\/xmlrpc(.*)$ http://www.dhs.gov
RedirectMatch permanent (.*)\/awstats(.*)$ http://www.nsa.gov
RedirectMatch permanent (.*)\/cgi-bin(.*)$ http://www.cia.gov
RedirectMatch permanent (.*)\/x90\/(.*)$ http://www.fbi.gov
RedirectMatch permanent (.*)cmd.exe(.*)$ http://www.microsoft.com
RedirectMatch permanent (.*)root.exe(.*)$ http://www.microsoft.com
...
<//IfModule> (un seul '/')
# D'un autre côté...
Posté par ragoutoutou . Évalué à 10.
C'est exactement le même genre de conneries qui ont fait la super réputation de windows: vieilles vulnérabilités, nouveau virus... (sauf que généralement, dans le monde du LL on a les patches plus vite)
[^] # Re: D'un autre côté...
Posté par Raoul Volfoni (site web personnel) . Évalué à 9.
D'autant plus qu'il suffit de mettre /tmp en noexec, nodev et nosuid pour avoir la paix!
Je ne comprend vraiment pas que l'on fasse tout un foin (Cf. FD en ce moment) pour quelque chose d'aussi insignifiant. Quoiqu'à la réflexion si ça peut faire peur à quelques apprentis admins et les amener à prendre des mesures qui auraient dûes être appliquées dès le départ, c'est peut-être un moindre mal.
Mais je n'aimerai pas que tout ce [battage|foin] finisse par laisser penser au dissaïdor que Linux est moins secure que qui vous savez.
[^] # Re: D'un autre côté...
Posté par yoho (site web personnel) . Évalué à 1.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 6.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: D'un autre côté...
Posté par Obsidian . Évalué à 10.
[^] # Re: D'un autre côté...
Posté par chl (site web personnel) . Évalué à 9.
[^] # Re: D'un autre côté...
Posté par Arachne . Évalué à 10.
Et un autre rétorqueras "Oui mais LVM si ça casse tu as l'air malin"
Un autre "Backups !"
etc...
Ce troll plus/moins de partitions est mon préféré entre sysadmins :)
N'empêche j'ai toujours pas trouvé la solution idéale...
[^] # Re: D'un autre côté...
Posté par Cereal Killer . Évalué à 9.
2) c'est pas si compliqué de faire une partoche de plus pour y mettre /tmp et lui dedier quelques centaines de mega, vu la taille des DD aujourd'hui.
3) Qq1 qui monte un machine avec un serveur web n'est plus un simple utilisateur, mais qu'il le veuille ou non, devient admin et DOIT se tenir au courant de ce genre de petit truc.
4) => http://www.us.debian.org/doc/manuals/securing-debian-howto/i(...)
(existe aussi en francais)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: D'un autre côté...
Posté par andeus . Évalué à 1.
[^] # Re: D'un autre côté...
Posté par mansuetus (site web personnel) . Évalué à 2.
a.k.a :
/
/home/monfauxtmp
/tmp => /home/monfauxtmp
si /tmp explose, /home/monfauxtmp explose et donc...
/ explose.
Donc rien à essayer de ce coté là.
[^] # Re: D'un autre côté...
Posté par Alexis P. (site web personnel) . Évalué à 6.
Mais est-ce que ça remet vraiment en cause Linux en soit ? C'est plutôt les applications qui sont fautives, pas le système lui-même...
[^] # Re: D'un autre côté...
Posté par Erwann Robin (site web personnel) . Évalué à 8.
[^] # Re: D'un autre côté...
Posté par Prosper . Évalué à 6.
D'autant plus qu'il suffit de mettre /tmp en noexec, nodev et nosuid pour avoir la paix!
Il me semble que noexec/nobidule/nomachin sur /tmp ne sert strictement à rien tant que tu peux faire /lib/ld-linux.so.2 /tmp/ton_soft_a_executer .
[^] # Re: D'un autre côté...
Posté par inico (site web personnel) . Évalué à 8.
qemu-img create test.img 1G
sudo losetup /dev/loop1 test.img
sudo mkfs.ext3 /dev/loop1
mkdir noexec
sudo mount /dev/loop1 noexec/ -o noexec,nodev,nosuid
sudo cp ./bin/hi ./noexec/
Infos:
./bin/hi: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), not stripped
/dev/loop1 on /home/nico/noexec type ext3 (rw,noexec,nosuid,nodev)
Linux xavia.thenico.fr.eu.org 2.6.12-10-686 #1 Mon Feb 13 12:18:37 UTC 2006 i686 GNU/Linux
Test témoin:
nico@xavia:~$ ./bin/hi
. half-life 3.1.0.x remote buffer-overflow for linux x86
. (c)2000, Tamandua Sekure Laboratories
. Authors: Thiago Zaninotti & Gustavo Scotti
. usage: hl-rcon <server ip[:port]>
nico@xavia:~$ /lib/ld-linux.so.2 ~/bin/hi
. half-life 3.1.0.x remote buffer-overflow for linux x86
. (c)2000, Tamandua Sekure Laboratories
. Authors: Thiago Zaninotti & Gustavo Scotti
. usage: hl-rcon <server ip[:port]>
Test dans la partition noexec:
nico@xavia:~/noexec$ ./hi
bash: ./hi: Permission non accordée
nico@xavia:~/noexec$ sudo ./hi
sudo: unable to execute ./hi: Permission denied
nico@xavia:~/noexec$ /lib/ld-linux.so.2 ./hi
./hi: error while loading shared libraries: ./hi: failed to map segment from shared object: Operation not permitted
nico@xavia:~/noexec$ sudo /lib/ld-linux.so.2 ./hi
./hi: error while loading shared libraries: ./hi: failed to map segment from shared object: Operation not permitted
Fin du test
Test effectué sur une Ubuntu hoary non fortifié au niveau kernel.
[^] # Re: D'un autre côté...
Posté par inico (site web personnel) . Évalué à 2.
Erreur de segmentation
nico@xavia:~/noexec$ strace /lib/ld-linux.so.2 /lib/ld-linux.so.2 ./hi
execve("/lib/ld-linux.so.2", ["/lib/ld-linux.so.2", "/lib/ld-linux.so.2", "./hi"], [/* 36 vars */]) = 0
uname({sys="Linux", node="xavia.thenico.fr.eu.org", ...}) = 0
brk(0) = 0x80016000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f79000
old_mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f77000
open("/lib/ld-linux.so.2", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220\7\0"..., 512) = 512fstat64(3, {st_mode=S_IFREG|0755, st_size=86596, ...}) = 0
old_mmap(NULL, 90052, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7f61000
old_mmap(0xb7f76000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14000) = 0xb7f76000
close(3) = 0
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Ca aussi ca ne fonctionne pas !
[^] # Re: D'un autre côté...
Posté par Prosper . Évalué à 3.
root@proute# mount -o remount,noexec /tmp
root@proute# mount | grep tmp
/dev/sda6 on /tmp type reiserfs (rw,noexec,noatime)
lolo@proute$ cp /bin/ls /tmp
lolo@proute$ /tmp/ls
bash: /tmp/ls: Permission denied
lolo@proute$ /lib/ld-linux.so.2 /tmp/ls
ls
T'es bien sur que le kernel ubuntu a pas un patch en plus ?
[^] # Strange !
Posté par inico (site web personnel) . Évalué à 2.
Réessai avec les même options que moi.
[^] # Re: Strange !
Posté par Prosper . Évalué à 2.
- ton binaire est bien un binaire ELF?
- le kernel ubuntu est patché avec selinux ?
- ton systeme utilise libsafe ?
[^] # Re: Strange !
Posté par inico (site web personnel) . Évalué à 2.
J'ai mis le résultat de file sur le binaire.
nico@xavia:~$ ldd bin/hi
linux-gate.so.1 => (0xffffe000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7dbb000)
/lib/ld-linux.so.2 (0xb7f03000)
2) D'apres le fichier que j'ai dans /boot/config
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=0
CONFIG_SECURITY_SELINUX_DISABLE=y
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_AVC_STATS=y
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1
Ca me laisse supposer que selinux est compilé mais qu'il est desactivé.
3)
nico@xavia:~$ aptitude search libsafe
p libsafe - Protection against buffer overflow vulner
p libsafe-hole-perl - Perl module which makes a "hole" in the S
On dirait pas ...
[^] # Re: Strange !
Posté par herodiade . Évalué à 3.
Exemple:
$ cat <> tst.c
#include <stdio.h>
int main(void) { printf("pouet\n"); return(0); }
EOF
$ gcc tst.c -o /tmp/tst
$ chmod -x /tmp/tst
$ /lib/ld-linux.so.2 /tmp/tst
pouet
$ gcc -static tst.c -o /tmp/tst
$ /lib/ld-linux.so.2 /tmp/tst
Segmentation fault (core dumped)
Mais quoiqu'il en soit, il reste des choses aussi simple que l'utilisation de scripts.
$ echo -e "echo pouet" > /tmp/tst.sh
$ chmod -x /tmp/tst.sh
$ /bin/sh /tmp/tst.sh
pouet
[^] # Re: D'un autre côté...
Posté par theocrite (site web personnel) . Évalué à 5.
Au prochain apt{itude,-get} up{date,grade}, ça va merder. La mise à jour se fera, mais certains paquets utilisent des scripts perls (ou autre chose) dans le /tmp. Ces scripts échoueraient en noexec (testé).
C'est pour ça que j'ai remis mon /tmp en exec. Il y a bien d'autres choses à faire à d'autres endroits pour sécuriser sa machine.
[^] # Re: D'un autre côté...
Posté par Prosper . Évalué à 6.
Au prochain apt{itude,-get} up{date,grade}, ça va merder. La mise à jour se fera, mais certains paquets utilisent des scripts perls (ou autre chose) dans le /tmp. Ces scripts échoueraient en noexec (testé).
Pour ca , il suffit de lire le manuel debian ;)
http://www.debian.org/doc/manuals/securing-debian-howto/ch4.(...)
Soyez vigilant si vous mettez /tmp en noexec et que vous voulez installer de nouveaux logiciels étant donné que certains peuvent l'utiliser pendant l'installation. Apt est un programme de ce genre (voir http://bugs.debian.org/116448) si APT::ExtractTemplates::TempDir n'est pas configuré correctement (voir apt-extracttemplates(1)). Vous pouvez paramétrer cette variable dans le fichier /etc/apt/apt.conf vers un autre répertoire que /tmp et qui aura les privilèges exec.
# autres systemes d'exploitation
Posté par David pasmalin (site web personnel) . Évalué à 6.
[^] # Re: autres systemes d'exploitation
Posté par Matthieu . Évalué à 10.
applications open-source = linux
php = linux
tout comme on a :
linux = gratuit
[^] # Re: autres systemes d'exploitation
Posté par Raoul Volfoni (site web personnel) . Évalué à 4.
Pour info voici un de ces scripts dont j'ai masqué les adresses IP car les sites et les vers téléchargés sont encore présents (enfin plus pour très longtemps amha):
Mais effectivement on devrait pouvoir en faire aisément un wsh. Enfin moi j'ai autre chose à faire... ;-)
[^] # Re: autres systemes d'exploitation
Posté par David pasmalin (site web personnel) . Évalué à 1.
avoir awstat 6.x x <3 , wget curl bash (perl vient avec awstat) xml rpc et webhint le mec qui a fait ce ver cherchait qq1 je pense mmm
[^] # Re: autres systemes d'exploitation
Posté par Arachne . Évalué à 1.
[^] # Re: autres systemes d'exploitation
Posté par Maxime (site web personnel) . Évalué à 1.
# Ce que l'on ne sait pas
Posté par Matthieu . Évalué à 7.
[^] # Re: Ce que l'on ne sait pas
Posté par Twidi (site web personnel) . Évalué à 1.
[^] # Re: Ce que l'on ne sait pas
Posté par Matthieu . Évalué à 5.
Ma question était plutôt quelles incidences peuvent avoir ces failles sur le système sachant que le programme ne peut avoir que accès au compte de l'utilisateur qui lance le service apache (ou autre). Et plus généralement, comment gèrent les distributions actuelles l'utilisateur apache ? a-t-il accès à un shell ? a-t-il accès à toutes les commandes du système ?
Tout pleins de questions qui ne sont pas dans la deuxième partie de la dépêche !
[^] # Re: Ce que l'on ne sait pas
Posté par Jean-Christophe Berthon (site web personnel) . Évalué à 3.
Mais je n'ai pas l'information à disposition.
En théorie donc, si ton système est configuré de manière assez sécurisé (user sans shell, chroot, etc.) tu devrais poser peut-être quelques problèmes au vers lors de l'infection qui pourrait peut-être échouée. Mais je ne puis te le confirmer.
Le plus sûr est de toute façon de mettre à jour ses logiciels pour éviter ce genre de soucis tout en reserrant la sécurité.
Comme ta question dépend de ta distribution ou de comment tu as installé/configuré tes serveurs web, on peut que difficilement y répondre. Il y a trop de possibilités.
Jean-Christophe
[^] # Re: Ce que l'on ne sait pas
Posté par Arthur Accroc . Évalué à 3.
Il est quand même indiqué que le ver, une fois le système infecté, va ouvrir une trappe (ou porte dérobée) sur le port UDP 27015.
Ça peut impliquer que l'auteur du ver ou toute personne connaissant la façon d'utiliser la porte dérobée pourra faire sur ta machine tout ce qu'Apache pourrait faire...
Vaste question qui dépend fortement de la distribution et demanderait plus qu'une dépêche pour être traitée...
Cela dit, pour une configuration "bateau" (pas de chroot (possible avec Apache ?), pas de SELinux, etc.), ça peut vouloir dire : accéder à tous les fichiers qui ne sont pas protégés en lecture pour "other", exécuter n'importe quoi avec exec, y compris chercher un exploit root local, scanner ton réseau s'il est accessible du serveur web, lancer un DDOS...
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Ce que l'on ne sait pas
Posté par Jérôme Pinot (site web personnel) . Évalué à 3.
Sur OpenBSD, la configuration "bateau" c'est Apache chrooté.
Bon maintenant, l'Apache utilisé est un fork de la version 1.3.29 et commence à ne plus ressembler beaucoup à la version couramment utilisée dans les distributions Linux. Si ces dernières voulaient réellement sécuriser les serveurs qu'elles fournissent, elles pourraient très bien le faire.
[^] # Re: Ce que l'on ne sait pas
Posté par theocrite (site web personnel) . Évalué à 3.
• C'est surtout apache qui a choisi de refuser de prendre un paquet de bugs corrigés par OpenBSD. Donc je ne vois pas pourquoi ce serait plus la faute des distribs que celle d'apache. M'enfin apache (OpenBSD) et apache n'ont plus rien à voir. Je crois avoir lu qu'il y a plusieurs milliers de lignes de code qui diffèrent.
• De toutes façons, quand je vois que de base beaucoup de monde installe apache pour servir de simples pages html, voire parfois un peu de php... juste parce qu'il a 75% du marché (ou plus je ne sais plus... et je m'en fout). C'est pas les httpd light et sécure qui manquent quand même.
• Si tu veux installer apache 1.3 officiel (pas OpenBSD) ou apache 2 sur un nux, alors tu peux te tourner vers RSBAC
http://radionet-libre.ath.cx/radionet/index.php?2005/12/01/8(...)
# Traduction
Posté par agmk . Évalué à 10.
[^] # Re: Traduction
Posté par Anonyme . Évalué à 10.
[^] # Re: Traduction
Posté par chl (site web personnel) . Évalué à 4.
[^] # Re: Traduction
Posté par Prae . Évalué à 8.
-->[]
[^] # Re: Traduction
Posté par totof2000 . Évalué à 9.
Par quel porte?
[^] # Re: Traduction
Posté par Erwann Robin (site web personnel) . Évalué à -2.
[*]<-------------- (je suis déja sorti)
# Libre?
Posté par Bob Billy . Évalué à 8.
[^] # Re: Libre?
Posté par totof2000 . Évalué à 10.
[^] # Re: Libre?
Posté par Rozé Étienne . Évalué à -2.
[^] # Re: Libre?
Posté par totof2000 . Évalué à 5.
[^] # Re: Libre?
Posté par isydor . Évalué à -1.
"A-t-on trouvé quel verrou l'ouvert ver a vers où ouvert ?"
[^] # Re: Libre?
Posté par Rozé Étienne . Évalué à 0.
A-t-on trouvé quel verrou l'ouvert ver vert "houx" a vers où ouvert ?
Comme dit le grand maitre : c'est exact, j'hère...
[^] # Re: Libre?
Posté par totof2000 . Évalué à 1.
[^] # Re: Libre?
Posté par totof2000 . Évalué à 1.
[^] # Re: Libre?
Posté par Maxime (site web personnel) . Évalué à -1.
[^] # Re: Libre?
Posté par isydor . Évalué à 0.
"Divers ouverts verrous par l'ouvert ver d'ouverts vers trouvèrent vers où errer"
[^] # Re: Libre?
Posté par totof2000 . Évalué à 1.
[^] # Re: Libre?
Posté par Mr F . Évalué à 3.
[^] # Re: Libre?
Posté par Obsidian . Évalué à -1.
[^] # Re: Libre?
Posté par totof2000 . Évalué à 0.
[^] # Re: Libre?
Posté par blobmaster . Évalué à 0.
C'est un père-vers pervers, mais pas sévère comme ses pairs, qui persévère(nt).
A moins qu'il y ait un jeu de mots que je n'aurais pas lu...
[^] # Re: Libre?
Posté par Obsidian . Évalué à 0.
c'est un père-ver pépère.
[^] # Re: Libre?
Posté par be_root . Évalué à 5.
Il se prend pour Napoléon, son état empire.
[^] # Re: Libre?
Posté par Zorro (site web personnel) . Évalué à 4.
[^] # Re: Libre?
Posté par be_root . Évalué à 0.
Quelqu'un à des nouvelles ?
Il se prend pour Napoléon, son état empire.
[^] # Re: Libre?
Posté par Entaxeime . Évalué à 0.
Ariel Sharon non plus ma foi
# Petite solution
Posté par fabroce . Évalué à -5.
Le ver va faire une requète sur le serveur, celui ci lui répond 302, et...
c'est tout!
Le ver ne tentera pas une nouvelle requete sur l'adresse retournée.
C'est une technique un peu similaire dans l'esprit au greylisting pour les mails!
[^] # Re: Petite solution
Posté par ragoutoutou . Évalué à 10.
On peut faire mumuse et essayer de s'adapter à un ou deux worms en sacrifiant des fonctionnalités, mais quand c'est par dizaines, c'est pas viable.
Plutôt que de faire du réactif de bricolage, mieux vaut mettre son système à jour et appliquer les règles de sécurité raisonnables et éprouvées.
[^] # Re: Petite solution
Posté par inico (site web personnel) . Évalué à 2.
Quite a remplir son fichier error.log de "[Wed Feb 22 06:40:54 2006] [error] [client *] mod_security: Access denied with code 403. Pattern match "<(.|\\n)+>" at POST_PAYLOAD [hostname "84.119.114.125"] [uri "/xmlrpc.php"]" !
[^] # Re: Petite solution
Posté par Matthieu . Évalué à 8.
Ainsi, l'utilisateur de SSL permet de se protéger des vers qui ne supportent pas SSL, mais pas des vers qui le supporte. Et à mon humble avis, le support ne doit pas être trop compliqué.
Donc, activer SSL permet de se protéger de l'attaque virale en cours, mais pas des prochaines.
De plus, je reviens sur la première réponse qui indique que SSL n'est pas une bonne solution, que la bonne solution est de mettre à jour ses serveurs. Oui et non. Oui, il faut mettre à jour ses serveurs. Non, ce n'est pas la solution, mais plutôt une partie de la solution, car mettre à jour vous protège des attaques connues et corrigées, mais pas des autres.
Je pense qu'il faut mettre en place plusieurs politiques de sécurité suivant le niveau que vous voulez atteindre.
La première règle de base est de mettre régulièrement à jour vos services. Ensuite, vous pouvez également vous poser la question sur la diffusion des informations. Le ver exploite une faille dans awstat. Est-ce vraiment utile/raisonnable de diffuser les statistiques de votre serveur web au monde entier ? n'auriez-vous pas interêt à protéger l'accès à cette ressource par l'utilisation d'un mot de passe ?
Ensuite, si vous voulez une protection élevée, peut-être que l'utilisation du chroot vous y aidera, à la seule condition de ne pas installer pleins d'outils dans le chroot (comme wget), et de rendre très difficile voir impossible la copie de tel outil depuis l'extérieur.
Tout ça pour dire que vous ne pourrez pas régler vos problèmes de sécurité par 1 solution, mais par une accumulation de solutions, toutes plus ou moins bonnes, mais qui chacune colmate une faille, même minuscule.
[^] # Re: Petite solution
Posté par herodiade . Évalué à 5.
Et tant qu'il est possible d'injecter des requetes maison dans les logs du serveur web (même dans le error_log, donc raf de la "redirection vers https") awstats risque de se vautrer lorsqu'on lance l'analyse de ces logs (je ne sait pas si c'est la faille visée par ce vers, mais c'est une faille qui a affecté awstats).
Je t'accorde volontier que l'accès aux services du backoffice / d'administration du serveur (comme la consultation des stats par awstats ou webhint) devrait généralement être authentifiés et par conséquent, accessible seulement par SSL (parceque l'auth web sur plain http ... hum ...), mais c'est une autre question.
Je saisis l'occasion pour manifester mon mécontetement à l'égard de nombreuses applications web ultra populaires qui s'offrent le luxe de vulnérabilités critiques tout les deux ou trois mois. On se croirait revenus à l'époque de wu-ftpd !
C'est choquant de voir autant de failles triviales publiées pour de simples applis web en languages interprétés, lorsque, à l'opposé, les services / applications système écrites en langage casse-gueule sont devenues plutôt robustes (les failles sur ces applis sont de plus en plus rare ou du moins, de plus en plus sophistiquées / subtiles). Voilà qui pourri la sécurité (et la réputation de fiabilité) des serveurs unix, malgré tout les efforts des devs système !
Il faudrait vraiment que les developpeurs d'awstats, squirrelmail et autre phpmyadmin se ressaisissent, ou arrètent les frais.
Et en tout cas, je déconseille aux admins d'installer ces logiciels sur leurs serveurs.
</coup de gueule>
[^] # Re: Petite solution
Posté par syj . Évalué à -3.
çà évite une quantité de faille critique sans trop d'effort.
[^] # Re: Petite solution
Posté par totof2000 . Évalué à 2.
Ps: j'ai pas mis les balises mais vous aurez certainement deviné ....
[^] # Re: Petite solution
Posté par B. franck . Évalué à 2.
enfin aussi sécure que d'arracher le rj45 ou l'alimentation...
[^] # Re: Petite solution
Posté par zlnix . Évalué à 1.
parce qu'elles servent maintenant de sous-couche aux appli. WEB.
Bien souvent les grosses/fréquentes modifications s'opèrent sur la couche opérationelle la plus exposée, soit les IHM WEB ! pour moi le problème s'est juste déporté !
# d'ou vient il,comment as t'il ete cree
Posté par GNUtoo . Évalué à -3.
maintenant on entend parler d'un ver linux...
*je me demande d'ou vient le ver(qui est deriere) pour cela:
*je me demande comment la personne a trouve la faille,plus precisement que faut il comme resources materiel afin de trrouver une faille precisement dans ces programmes par fuzzing
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.