Fedora 12 et séparation des privilèges

Un bien bel exemple, assez représentatif du concept de "en voulant simplifier la vie à l'utilisateur, on réduit le niveau global de sécurité d'un système".

En gros, sans entrer trop dans les détails (les posts sur la mailing list, et la "wave" sur Google Wave, liés à ce problème, seront plus précis et plus instructifs), tout utilisateur sur le système peut installer n'importe quel package signé sans avoir à donner de mot de passe root (bon, après tout, sur une distribution Ubuntu, on utilise sudo et on donne le mot de passe de l'utilisateur connecté pour installer des packages). Certains peuvent se demander où est le problème. Il est là:

The default configuration of PackageKitinFedora 12 permits non-root users to install signed rpm packages from configured yum repositories. This creates a number of potential security problems including the possibility to:

1) Execute a remote-root exploit by exploiting a networked client such as firefox, Adobe flash, pidgin, xchat, etc. to obtain a remote user shell, and then installing a signed package from a configured repository which contains a local-user to root privilegeescalation vulnerability to gain root.

2) Similar to #1 above, but downloading a signed rpm from a previous OS release that has a known user-to-root shell vulnerability, and doing a local install.

3) Similar to #1 above, only doing a denial of service attack by installing a massive number of applications (in one massive transaction, or many smaller ones), and possibly tying up a large amount of network bandwidth, spiking the system CPU load, causing an out of memory condition, etc.

Au final, après un long troll (dont j'ai pris connaissance en lisant dailydave), une décision importante a été prise et annoncée par le type qui maintient le package responsable de ce léger défaut:

"After more discussion and thought, though, the package maintainers have posted to the fedora-devel-list mailing list agreeing to provide an update to Fedora 12's PackageKit. The update will require local console users to enter the root password to install new software packages."

A part ça, sans transition, Google Wave c'est rigolo 5 minutes, mais je pense qu'une majorité de gens ne savent pas encore trop à quoi ça peut leur servir. J'aurai peut-être quelques invitations à refiler d'ici quelque temps. Pour le moment, à part ce qui peut s'apparenter à un échange de "mails" (qui s'appellent des "waves" là dedans), et un test de twitter-via-gwave, je n'ai pas fait grand chose. Par contre, il faudra envisager les plugins permettant de chiffrer/déchiffrer ce qu'on envoie sur wave :-)

le worm de l'iphone

Fatalement, fallait bien que ça arrive, un (nouveau) worm sur un téléphone mobile; et pas n'importe lequel: l'iPhone d'Apple. Alors que Mme Michu se rassure, seuls les iPhones dits "jailbreakés" sont concernés (il s'agit des iPhones dont l'utilisateur a fait tomber la protection contre l'exécution des exécutables par signature numérique, en gros [j'ai grossièrement résumé]).
Le code était public jusqu'à récemment, mais il semblerait que ça ne soit plus le cas; Mais par chance, il est encore disponible à de nombreux endroits.
Alors dans les médias, on nous présente toujours les développeurs de virus et autres worms comme étant des petits génies de la programmation; ce n'est clairement pas ce que je pense en lisant le code source de ce worm.

syslog(LOG_DEBUG, "Lannnnn");
scanner(lanRanges);
syslog(LOG_DEBUG, "VODAPHONE");
scanner(vodRanges1);
scanner(vodRanges2);
scanner(vodRanges3);
syslog(LOG_DEBUG, "OPTUSSSS");
scanner(optRanges1);
scanner(optRanges2);
scanner(optRanges3);
scanner(optRanges4);
scanner(optRanges5);
scanner(optRanges6);
syslog(LOG_DEBUG, "Telstra");
scanner(telRanges);

Vous en conviendrez aisément, ce code fait mal aux yeux. Et ensuite, sa série de variables "optRangesX", "vodRangesX", il les a définies plus haut:

char *locRanges = getAddrRange();
char *lanRanges = "192.168.0.0-192.168.255.255"; // #172.16.0.0-172.31.255.255 Ehh who uses it
char *vodRanges1 = "202.81.64.0-202.81.79.255";
char *vodRanges2 = "23.98.128.0-123.98.143.255";
char *vodRanges3 = "120.16.0.0-120.23.255.255";
char *optRanges1 = "114.72.0.0-114.75.255.255";
char *optRanges2 = "203.2.75.0-203.2.75.255";
char *optRanges3 = "210.49.0.0-210.49.255.255";
char *optRanges4 = "203.17.140.0-203.17.140.255";
char *optRanges5 = "203.17.138.0-203.17.138.255";
char *optRanges6 = "211.28.0.0-211.31.255.255";
char *telRanges = "58.160.0.0-58.175.255.25";
//char *attRanges = "32.0.0.0-32.255.255.255"; // TOO BIG

Alors vous aurez noté des trucs sympa, comme le 192.168.255.255, qui est utilisé comme borne haute dans la rangée d'adresses IP à scanner sur un LAN, ce qui n'est pas une obligation - en 192.168, c'est du /24 par défaut - ce qui fait que son programme a une chance non négligeable de tenter un nombre incroyable de connexions vers des IP ne faisant pas partie du même réseau que l'iPhone. Je ne sais pas ce que ça donne en terme de consommation CPU, mais ça doit pas être très optimal tout ça. On passera sur les adresses de broadcast aussi. Sa remarque sur le fait que personne n'utilise les IP privées en 172.16.x.y aussi. Puis il oublie les IP en 10.x.y.z (on passera sur les autres, qui sont encore plus rarement utilisées comme les 4-5.x.y.z, utilisées par exemple par hamachi :-)
Il aurait pu utiliser un ioctl() pour récupérer ces paramètres, afin de rendre son code fonctionnel dans les configurations réseau "moins répandues", et surtout optimiser la métode de propagation.
Revenons-en à nos moutons: la série d'appels à la fonction "scanner", qui aurait quand même pu être méchament simplifiée, par exemple en définissant une structure (en C) avec un entier comme "index", et une chaine de caractères qui contienne sa rangée d'adresses IP; ensuite, il n'avait plus qu'à itérer en incrémentant son index, et il se retrouvait avec un code sensiblement plus extensible (supposons qu'il veuille rajouter une rangée d'adresses IP pour un opérateur: il se retrouve à devoir ajouter un nouveau "optRangesX" correspondant à cet opérateur, ainsi qu'un ou plusieurs appels à "scanner()" en fonction du nombre de rangées d'adresses IP de l'opérateur; pour un code de quelques lignes comme celui -ci ça passe encore: pour un projet de grande envergure, je ne ferais pas appel à ce type).
J'ai aussi une petite pensée pour ses fonctions "runCommand" et "prunCommand", qui sont quasiment identiques, la différence étant que la première renvoie 0 si l'iPhone est vulnérable (comprendre: si l'utilisateur de l'iPhone n'a pas changé le mot de passe root).
En fait ça me fait plus penser à du code qu'un développeur PHP de 15 ans aurait pu pondre, et ça, même le commentaire en header du fichier ne me fera pas penser le contraire:

// This code is CLOSED source.
// And very hacky, i just needed it to work.

Je ne vais pas m'étendre plus sur le code source de ce truc. Sur Zataz, la question est posée sur "comment il sélectionne ses victimes", il y a plusieurs réponses, dont deux données au dessus:
- les ranges d'IP de quelques opérateurs;
- les IP du réseau local de l'iPhone, si une connexion wifi est active;
- des IP générées aléatoirement.
Dans tous les cas, le ver essaie de se connecter via ssh à chacune de ces adresses IP en essayant le mot de passe par défaut d'un iPhone, et en tentant l'exécution d'une commande ("echo 99"). Si cette commande reussit, la fonction "infectHost" est appelée, le fond d'écran de l'utilisateur est supprimé, et remplacé par un autre, puis le worm s'installe dans les scripts de démarrage, afin d'être lancé à chaque reboot de l'iPhone.
En plus d'avoir jailbreaké son iPhone et laissé le mot de passe root par défaut (même si 90% des stats sont inventées, je pense que 99% des utilisateurs d'iPhone jailbreakés [qui doivent être une minorité] ont laissé le pass root sans le changer), il faut que le port ssh de l'iPhone soit accessible depuis le reste d'internet; je ne sais pas ce que ça donne en france par contre à ce niveau là.
Il est maintenant temps de retourner à l'écoute en boucle du clip du moment.

Le bon vieux temps

Ce "DailyWTF" m'a bien fait rire. Surtout ce passage:

After 15 minutes of “Hmmm” and “That’s strange” from the other end of the phone, the support tech finally said “I think this is going to take a while – could you disconnect and well, just not do that thing you’re doing anymore? We’ll continue to investigate though – thanks for the tip!”

Idées de gens (crypto)

Un truc dont les médias vont probablement nous parler dans les jours à venir, c'est l'utilisation du "cloud computing" pour profiter d'une puissance de calcul très importante afin de casser des mots de passe. Un post récent sur slashdot nous envoie même sur un article racontant l'application de ce principe au cassage du mot de passe protégeant une archive au format PGPZIP.
L'article est très bien fait, et je ne pense pas m'attarder dessus, ou peut-être plus tard, style un jour de pluie.
C'est plutot ce que je peux lire dans les commentaires sur slashdot qui sont assez intéressants. Certains donnent un point de vue, discutable ou non. D'autres vont clairement plus loin dans le délire "comment chiffrer ses données confidentielles sans danger en cas de fuite de la clé ?", comme celui ci:

The best solution (if you are dealing with a desktop system) is to have the pass-phrase and keys but also have a small GPS module. If the usb key is not close to where it should be (with a fairly big margin for the fact that cheap GPS modules arent exactly accurate) it would erase the pass-phrase
If they try to force you to hand over your password (e.g. UK RIP act), you just hand it over (to the guys who seized your computer and are now trying to use it somewhere else other than the required GPS location) and boom, the data is gone forever.
If you need to move house, just log in from the old house and reset the GPS then when you get to the new house, log in and put in the new coordinates.

C'est assez extrème, mais ça pourrait être une idée intéressante. Finalement c'est aussi de l'authentification forte.
Puisqu'on en est à la crypto, pensons à la loi Création et Internet (alias 'HADOPI') qui va très certainement signifier la généralisation de l'usage d'outils de crypto en France. Et même si ce n'est pas leur généralisation, ils seront quand même nettement plus utilisés qu'actuellement.
Toujours en crypto, Ubuntu 9.10 propose maintenant de chiffrer le répertoire perso des utilisateurs à l'aide d'eCryptFS, et ça c'est très bien.