J'avais évoqué au début de l'année dernière des talks qui m'avaient bien plu
au CCC 2014. Il y avait notamment ce talk sur la sécurité de Xorg, et bien les fixes
ont été intégrés et une annonce officielle a été faite.
De retour de Bordeaux où se tenait XDC 2014, la conférence des développeurs de Xorg et
de ses petits amis (Wayland, MESA et autre GLeries).
Tout d'abord l'ambiance de la conférence était plutôt sympathique, les étrangers semblaient
apprécier l'air français. Comme touriste, Bordeaux by night est vraiment magnifique.
Ça a aussi été assez déroutant de passer 3 jours à parler anglais tout en étant en France.
La période estivale sans beaucoup de nouvelles publiées ici. Non qu'il ne se soit
rien passé, mais rien qui justifie un post.
Cette année j'assisterais à la conférence XDC (Xorg Developpers Conference) qui se tient à Bordeaux. Pour une fois ce n'est pas trop loin, donc autant en profiter.
Un petit retour sur la mouture 2014 du SSTIC. Je crois que cette année a été une
très bonne édition, en tout cas il y a eu peu de conférences qui ne m'ont pas intéressé.
Et puis le SSTIC c'est aussi l'ambiance, les rencontres, le social event (évidement) et
l'impression d'être avec une communauté qui comprend ce que tu dis.
Parmi les conférences qui m'ont un plus émoustillées que les autres:
Celle sur la sécurité des boxes ADSL. L'approche est rigolote car d'habitude on recherche plutôt des choses en attaquant la box sur son interface ethernet: celle qui a la majorité des services publiés. Là, les attaquants ont décidé de s'attaquer à l'interface ADSL et de se faire passer pour le DSLAM pour faire du man-in-the-middle sur la ligne téléphonique. Ils ont trouvé des trucs sympas avec des boxes qui acceptent des mises à jour maison. De plus l'attaque semble plus que pertinente car la surface d'attaque (la ligne téléphonique) est généralement peu protégée et en plus sur la voie publique: on peut déployer le dispositif d'écoute sans gros risques dans une armoire téléphonique dans la rue.
Ces dernières semaines, j'ai travaillé à rendre les écritures sockets non bloquantes dans FreeRDP. Ceci m'a permis de faire une petite balade dans les composants bas-niveau de FreeRDP, je vous propose donc un petit carnet de voyage.
Dans FreeRDP actuellement, les appels en lecture sont bien gérés de manière non-bloquante: on s'attend a des résultats EAGAIN ou EWOULDBLOCK lors des lectures / écritures. Par contre pour l'écriture, quand on a ce genre de résultats, on rentre dans une boucle qui va attendre de manière active que les octets aient bien été envoyés. On est donc bloquant pour l'écriture même si la socket est en mode non-bloquant.
On ne rencontre quasiment jamais ce cas en utilisant le client FreeRDP car la majorité du trafic va du serveur vers le client. On imagine difficilement une saturation de la bande passante à coups de frappes clavier ou de mouvements de souris. On peut néanmoins voir ça en utilisant des channels: par exemple la redirection de disques (en poussant un fichier vers le serveur) ou la redirection audio du micro (le micro local exporté sur le serveur).
Par contre quand on est dans FreeRDS, en tant que serveur RDP, c'est un cas que l'on rencontre très fréquemment. Il suffit de regarder une vidéo youtube en fullscreen à travers un réseau WIFI moyen (le mien pour ne pas le nommer), et on tombe tout de suite dans le cas en question. Et ceci malgrés la compression remoteFx.
OpenSSL a la "bonne" idée de vouloir fabriquer de l'entropie en se servant de la pile comme une source de valeurs "au hasard". C'est une entropie toute relative, qui a d'ailleurs donné le bug debian de 2008: le mainteneur debian d'openssl était agacé des erreurs de variables non-initialisées remontées par valgrind. Il a introduit un correctif enlevant les erreurs valgrind, mais réduisant les nombres aléatoires générés à quelques millions ce qui permettait de lister toutes les clés possibles. Une belle conséquence avec tout le matériel cryptographique généré avec cette version d'openSSL à recréer, et sûrement des serveurs qui tourne encore avec des clés facilement devinables.
Bon c'est bien beau, le mainteneur debian a fait son méa-culpa, mais on est quand
même bien embêté par toutes ces erreurs de valgrind quand on a le malheur de faire
un peu de SSL.
En travaillant autour du sessionManager de FreeRds, j'ai eu l'occasion de travailler
avec le binding python de Thrift.
Thrift est un nième framework de serialization de données. L'avantage pour notre projet est qu'il fournit directement une couche de transport avec un style RPC.
Comme avec protobuf, on a un fichier IDL qui décrit les messages et les méthodes. Ensuite le compilateur génère ce qu'il faut pour gérer ces messages. Pour Python, dans mon cas, ça ressemble à ça:
# thrift --gen py:twisted moninterface.thrift
Le résultat est dans le répertoire gen-py.twisted.
J'ai récement appris que le compositeur RDP de weston allait être proposé pour
compilation dans Tizen par défaut.
Celà faisait un bout de temps que j'étais agacé par wordpress. Tout le temps des
mises à jour, il y a même eu une fois une mise à jour, soit-disant annodine,
du plugin gérant les traductions qui m'a corrompu mes articles.
La fameuse mise à jour annodine m'a obligé à repasser sur tous les posts pour remettre correctement les informations de langages.
Le genre de truc que j'adore.
J'ai eu l'occasion de faire quelques corrections sur le code qui gère l'encodage remoteFx dans FreeRDP, j'en profite donc pour faire un petit article sur ce sujet.
RemoteFx est un codec pour encoder les images bitmap dans RDP. Il y a quelques années, on essayait à tout prix de rajouter des opérations vectorielles dans le protocole RDP: dessiner un rectangle avec une couleur, bouger un bout de l'écran d'une position à une autre, faire des opérations compliquées de bitmap... On se rend compte que Microsoft essayait de transposer ce qui est faisable avec GDI dans le protocole RDP, ce qui donne des opérations vectorielles assez subtiles. Par exemple les opérations de type ninegrid sont vraiment compliquées (lire incompréhensibles).
Au final, le résultat n'est pas si satisfaisant que cela:
L'accent a donc été mis sur la recherche de codecs permettant d'avoir une optimisation de la bande passante sans rajouter d'opération vectorielles compliquées. En procédant de la sorte:
Je ne vais pas rentrer dans les détails de technique de compression remoteFX car je ne suis pas compétent dans le domaine.