Vieilleries

Quelques vieilleries vues pendant ces quelques mois qui font tache dans un OS du XXIe siècle:

* Un vieil IKE de fin 2000 dans lequel AES s'appelle encore Rijndael ....
1016 at@khany:~> sudo racoon -vF
Foreground mode.
2006-10-24 20:39:54: INFO: main.c:176:main(): @(#)racoon 20001216 20001216 sakane@kame.net

* Des BPF dont les descripteurs de fichiers ne supportent pas select() : il n'y a pas de moyen simple d'appeler libpcap seulement quand on est sûr qu'il y a un paquet, ce qui ne facilite pas l'écriture d'applications d'écoute réseau un peu malignes (c'est dans FreeBSD depuis 4.3).

* Un SMBFS qui ne supporte pas le passage direct en SMB sur le port 445 et impose donc aux serveurs d'avoir NetBios sur TCP alors que c'est en voie d'abandon partout. Pas de signature de paquet non plus (alors que l'utilitaire smbclient livré supporte ces deux fonctions).

Mise en veille - 2

Ce soir le mac s'est réveillé tout seul dans mon sac ... Du coup il était brûlant en le sortant. Peut être quelqu'un a branché une souris pendant que j'avais le dos tourné dans le train, qui sait ?

Accéder à /tmp

MacOS a la désagréable manie d'essayer de cacher ses origines prolétariennes et son lourd passé Unix. Ainsi le Finder cache systématiquement les répertoires systèmes tels que /usr, /tmp et /var. On peut changer le comportement du Finder en tapant la douce ligne de commande defaults write com.apple.Finder AppleShowAllFiles true . Le problème c'est qu'apparaissent alors sur le bureau les fichiers Desktop DB et Desktop DF, qu'il faut donc planquer sous le tapis en les amenant dans un coin ou il ne gênent pas trop.

Bon ensuite naivement je pensais que j'allais avoir le même comportement dans le FileChooser, et que j'allais pouvoir ouvrir mes MP3 dans /tmp. Que nenni:



Après j'ai appris que je pouvais taper / et avoir accès à ça:



J'aurais pu m'en satisfaire, sauf que ça ne marche que dans les Applis COCOA (les trucs plus mieux bien) et pas dans les applis CARBON (un truc caca préhistorique qui doit mourir bouh).

Évidemment comme moi je suis préhistorique j'utilise beaucoup d'applications pas belles bouh, dont FireFox et Java. Comme je suis aussi très pervers j'ai donc créé un répertoire $HOME/slash dans lequel j'ai des liens vers /tmp et consorts. Haha.

Nawak à 200$

Rien à voir avec le Mac, mais j'ai été atterré par cette maquette Apollo : 200$ pour un truc moche ou le LM est à l'envers ! (Sans parler de la taille relative de l'ombilical entre le CM et le SM).

Firewall

MacOSX utilise le firewall ipfw de FreeBSD. Ce firewall est déjà largement moins bon que les deux autres qui étaient disponibles sur FreeBSD (pf et ipf), mais il est également très mal utilisé. Une interface graphique (pas très pas jolie ni intuitive) permet de le configurer, on trouve en particulier cette boite de dialogue "Advanced" :



Notez bien "Block UDP Traffic", puis allez voir avec ipfw show -a les règles générées, parmi les quelles:

20321 0 0 allow udp from any 67 to me in
20322 0 0 allow udp from any 5353 to me in
20340 0 0 allow udp from any to any dst-port 137 in
20350 0 0 allow udp from any to any dst-port 427 in
20360 0 0 allow udp from any to any dst-port 631 in
20370 0 0 allow udp from any to any dst-port 5353 in
22000 0 0 allow udp from any to any dst-port 3283 in
22010 0 0 allow udp from any to any dst-port 5900 in
22020 0 0 allow udp from any to any dst-port 123 in

Les deux premières sont très intéressantes : en prenant un port source égal à 67 (DHCP) ou 5353 (multicast DNS), vous pouvez accéder n'importe quel port UDP de la machine, ce qui est euhh ... contradictoire avec la première case à cocher. D'autre part, quand vous choisissez "Stealth Mode", vous avez la vague impression que votre système ne va pas envoyer plein d'infos quand on va le titiller sur le port Bonjour. IPFW possède pourant un moteur à états, capable de maintenir une pseudo-session UDP. Apple n'a visiblement pas jugé utile de l'utiliser, ce ne serait pourtant pas très compliqué de faire de meilleures règles un peu moins larges tout en sauvegardant le plug-and-play, ou alors de faire un bouton "Hellen Keller stealth mode" pour ceux qui branchent leur mac sur des réseaux pas très sûrs.

Evidemment rien ne vous empèche de réécrire vous même les règles manuellement et de profiter du moteur d'état, mais bon, il y a quand même tromperie sur le niveau de sécurité annoncé.

Please call the irony police !

Reçu aujourd'hui :

From: Apple Research <macresearch@apple.com>
Date: Fri, 13 Oct 2006 09:54:02 UTC
Subject: Apple vous invite à participer à un important sondage

Cher/chère Alain, Apple prend en considération votre opinion et vous invite à participer à un sondage concernant votre expérience avec les ordinateurs Mac. Vos suggestions sont grandement appréciées et nous aideront à comprendre comment nous pouvons mieux répondre à vos besoins. Ce sondage est mené pour nous par LRW, une société indépendante de recherche en marketing.

Je pense que j'ai des lecteurs facétieux.

Verrouiller l'écran

J'aime bien pouvoir verrouiller mon écran en une seule combinaison de touches . Je sais faire avec sous Unix avec X11 (grâce à xbindkeys par exemple ou d'autres programmes selon le Window manager utilisé). Je sais faire sur Windows qui a un raccourci en standard. Je me suis dit que MacOSX avait ça évidemment, c'est une fonction qui semble assez naturelle.

On peut assez facilement activer le screen-saver sur MacOS en utilisant des "hot-corners" (mettre la souris en haut à gauche par exemple), on peut aussi faire apparaître un petit menu avec un verrou so cute en utilisant "KeyChain Access" et en précisant "Show Status in Menu Bar". Ce petit menu a un choix "Lock Screen":



Après quelques jours, je me suis demandé pourquoi sélectionner ce menu ne verrouillait pas toujours mon écran. J'ai fini par comprendre un truc incroyable : vous sélectionnez le choix "Lock Screen", vous lachez la souris, et vous ne devez surtout pas la bouger avant que le screen-saver ne soit lancé (ce qui peut prendre quelques secondes si ça swappe, et MacOSX swappe beaucoup). Sinon le screen-saver croit qu'il y a eu de l'activité et que vous avez changé d'avis. Sisi.

Ensuite, pas découragé, j'ai cherché comment activer le "Cmd-L" (ou autre chose) pour déclencher le screen saver par clavier. Je suis allé dans System Preferences/Keyboard et là j'ai vu, oh miracle, qu'on pouvait créer des raccourcis globaux à toutes les applications. Génial !



Sauf que en fait ça ne marche pas. En cherchant pourquoi je suis tombé sur cette page ou quelqu'un sans doute de très bien explique "since this is a keyboard shortcut for a menubar icon, it only works when that area of the menubar is active (“has focus”). Et son contournement est délirant : il faut, pour activer le focus, faire auparavant Ctrl-F8. Pour simplifier les manipulations clavier il propose donc de mettre le raccourci Shift-Ctrl-F8. Et donc de locker l'écran avec la séquence Ctrl-F8 Shift-Ctrl-F8.

Bonk. Bonk.

Bizarreries Réseau (2)

Bon en fait c'est plus qu'une bizarrerie, c'est un gros bug. Gros gros, qui montre que le passage de MacOS des processeurs PowerPC à Intel est pas si tranquille que ça.

Je développe un logiciel de détection d'anomalie de trafic réseau, un petit truc qui doit permettre de repérer les malins qui font du SSH dans HTTPS ou un tunnel IP dans DNS ... Pour cela, il est nécessaire d'écouter le réseau, mais également de reconstruire le trafic afin d'obtenir le flux de données tel qu'il est lu à l'autre bout. Cela nécessite donc de réassembler le trafic TCP, ce qui n'est pas très simple, et ce que fait (imparfaitement) par exemple libnids. J'ai parlé de ce truc en gestation à SSTIC06.

Quand j'ai commencé à porter ce petit travail sur mon Mac, libnids ne reconnaissait aucun trafic. J'ai commencé par penser que le portage de libnids était un peu moisi (ce qu'il est), puis j'ai examiné le trafic remontré par libpcap (dans tcpdump ou ethereal), et j'ai constaté que tous les checksums des paquets TCP envoyés par ma machine étaient faux.

10:39:29.784579 IP (tos 0x10, ttl 64, id 30135, offset 0, flags [DF], proto: TCP (6), length: 52) 192.70.106.104.61090 > 192.70.106.100.22: .,cksum 0x5580 (incorrect (-> 0x7e1c), 192:192(0) ack 2657 win 65312

Jusque là, ce n'est pas un bug en fait: les cartes Ethernet récentes savent calculer les checksums TCP en hardware, dans mon cas, les paquets émis au final sur le réseau étaient corrects (on peut juste regretter que libpcap n'aie pas accès au vrai paquet).

Je suis donc parti à la recherche d'une option permettant de désactiver la gestion hardware des checksums TCP, et après avoir pas mal cherché dans les forums de geeks MacOS qui font du réseau (c'est pas la majorité), je suis tombé sur deux sysctl \o/:

net.link.ether.inet.apple_hwcksum_tx: 1
net.link.ether.inet.apple_hwcksum_rx: 1

Il y avait donc plus qu'à les mettre à 0 pour que le système se mette à les générer (et à les vérifier) au lieu de laisser la carte le faire. Je fais donc:

1007 root@khany:~> sysctl -w net.link.ether.inet.apple_hwcksum_tx=0
net.link.ether.inet.apple_hwcksum_tx: 1 -> 0
1008 root@khany:~> sysctl -w net.link.ether.inet.apple_hwcksum_rx=0
net.link.ether.inet.apple_hwcksum_rx: 1 -> 0

Et la c'est le drame : plus moyen d'ouvrir un terminal, plus moyen de faire sudo, la résolution de nom marche plus, plus aucune appli ne se lance. C'est un symptôme assez connu sur MacOS qui indique que le réseau est mort : le système passe son temps à se causer sur lui même sur 127.0.0.1 pour interroger NetInfo (une vieille réminisence de NextStep de 1990 qui résiste, on se plaint pas, ca pourrait être du XML et du SOAP) . Quand le réseau est mort, le reste va suivre assez vite. Si vous avez de la chance vous avez encore votre shell root ouvert et vous remettez les deux valeurs à 1. Si vous avez pas de chance vous faites un ON/OFF brutal.

Vous réfléchissez, vous recommencez prêt à remettre la valeur à 1, vous regardez ce que donne tcpdump -lnvv -i lo0 et vous vous apercevez que les checksums TCP calculés par MacOS sur Intel sont faux. Ils sont faux sur Ethernet, mais la carte les recalcule quand même, ce qui fait que vous gardez votre connectivité avec les autres machines. Ils sont faux aussi sur le loopack et comme par le deuxième sysctl vous avez demandé à les vérifier, tous les paquets sont rejetés. Ils sont sans doute faux pour un bête problème d'Endianness et de raccourci dans les calculs, j'avoue que je n'ai pas cherché _ou_ ça merdait.

J'ai posté ce bug avec sa description sur bugreport.apple.com le 1er Mai, on m'a attribué le bug #4532260. 5 jours plus tard j'ai reçu un mail me disant que mon bug était un duplicate d'un autre (comment le savoir ?) et que "After further investigation it has been determined that this is a known issue, which is currently being investigated by engineering." Depuis il y a eu 4 updates de systèmes, et le bug est toujours la dans MacOS 10.4.8.

Ce bug est grave parce qu'il montre qu'il y a des problèmes d'Endianness qui trainent dans le portage Intel. Il en est des plus faciles à contourner (j'en ai un autre sous le coude dont je vous parlerais), mais il y en a probablement qui ont des conséquences sur la sécurité. Il est grave aussi parce que en gros ça marche par miracle et que la qualité est pas là ... Ce que je n'ai pas encore compris, c'est pourquoi les checksums TCP sont corrects sur ppp ...

Pour finir, il n'est donc pas possible sur MacOS Intel de faire un système de détection d'intrusion réseau(NIDS) valide : il est en effet impossible de savoir si les paquets émis par la machine ont vraiment un checksum invalide ou pas, et il faut donc se résoudre à ça:

/* AT 20060501 Grrr
if (my_tcp_check(this_tcphdr, iplen - 4 * this_iphdr->ip_hl,
this_iphdr->ip_src.s_addr, this_iphdr->ip_dst.s_addr)) {
nids_params.syslog(NIDS_WARN_TCP, NIDS_WARN_TCP_HDR, this_iphdr,
this_tcphdr);
return;
} */

Autant dire que c'est dangereux, parce que quelqu'un de malin va balancer des paquets contenant des données vues comme normales, alors qu'elles ne seront pas acceptées par le système distant.

Bizarreries Réseau (1)

Bon en lisant la suite vous allez dire que j'abuse. Mais non en fait.

Comme je l'ai dit, je fais des choses bizarres dans mon métier. Mais la couche réseau de MacOS, elle, elle est très bizarre. J'ai plein de petits exemples, alors on va commencer sur un que vous pourrez reproduire chez vous. Imaginons que la carte Ethernet ait l'adresse 192.168.230.5 et tapez les commandes suivantes:


1017 root@khany:~> route add 10.0.0.1 192.168.230.5
add host 10.0.0.1: gateway 192.168.230.5
1018 root@khany:~> telnet 10.0.0.1
Trying 10.0.0.1...
telnet: connect to address 10.0.0.1: Cannot allocate memory
telnet: Unable to connect to remote host

"Cannot allocate memory" ? WTF ! Évidemment dans le man de connect(2) cette erreur n'est pas prévue. Je ne comprends meme pas comment elle peut se produire d'ailleurs, j'imagine qu'il y a une boucle quelque part dans le noyau, ça fait un peu peur. D'ailleurs ce n'est pas propre à TCP, en icmp c'est pareil:

1022 root@khany:~> ping 10.0.0.1
PING 10.0.0.1 (10.0.0.1): 56 data bytes
ping: sendto: Cannot allocate memory

Je n'ai retrouvé ce comportement sur aucun autre système Unix (qui peuvent avoir des comportements divers selon la configuration du routage: soit ils répondent sur cette adresse, soit ils se mettent a renvoyer plein de ICMP Redirect, soit ca se perd).

[Edit: Radar #4782601]

iCal

J'aime bien iCal. J'aime bien les gens qui l'ont écrit, ils montrent qu'il reste (ait?) de la place pour des équipes de développement en Europe, qu'il reste de la place pour faire de la qualité, des trucs jolis et pas trop lourdingues, et qui ne soient pas web-centric.

Sauf que je ne peux quasiment pas me servir d'iCal dans mon travail : mes collègues et mes clients (comme la plupart des gens dans le monde professionnel) ont pris la désagréable habitude de se référer aux numéros de semaine pour dater des évènements.

iCal sait saisir et afficher des tâches débutant en Arabe ancien et se terminant en Klingon, mais ne sais pas afficher un putain de numéro de semaine dans la colonne qui va bien.

"Alain, on peut faire un audit machin semaine 47 ?"
"Attends je finis de porter /usr/src/usr.bin/ncal sous MacOS et de voir à quoi ça correspond et je te réponds !"

Bon j'exagère, en pratique je me balade avec un QuoVadis Bleu pâle du meilleur effet, mais il est impossible que je sois le premier à demander ça. Et iCal a bientot 4 ans, et c'est la version 2.0.4.

Et non, il n'y a pas non plus de n° de semaine dans le widget Calendrier de Dashboard.

Ergonomie (1)

MacOS est censé être très user-friendly, mais NextStep de 1990 sur lequel MacOSX est fondé avait selon moi de sérieux soucis d'ergonomie, et ces problèmes ressortent régulièrement, en particulier dans le Finder (que pour ma part j'ai renoncé un peu à utiliser: un shell, "cd" et "open" ça va à peu près), mais pas seulement.

Une des choses sur lesquelles je peste régulièrement, ce sont les "tabbed dialog" (enfin je crois que c'est cela le nom). Un des exemples les plus flagrants de leur dramatique destinée c'est ça:



"Je voudrais imprimer seulement cette page. Où est le numéro de la page ?" "Il est sous la boîte !" On peut la déplacer ? "Nan, il ne faut pas compliquer la vie de l'utilisateur avec des boîtes de dialogues qui se déplacent !". Bref.

De même dans Firefox, qui utilise les tabbed dialogs pour les alertes Javascript, ce qui m'empêche de faire de beaux screenshots pour montrer des attaques de Cross Site Scripting (on ne voit plus l'URL). Grr.

Trop compliqué pour moi.

Quand le mac est livré il a un fond d'écran en dégradés. N'ayant pas forcément beaucoup de goût, je préfère un fond d'écran uni bleu foncé (pour vous dire comme je suis original, j'ai une voiture gris metallisé).

Bref j'ai voulu aller dans System Preferences/Desktop & Screen Saver, et mettre un fond bleu foncé. Chouette, un bidule marqué "Solid Colors", ça doit être ça ! Comment fait-on pour choisir une autre couleur, on doit cliquer quelque part je suppose...



Click Click Click Click ... Grmmmbbll Click Click Click ... RHAAA PUTAIN COMMENT ON FAIT !?


Après avoir demandé de l'aide à un ingénieur système MacOS reconnu: on fait pas. On prend ImageMagick compilé depuis Darwin Ports (y a pas de logiciel de dessin bitmap livré avec MacOS), on crée un fichier de 10x10 de la bonne couleur, on va le poser dans /Library/Desktop Pictures/Solid Colors et on le voit apparaître. Après on m'a dit que j'aurais pu faire un glisser/déposer. Ah.

Wifi (2)

Au boulot nous utilisons une borne en Wep only, qui ne sert qu'à monter un tunnel vers le LAN interne via un firewall et des trucs compliqués. Le collègue qui a installé la borne a fait preuve d'imagination, et comme il a bien compris comment marchait le Wep, il a mis 4 clés qui tournent de temps en temps. Il faut donc préciser l'index de la clé utilisé, index qui est envoyé dans chaque paquet.

Sous Linux on fait:

iwconfig eth1 enc [2] aaaa-bbbb-cccc-dd
iwconfig eth1 key [2]

Et sur MacOS on fait ... Ben on fait pas, il n'y a pas moyen d'entrer cet index. Il n'y a pas moyen ni dans l'interface graphique, ni dans l'IOKit, ni dans aucun ioctl connu. Je ne suis pas le seul à avoir cherché, j'ai passé de longues heures sur Google et dans les forums de macounets. C'est d'autant plus débile que toutes les cartes et tous les drivers ont probablement la fonctionnalité nécessaire. Et c'est dans la norme depuis le premier jour.

Bref à cause de moi on a remis la clé d'index 1.

Mise en veille

Il y a truc que je trouve complètement débile sur MacOS : la système se réveille quand on enlève un périphérique USB. Si vous avez un esprit assez logique, quand vous partez du taf ou de la maison, vous passez votre machine en veille en allant avec la souris dans le menu Pomme puis vous choisissez "SLEEP". Vous fermez alors l'écran de votre portable, puis vous débranchez les cables, dont celui de la souris.

Et la le mac se réveille. Vous l'entendez très bien parce qu'il essaye d'éjecter le CD-Rom (qui n'est pas la, ça aussi c'est débile, mais passons). Et comme sur une machine à 3000 euros il y a un détecteur de fermeture de l'écran, il s'aperçoit qu'il est fermé, et il se remet en veille immédiatement. Pas de mal allez vous dire, c'est juste un peu bizarre. Oui. C'est même complètement débile, mais ça peut avoir des conséquences potentielles plus graves que j'ai essayé d'expliquer dans ce bugreport (bon j'ai peut être été trop douloureusement ironique pour eux):




La réponse n'a pas été très encourageante:

Hello Alain,

This is a follow-up to Bug ID# 4666288. We have received the
following update regarding your report:

<GMT04-Aug-2006 18:33:00GMT>, XXXX YYYYY:
Engineering has determined that this issue behaves as
intended based on the following information:

Please note, when the machine is closed and the machine
is a sleep, the mouse is in _suspend_ mode.
When the mouse is unplugged, it generates a notification
that it is unplugged.
The OS receives the notification (wakes up) determines
that the lid is closed and puts the machine back to
sleep. This is as designed.

Thank you for taking the time to submit this report.

Best Regards,

The Bug Reporting Team
Apple Developer Connection

*****************************************************************
THE INFORMATION CONTAINED IN THIS MESSAGE IS UNDER NON-DISCLOSURE


Chez Apple je suis sûr qu'il y a eu des jours de meeting pour choisir la couleur des trois petites boules en haut à gauche de chaque fenêtre, mais pas une personne pour se dire que enlever un cable ne devrait pas réveiller la machine. Peut être je ne raisonne pas assez bien, ou alors c'est un complot avec les marchands de piles pour vendre des souris sans fil.

Le NON-DISCLOSURE est assez rigolo :)

Wifi (1)

Je ne peux pas lancer ethereal (enfin wireshark maintenant) quand j'utilise le Wifi : je suis immédiatement désassocié de la borne. C'est systématique et complètement reproductible, même sans lancer le sniff en mode promiscuous. Ca ne se produit pas avec tcpdump, mais d'autres outils ont le meme problème (en particulier ceux qui utilisent libnet).

Il est possible que cela soit lié à l'ouverture de sockets Raw pour lister les interfaces réseau.

C'est très très très handicapant dans mon travail.

[Edit: Radar #4779825, mais voir ce post]

Pourquoi tant de haine.

J'utilise MacOS X sur un Mac Book Pro depuis fin Mars. Ce blog , sans violence et sans haine, se veut seulement un témoignage de mes expériences avec cette machine et ce système.

J'ai pendant très longtemps utilisé (disons depuis 1997) seulement FreeBSD et Linux, pour le travail comme pour la maison. Au travail (je suis consultant en sécurité informatique), j'ai souvent utilisé Unix à ses limites, en faisant des choses que peu de gens font tous les jours (tunnels IP divers, écoute du réseau, lancement de dénis de service, routage et bidouillages divers de paquets, ...) tout en ayant une activité bureautique assez standard pour un Unixien (mail sous Mutt, vim, OpenOffice pour mes rapports et présentations, Mozilla Firefox, ...).

Ma machine portable précédente (un Compaq 2710 de Juin 2003 que j'utilisais sous Gentoo sans jamais la maintenir à jour) étant en train de mourir (batterie HS, clavier effacé, divers pains sur le plastique) , j'ai demandé à mon patron un nouveau portable, et à mon âge, avoir une machine statutaire qui en jette me semblait nécessaire . Comme les Mac me semblaient enfin avoir un processeur décent et que j'en avais un peu marre des merdouilles Linux (genre la gestion ACPI, la lenteur de X11, le support Java merdique, etc) et de la déliquescence de FreeBSD, j'ai décidé de faire l'expérience MacOS (d'autant que en plus BootCamp venait de sortir et qu'on m'avait dit que ceux qui ont des Mac baisent).

Je ne suis pas un newbie en Macintosh et dans le monde Apple: j'ai utilisé par intermittence des Macs entre 1986 et 1998 (j'en ai même réparé quand je travaillais la), et je connais bien la dualité d'Apple: avoir des trucs très smooth d'apparence qui font très pro, et des bugs horribles dans le matériel et dans le système d'exploitation, sans parler de la politique commerciale.

Bref, je pensais que j'allais pouvoir utiliser MacOS X comme un FreeBSD plus stable, tout en frimant avec la zapette infrarouge et en faisant des trucs de ouf avec Exposé.

Je n'allais pas être déçu ...