Sécurité : Un petit ver pour Linux
Posté par Jean-Christophe Berthon (page perso, ). Modéré le 21 février 2006.
Symantec a découvert [1] ce week-end un nouveau ver destiné aux plate-formes Linux et UNIX. Il s'agit d'une nouvelle variante du virus Plupii découvert en novembre dernier [4].
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.
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.
[1] Alerte Symantec Plupii.C (742 hits)
[2] XML-RPC advisory (453 hits)
[3] AWStats 6.4 (439 hits)
[4] Alerte Symantec Plupii (342 hits)
> Lire la dépêche (107 commentaires, moyenne: 3,9).
Vous avez demandé le commentaire #684331.




D'un autre côté...
... ceux qui se font chopper avec des vulnérabilités aussi anciennes sont sans doutes pas les plus capables et/ou rigoureux.
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é...
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é...
Il faut aussi repartitionner tout ton disque si /tmp n'est pas sur une partition distincte. Donc je dis halte aux "il suffit de..."
[^]Re: D'un autre côté...
Y'a pas un truc qui s'appelle tmpfs justement ?
E Ultreïa !
[^]Re: D'un autre côté...
Tout admin, qui se respecte, utilise un partition distincte pour /tmp /var /home etc.
[^]Re: D'un autre côté...
Et tout utilisateur de GNU/Linux n'est pas forcément admin système, ni même n'en a la prétention ...
[^]Re: D'un autre côté...
Pour maximiser ses chances d'avoir l'erreur "No space left on device" ?
[^]Re: D'un autre côté...
Et là on te répondra "LVM" !
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é...
1) Mieux vaut avoir un "no space left on device" sur un /tmp que sur un / avec ton tmp dedans.
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)
[^]Re: D'un autre côté...
>Pour maximiser ses chances d'avoir l'erreur "No space left on device" ?
Pour minimiser, les chances de l'avoir sur un / .
Le /var contient des fichiers qui augmentent indépendament de la volonté du sys admin (logs, ...). En cas de comportement anormal du système ou de facteurs externe (attaque, par exemple), /var peut devenir full. Il faut donc empêcher que le système devienne inutilisable dans ce cas là => partoch séparée.
Un raisonnement similaire peut s'appliquer à /tmp et /home entre autres.
Le reste est une question de dimensionnement.
Pour un serveur, généralement :
/home petit, /var grand, /tmp de quoi tenir un DVD
Pour un machine perso :
/home grand, /var petit, /tmp de quoi tenir un DVD (enfin pour mon usage perso)
Le "No space left on device" est un fait et peut arriver quelque soit la taille des supports. Il faut donc faire de sorte que quand cela arrive les conséquences soient minimes.
[^]Re: D'un autre côté...
Avec mount -bind ça marche pas ? (j'ai pas essayé)
[^]Re: D'un autre côté...
--bind ==> permet de faire plusieurs "points de montage" du meme disque.
a.k.a :
/
/home/monfauxtmp
/tmp => /home/monfauxtmp
si /tmp explose, /home/monfauxtmp explose et donc...
/ explose.
Donc rien à essayer de ce coté là.
mansuetus @ spontex . org
[^]Re: D'un autre côté...
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é...
l'amalgame est vite fait ... déja que beaucoup de personnes croient que freebsd est une distribution linux...
[^]Re: D'un autre côté...
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é...
Etapes préliminaire:
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.
"Les États-Unis sont le seul pays à être passé de la barbarie à la décadence sans connaître la civilisation." -- (origine réelle inconnue) Albert Einstein/Oscar Wilde/Georges Clemenceau/etc..
[^]Re: D'un autre côté...
nico@xavia:~/noexec$ /lib/ld-linux.so.2 /lib/ld-linux.so.2 ./hi
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 !
"Les États-Unis sont le seul pays à être passé de la barbarie à la décadence sans connaître la civilisation." -- (origine réelle inconnue) Albert Einstein/Oscar Wilde/Georges Clemenceau/etc..
[^]Re: D'un autre côté...
Pourtant sur une debian ca marche sans souci :/
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 !
Sur une distrib desktop, ca m'etonnerai qu'il y est un patch du style grsec.
Réessai avec les même options que moi.
"Les États-Unis sont le seul pays à être passé de la barbarie à la décadence sans connaître la civilisation." -- (origine réelle inconnue) Albert Einstein/Oscar Wilde/Georges Clemenceau/etc..
[^]Re: Strange !
Oui et ca ne change rien ( normal c ets pas une option nosuid/nodev qui va changer qqch ) , la seule chose qui change est que je le fais avec une vraie partition et pas un loop , par contre j aimerais savoir :
- ton binaire est bien un binaire ELF?
- le kernel ubuntu est patché avec selinux ?
- ton systeme utilise libsafe ?
[^]Re: Strange !
1) Oui, le binaire est bien un elf.
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 ...
"Les États-Unis sont le seul pays à être passé de la barbarie à la décadence sans connaître la civilisation." -- (origine réelle inconnue) Albert Einstein/Oscar Wilde/Georges Clemenceau/etc..
[^]Re: Strange !
Ça dépend de la façon dont le binaire est consitué: s'il est lié statiquement l'astuce du loader ne marche pas telle quelle.
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é...
Je sais pas si ça passe ou pas sur ta debian, mais mettre ton /tmp en noexec, ce n'est pas une bonne idée de toutes façons.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.
Le libre vaincra, tout est déjà joué.
[^]Re: D'un autre côté...
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.