Victor STINNER a écrit 1632 commentaires

Hélas l'article à été réécrit avant ça publication

Il était incompréhensible, incomplet et bourré de fautes. J'ai par exemple très largement complété la liste de nouveautés de la version 0.2.

par exemple ultracopier utilise au choix la lib Qt ou Qt+KDE

Comme je n'avais pas vu de fichier INSTALL, j'ai testé héroïquement la compilation avec cmake (qui a foiré à plusieurs endroits : cmake puis dans le code). Le système de compilation basé sur cmake exige KDE.

À l'instant, je viens de découvrir le fichier docs/readme.txt et qu'il existe un 2e système de compilation (étonnant). UltraCopier ne respecte pas trop les "standards" du logiciel libre :
- l'archive ne contient pas dossier "ultracopier-x.y" : tar -xf ultracopier-src.tar.bz2 crée plusieurs sous-dossiers dans le dossier courant. Je me suis fait avoir, oups ! "tar -tf ultracopier-src.tar.bz2|xargs rm -rf" pour supprimer la polution.
- il n'y pas de fichier INSTALL, mais il y a des infos dans docs/readme.txt (découvert après-coup, trop tard)
- le nom des fichiers est assez inhabituel, je proposerai : docs/readme.txt => README, docs/version.txt => ChangeLog, docs/gpl-3.0.txt => COPYING

j'avais pas préciser volontairement dans l'article

Le problème est que ce n'est pas clair du tout. Je pensais qu'UltraCopier dépendait de KDE, et j'ai préféré que la dépêche soit explicite.

J'avais aussi tiqué. En même temps, MiniCopier est écrit en Java et SuperCopier en Delphi !

Le plus gros avantage de Skype est d'être capable de passer des passerelles de part et d'autre sans configuration de firewall, NAT et autres joyeusetés, or aujourd'hui les box faisant légion c'est indispensable.

En IPv6, on peut écouter sur le même port depuis plusieurs ordinateurs derrière la même "box" Internet. Du coup, la configuration du parefeu est beaucoup plus simple. Avec une Freebox c'est encore plus simple, parce qu'il n'y pas de parefeu IPv6 : tout est ouvert :-)

Ainsi, par exemple, je ne me soucie pas trop de cette faille sur ma machine personelle. Je suis le seul à avoir un accès.

Sais-tu que les navigateurs web sont devenus le principal point d'entrée des malwares ? Les failles (HTML, Javascript, Flash, etc.) sont très courantes. Si un pirate arrive à exécuter du code dans ton navigateur web, c'est comme si c'était un utilisateur local. Avec ça, il peut déjà voir tes photos de vacances, lire tes mails, sniffer tous tes mots de passe, récupérer tes clés SSH/GPG, etc. C'est déjà pas mal.

Maintenant, en utilisant un exploit pour passer root, il peut modifier le système, très utile pour la furtivité (supprimer quelques lignes compromettantes dans des fichiers de log, compiler et charger un module noyau à la volée, remplacer tes programmes par des versions piratées, etc.). Ça permet également de mettre en place un serveur web, FTP et/ou ssh : un utilisateur ne peut pas écouter sur les ports TCP inférieurs à 1024 (bien qu'on puisse très bien utiliser des ports non standards, mais c'est moins furtif, après ça dépend des usages).

Bien sûr, le navigateur n'est pas le seul vecteur d'entrée. N'importe quel support amovible (clé USB, disque dur externe, CD/DVD) et tout ce qui vient d'Internet (web, mail, photos, paquets, etc.) peut servir pour infecter ta machine.

Aujourd'hui, le plus grand fléau sont les botnets qui servent à envoyer du spam : des troyans s'installent sur des postes Windows. Des postes de travail, pas des serveurs, car justement le but est d'avoir le botnet le plus gros possible, donc infecter le maximum d'ordinateurs.

Je n'essaye pas de te rendre parano, juste de t'expliquer les risques ;-) C'était pour dire que même si tu n'as aucun port en écoute, tu n'es pas protégé pour autant.

Euh, un simple dist-upgrade t'aurait installé le nouveau noyau précompilé. C'est l'objet du dernier bulletin de sécurité Debian :
http://www.debian.org/security/2009/dsa-1927

« For the stable distribution (lenny), this problem has been fixed in version 2.6.26-19lenny2. »

Tu es tombé au moment où les sources du nouveau noyau étaient en ligne, mais pas encore les paquets binaires (le temps qu'ils soient compilés, puis copiés sur tous les miroirs).

CVE-2009-3547

Earl Chew discovered a NULL pointer dereference issue in the
pipe_rdwr_open function which can be used by local users to gain
elevated privileges.
http://lists.debian.org/debian-security-announce/2009/msg002(...)

Le noyau ne corrige que la faille pipe. Par contre, mmap_min_addr est inchangé. Ça ne sera changé que dans Debian 5.0.4.

Sur Fedora 11, si on écrit 0 dans mmap_min_addr, l'exploit fonctionne, arrive à contourner SELinux (et aucun avertissement SELinux n'est affiché). En plus, il affiche une image se moquant du modèle de sécurité de SELinux (Discretionary access control vs Mandatory Access Control).

Au sujet de ma phrase « Brad Spengler a écrit un exploit (pouvoir passer root à partir d'un compte utilisateur) fonctionnant sur, au moins, Debian Etch, Fedora (6, 10 et 11), et RedHat (5.3 et 5.4). L'exploit contourne les protections SELinux dans le cas de Fedora 10 et RedHat 5.4. », j'ai utilisé les captures d'écran publiées par Brad (j'ai utilisé le peu d'infos disponibles sur le net). Pour Fedora 11 par exemple : http://grsecurity.net/~spender/fc11.png (mise en ligne le 3 novembre). Peut-être que cette capture d'écran n'est pas liée à l'exploit MooseCox (pipe) ou que c'est une Fedora 11 pas à jour.

Je viens de tester l'exploit sous une Fedora 11 à jour, et 1) l'exploit ne fonctionne 2) beaucoup mieux : SELinux affiche un avertissement comme quoi il y a eu une attaque. Bravo Fedora ! Bravo SELinux ! clap clap clap !
http://www.haypocalc.com/tmp/fedora_enlightenment.png

Vous ne pouvez plus ignorer la faille maintenant que l'exploit est public : http://grsecurity.net/~spender/enlightenment.tgz

Lancez "./run_null_exploit.sh", c'est l'exploit « MooseCox: Linux-2.X->Linux.2.6.31.unfixed pipe local root ». L'exploit ne fonctionne pas sur Ubuntu (car mmap_min_addr est non nul), mais fonctionne très bien sur Debian Lenny. J'espère que Debian va se bouger les fesses.

Extrait du 2e lien (wiki Debian) : « wine
Only Win16 binaries require the ability to mmap low addresses, Win32 binaries do not. It is recommended that you test your application with the increase mmap_min_addr setting. If the application starts up without issue, then you should not need to remove the mmap_min_addr restriction. »

Tiens, en lisant http://lwn.net/Articles/347390/ j'ai trouvé la justification de RedHat sur le fait que mmap_min_addr soit toujours nul : « In RHEL5 the boolean is enabled by default for backwards compatibilitally, as mmap_min_addr was introduced during the lifetime of RHEL5, allowing all unconfined domains to mmap_zero. (...) We are not planning on changing the default in RHEL5, to maintain backawards compatability. »
http://danwalsh.livejournal.com/30084.html

Pour Debian Stable, je pense que la raison est la même. Pour Debian Testing par contre, il me semble que mmap_min_addr soit toujours nul, mais j'espère que ça sera changé (c'est prévu pour Debian 5.04 en tout cas).

Le commit OpenBSD date de juin 2008, alors que Linux possédait déjà l'option mmap_min_addr depuis octobre 2007 (noyau 2.6.23). Mais il est vrai que la valeur par défaut ne protège pas des exploits noyau (c'est à la distribution de bien configurer Linux, choix discutable, alors qu'OpenBSD décide pour l'utilisateur).

The #1 reason why the Linux team has not commited this by default is because it breaks Wine

Petite précision pour Wine : seule l'exécution de programme Win16 (Windows 3.1 ?) dans Wine pose problème avec mmap_min_addr. Mais il n'y a pas que Wine qui est impacté par mmap_min_addr : dosemu, qemu et BitBake le sont également. Oui, qemu peut servir à émuler un système d'exploitation propriétaire, mais il est beaucoup utilisé pour tester (voir même utiliser !) Linux. kvm est d'ailleurs basé dessus. Il me semble que certains utilisent même qemu pour exécuter Linux sous Windows (mais là c'est hors sujet) :-)

Je pense également que SELinux et grsecurity protègent des bugs « déréférencement de pointeur NULL » depuis fort longtemps (ex: option « UDEREF » de PaX), mais j'ai la flemme de chercher une date.

C'est déjà fait : http://www.splitted-desktop.com/~gbeauchesne/mplayer-vaapi/

Il n'y a qu'un seul driver officiellement maintenu pour US15W (Poulsbo): IEGD

Ah bon ? Pourquoi Ubuntu, Fedora et Mandriva utilisent le vieux pilote non maintenu alors ?

l'argument 'plus supporté depuis un an et demi' n'est pas valable.

Au sujet de xorg-x11-drv-psb (et ses amis, cf. ma dépêche plus haut), il y a un dépôt git officiel (maintenu par Intel) qui est mort depuis 1 an 1/2 :
http://git.moblin.org/cgit.cgi/deprecated/xf86-video-psb/
(il est d'ailleurs marqué comme étant déprécié)

Ce qui est reproché à Intel, au sujet du Poulsbo, est de ne pas chercher à être intégré au noyau et/ou à Xorg. Il y aurait au moins la 2D qui pourrait être intégrée car (tout?) le code est libre (GPL ou MIT).

the netbook was running Moblin Linux

Il me semble que cet OS ait été publié en Avril 2008 environ. Quant est-il de Moblin 2 (avril 2009), Linux 2.6.31 et Xserver 1.7 ?

Les deux seuls Netbooks répandus l'utilisant à ma connaissance étant le Dell Mini 12 et... l'Eee PC 1101HA !

Je ne voulais pas copier/coller Wikipédia dans ma dépêche, de peur d'avoir une liste incomplète (alors que Wikipédia est complété en continu). Mais bon, tant pis. Si tu suis le 1er lien de la dépêche, tu verras :

Intel System Controller Hub US15/W/L-SGX535(Intel GMA500) + VXD370

* Abit (USI) MID-100
* Abit (USI) MID-150
* Abit (USI) MID-200
* Acer Aspire One AO751h
* Advantech MICA-101
* Aigo MID P8860
* Aigo MID P8880
* Aigo MID P8888
* Arbor Gladius G0710
* Archos 9
* ASUS EeePC T91
* ASUS EeePC S121
* ASUS EeePC 1101HGO
* ASUS R50A
* ASUS R70A
* Averatec (TriGem) MID
* BenQ Aries2
* BenQ S6
* Clarion MiND
* CLEVO TN70M
* CLEVO TN71M
* Clevo T89xM
* Colmek Stinger
* Compal jAX10
* CompuLab Fit-PC2
* Dell Inspiron Mini 12
* Dell Inspiron Mini 10
* Dell Inspiron Mini 1010 Tiger
* Digifriends WiMAX MID
* DT Research DT312
* DUX HFBX-3800
* EB mobile internet device
* FMV-BIBLO LOOX U/C40
* FMV-BIBLO LOOX U/C30
* Fujitsu UMPC U2010
* Fujitsu LifeBook U2020
* Fujitsu LifeBook U820
* Gigabyte M528
* Hanbit Pepper Pad 3
* Kohjinsha/Inventec S32
* Kohjinsha/Inventec SC3
* Kohjinsha W130
* Kohjinsha SX3KP06MS
* KOHJINSHA SC3KX06A
* Kohjinsha/Inventec X5
* Kohjinsha PM series
* Lenovo IdeaPad U8
* LG XNote B831
* MaxID BHC-100
* MaxID iDLMax
* mis MP084T-001G
* MSI Wind U115
* MSI Wind U110
* MSI X-Slim 320
* NEC VersaPro UltraLite type VS
* NEXCOM MRC 2100
* NEXCOM MTC 2100
* NEXCOM MTC 2100-MD
* Nokia Booklet 3G
* NOVA SideArm2 SA2I
* OMRON Panel PC
* OQO Model 2+
* Panasonic Toughbook CF-U1
* Panasonic CF-H1 Mobile Clinical Assistant
* Portwell Japan UMPC-2711
* Quanta mobile internet device
* Sony Vaio P series
* Sony Vaio X series
* TCS-003-01595 - Intel ATOM Rugged Tablet PC 8.4"
* Toshiba mobile internet device
* Trigem LLUON Mobbit PS400
* UMID Clamshell
* Viliv (YuKyung) S5
* Viliv (YuKyung) S7
* Viliv (YuKyung) X70
* WiBrain i1
* WiBrain M1
* WILLCOM D4 (Sharp WS016SH)
* Various system boards and computer on modules including:
o Adlink Express-MLC
o Advantech SOM-5775
o AXIOMTEK PICO820
o Congatech conga-CA
o Congatech-IVI Starterkit
o CoreExpress-ECO
o Eurotech Catalyst
o Eurotech Isis
o Eurotech Proteus
o IBASE IB822
o Inhand FireFly
o Kontron nanoETXexpress-SP
o Kontron microETXexpress-SP
o Kontron KTUS15/miTX
o LiPPERT CoreExpress-ECO COM
o MEN Micro XM1
o MSI MS-9A06
o MSC Q7-US15W
o Portwell PEB-2736
o Portwell PCS-8230
o Portwell NANO-8044
o Portwell WEBS-2120 (Nano-ITX)
o Portwell WEBS-1310/1320 (ECX)
o PROTEUS COM EXPRESS
o RadiSys Procelerant Z500
o RadiSys Procelerant CE5XL
o RadiSys Procelerant CE5XT
o Woodpecker Z5xx Micro COM Express
o Xilinx XA Spartan-3E FPGA

Je ne sais pas si les modèles listés sont « répandus », et je n'ai pas non plus regardé ce dont il s'agit (si c'est des netbooks ou non), mais en tout cas, il existe plus de deux modèles :-) J'ai entendu parlé de problèmes de Poulsbo (du pilote Linux) sur MSI Wind U115 et sur Sony Vaio P.

Quant aux téléphones, ils utilisent pour la plupart des SoC ARM, donc pas de Poulsbo non plus.
Note : Le problème reste cependant valable pour eux puisque beaucoup de ces SoC ont une partie graphique signée PowerVR. On y revient.

Moui, j'ai fait un raccourci. À vrai dire le problème n'est pas le Poulsbo, mais le pilote pour les puces PowerVR (SGX). Et les puces SGX équipent beaucoup de monde de l'embarqué.

« accès aux machines et au code du logiciel entre le 10 et le 13 novembre »

Pour écrire un exploit stable et indétectable, je pense qu'il faudrait un peu plus que 3 jours... Je n'ai pas suivi les liens, mais est-ce le code source est consultable (avant/après le concours) ?

--

Quelques nouvelles récentes sur le vote électronique.

30 septembre 2009 : « In a recent paper a six person research team with members from Princeton, University of Michigan and University of California, San Diego, describe how they approached subverting a high security Direct recording Electronic (DRE) voting machine. The machine in question, the Sequoia AVC Advantage, (...) »
http://www.h-online.com/security/news/item/Voting-machine-ha(...)

28 octobre 2009 : « Sequoia to release voting system software » (ça semble être une société américaine)
http://lwn.net/Articles/359089/

Oh, chouette, tu as l'air bien renseigné ! Déjà, pour être franc, je n'ai pas vérifié la compatibilité du matériel avec Linux. Comme les premiers netbooks étaient vendus sous Linux, j'ai pensé que les netbooks étaient toujours compatibles Linux... Or, j'ai vite déchanté :-(

Donc si j'ai bien compris Imagination Technologies vend des très bonnes puces (graphiques), mais vend les pilotes à part oi propose des NDA pour que le constructeur écrive ses propres pilotes ? Quel est l'intérêt d'avoir un chouette puce 3D sans pilote (cas du N800) !? La licence pour le pilote et/ou NDA est trop cher, et certains constructeurs préfèrent s'en passer ?! Enfin, l'intérêt pour Imagination Technologies est flagrant : gagner un max de fric. Mais pour le constructeur, je trouve que c'est quand même un point bloquant (absence de pilote correct).

Je trouve ça assez étonnant de vendre du matériel sans pilote. Mais bon, je ne connais pas trop le domaine, peut-être que c'est une chose normale.

http://www.netsplit.com/2009/09/02/making-a-splash/ date du 2 septembre 2009. Au sujet de Plymonth, le backend "drm" a été crée le 28 septembre, et le backend "x11" le 4 octobre (après cet article).

Maintenant si on regarde le planning de Karmic (https://wiki.ubuntu.com/KarmicReleaseSchedule) :
* 3 septembre : Alpha 5
* 17 septembre : Alpha 6
* 23 octobre : Béta

Bien sûr, si Canonical avait investit plus dans Plymonth, les backends drm et x11 auraient été plus rapidement disponible, et pour être à temps pour Karmic.

Au sujet de setuptools, le projet a été forké après 2 ans d'inactivité de son auteur (P.J. Eby). Pourtant, il y avait des bugs dans setuptools, et je crois qu'il y avait même des patchs en attente.

Le français Tarek Ziadé a pris le taureau par les cornes en commençant par s'assigner mainteneur du module distutils (la brique sur laquelle repose setuptools, et qui sert pour installer tous les projets Python). Ce n'est pas une tâche facile car le projet distutils est très mal testé (couverture de code à hauteur de 20-30% quand tarek est arrivé), pas mal bogué et il y avait des dizaines tickets en attente dans le bug tracker. Bref, tarek a fait un énorme travail sur distutils ces derniers mois.

--

C'est indécent, mais il ne s'en est pas arrêté là le coquin. Il s'est attaqué à bien pire, à setuptools. Comme le mainteneur de setuptools semble plutôt frileux niveau contributions et ouverture sur la communauté, tarek a forké le projet sous le nom Distribute.

Distribute fonctionne plutôt bien et est développé par plusieurs personnes, dont deux développeurs "core" de Python (gros gage de qualité). Le projet est hébergé là :
http://bitbucket.org/tarek/distribute/

La documentation est directement sur le site python.org, preuve que le projet est supporté par les développeurs core de Python :
http://packages.python.org/distribute/

La semaine dernière il y a même eu un sprint en ligne pour booster le projet. Pour suivre l'évolution de Distribute, le mieux est le blog de Tarek :
http://tarekziade.wordpress.com

Au contraire, setuptools a toujours voulu rester séparé de Python, et n'a rien fait pour être intégré ou bien améliorer distutils (corriger le mal (distutils est une horreur !) à la source).

--

Pendant ce temps, le mainteneur de setuptools sort de son hibernation et attaque directement tarek et son projet Distribute, en disant qu'il est plus bogué que setuptools (ce qui est une abération). Il dit également qu'il était parfaitement ouvert aux contributions externes, ce qui semble bien étonnant quand on sait qu'en 2 ans il n'y a eu aucune release.
http://dirtsimple.org/2009/10/that-wasn-so-difficult-was-it.(...)

Il en profite pour se plaindre que Python 2.6.3 a cassé SON projet (setuptools, vilain Python !), et se vante d'avoir contourné le bug.

--

Des liens sur distutils, Distribute et setuptools :
http://pvergain.wordpress.com/package-management/

Je vous laisse lire les archives de la liste de diffusion distutils-sig, mais moi j'ai fait mon choix : Distribute ! Et je suis très content que Tarek mette un coup de pied dans la fourmilière.

LLVM est sous licence BSD, est plus jeune (ne traine pas du vieux code depuis 1985 comme gcc), sait faire des optimisations dont GCC est incapable (parce que GCC est difficile à modifier, plus gros, plus complexe), possède un compilateur à la volée (JIT). Il me semble que LLVM est plus générique que GCC (gère plus de langages et des langages plus variés) : LLVM est par exemple utilisé pour compiler les shaders pour GPU avec Gallium ou bien pour compiler du Python à la volée.

J'ai l'impression que LLVM est plus conçu comme une bibliothèque intégrable à un projet existant qu'un programme en ligne de commande.

Le problème d'un compilateur à la volée est que c'est difficile à déboguer. La dernière version d'Unladen Swallow (qui utilise LLVM), la 2009Q3, inclut de symbole de debug pour gdb 7.0 :

"The Unladen Swallow team added support to gdb 7.0 that allow JIT compilers to emit DWARF debugging information so that gdb can function properly in the presence of JIT-compiled code. This interface should be sufficiently generic that any JIT compiler can take advantage of it."
http://code.google.com/p/unladen-swallow/wiki/Release2009Q3

Ça évite d'avoir juste des "???" dans gdb ;-)

La modif a été faite directement dans LLVM :
http://llvm.org/docs/DebuggingJITedCode.html

Je viens de voir Le Petit Nicolas au cinéma et je l'ai adoré :-) Le film est très drôle et divertissement.

Il existe le projet GGCC (qui existe depuis... 2007 ?) qui rajoute des extensions à GCC :
http://www.ggcc.info/
http://2008.rmll.info/Projet-GGCC-Global-GCC.html

GGCC utilise par exemple du LISP et du Prolog pour les vérifications, et se branche sur GCC avec ICI :
http://ctuning.org/wiki/index.php/CTools:ICI

« The Interactive Compilation Interface (or 'ICI' for short) is a plugin system with a high-level compiler-independent and low-level compiler-dependent API to transform current compilers into collaborative open modular interactive toolsets. The ICI framework acts as a "middleware" interface between the compiler and the user-definable plugins. »

Et au sujet des plugins, il y a cette page qui explique un peu plus de choses :
http://gcc.gnu.org/wiki/GCC_Plugins

s'engager au freeze, la garanti de non-evolution...

Il ne s'agit que de figer le langage, la bibliothèque standard va continuer à évoluer, comme indiqué dans la dépêche.

je pense que la synthaxe reste perfectible

Les ajouts récents (with, décorateur de classe, etc.) sont du sucre syntaxique, càd qu'on peut s'en passer. Je pense que le noyau dur du langage (définition d'une fonction/classe, les modules, les boucles, les exceptions, etc.) est stable et cohérent, et qu'on devrait y survivre durant quelques années. S'il y avait des énormités insupportables, ils ont été corrigés ou alors ce n'était pas si insupportable que ça :-)

si je ne balance pas ver 3.x de python (...) qu'on y perde en performance

Unladen Swallow et PyPy ont un compilateur à la volée (JIT) qui montre de gros gains de performances, c'est très prometteur. Si Python2 devient 5x plus rapide mais que Python3 reste 30% plus lent que Python2, je pense que les 30% deviendront négligeables (ou dumoins, acceptables).

Petit à petit, les nouvelles fonctions et optimisations arrivent plutôt dans Python3 que dans Python2.