Hardening consulting

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.

Lire la suite…

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.

Lire la suite…

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.

    Lire la suite…

FreeRdp

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.

Rendre les écritures non bloquantes

De quoi s'agit-il ?

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.

Lire la suite…

Le problème

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.

Lire la suite…

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.

Lire la suite…

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.

Lire la suite…

rdc-iconJ'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.

Historique

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:

  • les clients RDP deviennent très compliqués car ils doivent gérer plein d'opérations vectorielles pour avoir de bonnes performances. Les clients RDP legacy (les terminaux légers pas facilement mettable à jour) restent avec leurs capacités à la sortie d'usine;
  • le serveur aussi devient compliqué car il doit s'adapter aux clients et donc avoir des conditionnelles un peu partout dans le code pour faire un rendu avec des commandes supportées;
  • le monde graphique a bien changé et le temps des rendus vectoriel est révolu, quasiment tous les toolkits graphiques maintiennent le contenu à afficher et envoient sous forme d'un gros bitmap le résultat. On perd donc complètement la notion de commandes vectorielles.

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:

  • les clients deviennent plus faciles à coder, ils peuvent ne supporter que quelques codecs;
  • les encodeurs / décodeurs de protocole peuvent être fondus dans le silicium pour avoir de meilleures performances. Par exemple le codec h264: de plus en plus de machines disposent d'un encodeur / décodeur matériel h264 (même mon téléphone portable en a même un);
  • le serveur peut faire des heuristiques sur le codec à utiliser pour différentes parties de l'écran;
  • en ayant des encodages avec pertes, on va améliorer le volume de données

RemoteFX

Je ne vais pas rentrer dans les détails de technique de compression remoteFX car je ne suis pas compétent dans le domaine.

Lire la suite…