NAS : passage au crible du Synology DS-101
Transcription
NAS : passage au crible du Synology DS-101
Ceci est un extrait électronique d'une publication de Diamond Editions : http://www.ed-diamond.com Ce fichier ne peut être distribué que sur le CDROM offert accompagnant le numéro 100 de GNU/Linux Magazine France. La reproduction totale ou partielle des articles publiés dans Linux Magazine France et présents sur ce CDROM est interdite sans accord écrit de la société Diamond Editions. Retrouvez sur le site tous les anciens numéros en vente par correspondance ainsi que les tarifs d'abonnement. Pour vous tenir au courant de l'actualité du magazine, visitez : http://www.gnulinuxmag.com Ainsi que : http://www.linux-pratique.com et http://www.miscmag.com embarqué analyse NAS : passage au crible du Synology DS-101 Denis Bodor EN DEUX MOTS Que vous disposiez de quelques machines personnelles où que vous soyez en charge de l’administration d’un LAN dans une PME, l’utilisation d’un NAS est souvent une bonne idée. Le coût des solutions « entrée de gamme » ne cessant de chuter, nous avons essayé et étudié l’un de ces produits. e modèle sélectionné est un DS-101 fabriqué par la société Synology. Le fabricant présente le produit comme une solution SOHO (Small Office/Home Office) et donc entrant précisément dans le cadre de cet article. Le produit testé est relativement populaire en Europe, mais peu aux États-Unis. En effet, pour quelques 230 Euros TTC, on dispose d’un boîtier dans lequel peut s’intégrer un disque IDE allant jusqu’à 400 Go. Le DS-101 se connecte ensuite à un réseau Ethernet 10/100Mbps et permet différentes utilisations : Partage disque Windows ; Partage disque Mac ; Connexion et partage d’une imprimante (USB) ; Copie automatique de données en provenance de clefs, d’appareils photo ou disques USB. Voilà pour ce qui est des caractéristiques pour monsieur « tout le monde ». En regardant de plus près, les spécifications données par le constructeur, on en apprend un peu plus : Processeur Intel IXP420BB : il s’agit d’un cœur Intel XScale® auquel s’ajoutent une interface PCI, un contrôleur USB et deux interfaces Ethernet 10/100Mbps (une seule est utilisée avec le DS-101). Rappelons que le XScale® est le successeur du StrongARM. 64 Mo de mémoire SDRAM. Ici rien d’étonnant. Comme le montrent les photos illustrant l’article, la mémoire est directement soudée sur la carte mère du périphérique. 64 Mo est une quantité de mémoire relativement importante pour un système embarqué. 16 Mo de mémoire Flash ou plus exactement un M-system DiskOnChip MD2811-D16V3Q18 utilisant la technologie TrueFFS. Un tel disque de mémoire flash est très facile 90 d’intégration. Il apparaît en effet comme un disque pour le système d’exploitation. Protocoles réseau TCP/IP et Apple Talk, bref, du standard. Sélection d’IP via DHCP ou configuration manuelle. Protocoles de partage de fichiers Microsoft Networks CIFS et Apple File Protocol AFP 3.X. Il manque quelque chose. Si, si, cherchez bien... En trois lettres, commençant pas un « N » et finissant par un « S »... Services réseau divers comme FTP, NTP, HTTP... Mise en marche Arrêtons là les spéculations et passons à la pratique. L’intégration d’un disque 3"1/2 est un jeu d’enfant. Quelques vis, une connexion à la nappe et à l’alimentation et c’est fini. Le disque doit être initialisé pour être pris en charge par le périphérique. Un appui maintenu de 4 secondes sur le bouton [reset], suivi d’un nouvel appui après 5 secondes déclenche l’opération. Après deux signaux sonores, le système embarqué dans le DS-101 s’en prend au disque. Nous verrons plus loin ce qui se passe exactement à ce moment. Notons au passage que le disque, après cette étape, devient inutilisable sans reformatage (véritablement inutilisable, cf. plus loin). Une fois le disque initialisé et le produit redémarré, celui-ci s’empresse d’envoyer des requêtes DHCP. Une machine préalablement configurée avec le serveur ICS dhcp3 lui attribue une adresse : DHCPDISCOVER from 00:11:32:00:4a:d4 via eth0 DHCPOFFER on 192.168.0.11 to 00:11:32:00:4a:d4 via eth0 DHCPREQUEST for 192.168.0.11 (192.168.0.10) from 00:11:32:00:4a:d4 via eth0 DHCPACK on 192.168.0.11 to 00:11:32:00:4a:d4 via eth0 Dès lors, le serveur web intégré au boîtier peut être utilisé pour configurer la bête. Un assistant guide l’utilisateur dans les étapes de configurations minimales.Après paramétrage, en bon curieux, on peu se pencher sur le partage Windows : % smbclient -L 192.168.0.11 Password: Domain=[CASSIS] OS=[Unix] Server=[Samba 3.0.0beta3] Sharename --------public IPC$ ADMIN$ Type ---Disk IPC IPC Comment ------System default share IPC Service () IPC Service () Domain=[CASSIS] OS=[Unix] Server=[Samba 3.0.0beta3] Server --------- Comment ------- Workgroup --------- Master ------- Le résultat est clair : Samba 3.0 beta. On dirait bien que nous ayons sous la main un système Linux embarqué pour GNU Linux Magazine France CPU ARM/XScale®. Confirmons le soupçon avec un scan de port : % nmap -O 192.168.0.11 Starting nmap 3.75 ( http://www.insecure.org/nmap/ ) Interesting ports on 192.168.0.11: (The 1657 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 21/tcp open ftp 80/tcp open http 139/tcp open netbios-ssn 445/tcp open microsoft-ds 515/tcp open printer 548/tcp open afpovertcp MAC Address: 00:11:32:00:4A:D4 (Synology Incorporated) Device type: general purpose Running: Linux 2.4.X|2.5.X OS details: Linux 2.4.0 - 2.5.20 Uptime 0.002 days (since Wed Aug 24 14:26:11 2005) Cette fois, plus de doute, il s’agit bien d’un noyau Linux 2.4. Mais pourquoi donc limiter les partages à SMB, AFP et FTP ? Un système embarqué GNU/Linux sur 16Mo de mémoire flash et disposant de 64Mo de SDRAM peut faire bien mieux que cela. Qu’à cela ne tienne, si le constructeur oublie des choses, nous allons les ajouter. Creusons un peu Les pages web de support sur le site officiel proposent divers téléchargements parmi lesquels une image du firmware et les sources en GPL du système Linux embarqué. A ce moment là, on se croit sauvé... mais on déchante rapidement. Après un téléchargement pénible à 16Ko/s depuis un site FTP poussif, on récupère une archive ds101-157.tgz de quelques 157 Mo (je vous laisse le plaisir de faire le calcul du temps nécessaire). Trépignant d’impatience, on désarchive le fichier et... déception. On obtient quelques 25 répertoires contenant les sources plus ou moins modifiées de chaque composant. Apache, BusyBox, IPtables, HotPlug, PHP, uCLinux, uClibC... Pas de README, pas de documentation incluse, rien.Après une petite promenade dans les quelques 627 Mo de fichiers, on en apprend un peu plus. Quelques répertoires debian traînent de-ci, de-là. Les sources d’uCLinux sont quelque peu modifiées et la compilation automatisée via un script. Un répertoire lnxsdk contient du code GPL spécifique au fabricant. Cependant, rien ne permet de construire simplement le système tel qu’il est présent dans le produit final. Laissons de coté les sources pour le moment. Avec beaucoup de courage, de chance et de temps, il doit être possible d’obtenir un firmware fonctionnel. Ceci, à condition de savoir à quoi ressemble le système en question. Pariant sur les bruits, des plus suspects, lors de l’initialisation du disque et de l’allumage du produit, on en arrive à soupçonner le système de ne pas démarrer sur la mémoire flash directement. Si c’est le cas, le système GNU/Linux est donc installé sur le disque intégré au produit. Il nous est donc peut-être possible d’accéder aux données et de modifier directement le système en place. Cette approche, en plus d’être simple, présente un net avantage : elle permet de laisser le firmware du fabricant dans l’état. En effet, en construisant un firmware personnalisé et en le téléchargeant dans le périphérique, nous annulons la garantie. De plus, si le firmware en question n’est pas fonctionnel, une fois en place, nous n’avons plus de solution de rattrapage, puisque la mise à jour se fait via l’interface web. Il doit certainement exister des procédures de secours et de restauration du firmware (un mode debug ?), mais nous n’avons pas accès à ces informations. Le disque sorti de son logement et placé dans une machine se révèle effectivement aussi bavard que prévu : Device Start End Blocks Id /dev/hdd1 1 271 136521 /dev/hdd2 271 1052 393592+ /dev/hdd3 1323 3140 915705 /dev/hdd4 1052 1182 65536 Fig. 1 : La carte du DS-101 semble être relativement générique. On remarque qu’une partie des emplacements sont vides comme sur la droite pour un chip réseau Kendin et au centre ce qui pourrait bien être une extension de bus. Numéro 76 / Octobre 2005 System 83 Linux 82 Linux swap 83 Linux 83 Linux Quatre partitions, dont un swap de quelques 400 Mo !!! On suppose que la première partition est réservée au système ou aux données « variables » du système comme les journaux, etc. La troisième partition, au vu de sa taille, correspond à l’espace de stockage partageable en réseau. Le disque utilisé ici pour le test est un très modeste Western Digital Caviar de 1,6 Go. 91 embarqué Analyse Malheureusement, toute tentative de montage de l’une de ces partitions est un échec. Il ne semble s’agir d’aucun système de fichiers connu de Linux. Les partitions sont pourtant bien marquées d’un type correspondant, mais rien n’y fait. En désespoir de cause, on finit par utiliser hexdump directement sur l’une des partitions : 00010000 00010010 00010020 00010030 00010040 00010050 52 00 84 12 03 01 85 00 03 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 1b 00 1e 53 03 4d 57 20 00 79 00 04 00 00 00 4e 02 59 00 00 00 6f 00 9a 81 00 00 52 02 b8 22 04 00 73 00 1e 00 00 00 32 00 4e 00 00 00 46 00 b2 12 30 00 73 71 a1 00 51 10 00 00 a8 00 c1 cc 00 00 56 00 40 03 00 00 2d |R....W...»......| |..... ......0QÁ@| |..............Ì.| |....SyNoRs2Fs...| |............q...| |....M.Y.¸.N²¡¨V-| La présence d’un répertoire reiserfs362 aidant, on remarque dans les premières données de la partition, la chaîne SyNoRs2Fs : Synology ReiserFS ? Pour en avoir le cœur net, nous avons les sources et, après un rgrep, on finit par trouver la cause du problème dans le fichier reiserfs362/ include/reiserfs_fs.h : #ifdef SYNO_REISERFS #define REISERFS_SUPER_MAGIC 0x25521814 #define REISERFS_3_5_SUPER_MAGIC_STRING «SyNoRsFs» #define REISERFS_3_6_SUPER_MAGIC_STRING «SyNoRs2Fs» #define REISERFS_JR_SUPER_MAGIC_STRING «SyNoRs3Fs» #else #define REISERFS_SUPER_MAGIC 0x52654973 [...] #define REISERFS_3_5_SUPER_MAGIC_STRING «ReIsErFs» #define REISERFS_3_6_SUPER_MAGIC_STRING «ReIsEr2Fs» #define REISERFS_JR_SUPER_MAGIC_STRING «ReIsEr3Fs» #endif Les sources du support ReiserFS ont été modifiées de manière à supporter un identifiant de système de fichiers différent. Mais la modification va plus loin. En effet, en recompilant un module reiserfs.ko légèrement modifié de manière à utiliser un identifiant correspondant aux partitions, nous pouvons monter le système de fichiers. Cependant, les données ne sont pas lisibles, ni même la hiérarchie des répertoires. Le fabricant semble donc effectivement avoir modifié le support ReiserFS au-delà de la simple chaîne d’identification. Chose confirmée par un coup d’œil dans les sources et le fichier /uclinux2422/linux-2.4.x/include/ linux/syno.h et synobios.h. La question qu’on se pose tout naturellement est « Pourquoi ? ». Linux dispose de suffisamment de souplesse et de fonctionnalité pour se passer d’une telle manipulation. Savoir si cette modification est légitime ou non nécessiterait une étude plus approfondie des sources. On y parle effectivement d’« Archive bit support on our ReiserFS ». Bien sûr, il vous reste une solution : comprendre et développer un support GNU/Linux pour votre ordinateur de bureau afin de lire et d’accéder aux données contenues sur les partitions utilisant un système de fichiers ReiserFS modifié. Sachez que les sources reiserfs362 présentes dans l’archive du fabricant se compilent sous GNU/Linux. Mais ce n’est là qu’une partie de la solution. Il vous faudra adapter le code uCLinux à votre système pour obtenir un module noyau. Bonne chance, bon courage ou bon amusement... c’est selon... Une autre voie La solution du disque dur est un échec.Voyons si nous pouvons trouver un autre chemin en regardant du côté du firmware mis à disposition par le constructeur. Nous récupérons donc la « Mise à jour du progiciel pour DS-101 v.2.0.1-3.0200 » sous la forme d’un fichier synology_ixp420_1hd.pat. Comme c’est souvent le cas pour les firmwares, l’extension ne révèle en rien la nature des données, bien au contraire. Il n’est cependant pas difficile de voir de quoi il retourne : % file synology_ixp420_1hd.pat synology_ixp420_1hd.pat: POSIX tar archive Ce qui nous fait embrayer directement sur : % tar xvf synology_ixp420_1hd.pat AllLib.tgz checksum.syno rd.gz updater VERSION zImage Les petits fichiers checksum.syno et VERSION ne sont pas forcément intéressants. On remarque toutefois que le fichier contenant les sommes de contrôle n’est pas standard. Une ligne mentionnant un binaire Synocksum est d’ailleurs commentée. C’est sans doute ce binaire qui est chargé de calculer les sommes de contrôle et il aura été exécuté dans le répertoire, d’où la ligne dans le fichier. Nous n’avons pas trouvé trace de ce type d’outil dans les sources GPL téléchargées. Le fichier updater est un exécutable, on en profite pour vérifier la plate-forme sur laquelle il doit s’exécuter : Fig. 2 : On reconnaît ici le processeur Intel et la SDRAM sur la gauche 92 % file updater updater: ELF 32-bit MSB executable, ARM, GNU Linux Magazine France NAS : passage au crible du Synology DS-101 version 1 (ARM), for GNU/Linux 2.0.0, statically linked, stripped Intéressons-nous maintenant à ce qui semble, d’après son nom, être une image de RAMdisk : % gunzip rd.gz % mount -oro,loop rd /mnt/loop Pas de râlement, il s’agit bien de cela. Le système de fichier ext2 est monté via le périphérique loop0. Pour en apprendre un peu plus, commençons par vérifier notre théorie concernant ReiserFS : % cat /mnt/loop/etc/fstab /dev/ram0 / ext2 defaults 1 1 none /proc proc defaults 0 0 /dev/hda3 /volume1 reiserfs defaults 0 0 La troisième partition du disque est donc bien celle censée contenir les données de l’utilisateur. De plus, elle est effectivement du type attendu. Seul problème, pour le système embarqué dans le DS-101, un système de fichiers ReiserFS n’est pas la même chose que pour une installation GNU/Linux standard. Autre point intéressant qui risque de venir contredire l’hypothèse du système installé sur la première partition, la racine du système est /dev/ram0. Normal, me direz-vous, puisqu’il s’agit d’un RAMdisk et non d’une image initrd. On s’éloigne donc de la théorie de copie du système sur la première partition... mais gardons-la sous le bras tout de même. En poursuivant plus loin l’exploration, tout en gardant dans l’idée d’ajouter ce qui manque au système, nous pouvons remarquer la présence de plusieurs choses. Tout d’abord, nous avons des fichiers de configuration PPPoE qui semblent indiquer qu’un système très proche doit être utilisé dans un produit de partage de connexion (la carte dans le DS-101 dispose d’un second connecteur LAN/WAN non soudé). D’autant plus que des scripts adsl-start ou adsl-status sont également présents dans l’image. Dans le /etc/rc, nous apprenons que la première partition est également en pseudo-ReiserFS et montée en /mnt. Un fichier configs est copié depuis là vers un répertoire /writeable où est monté un tmpfs. Plus intéressant que la lecture du /etc/rc, nous avons la présence d’un lien symbolique vers un démon Telnet BusyBox. % ls -l /mnt/loop/usr/sbin/telnetd /mnt/loop/usr/sbin/telnetd -> ../../bin/busybox utilisateurs par défaut du système sont admin et guest. Serait-il possible que l’utilisateur root soit pleinement configuré ? % cat /mnt/loop/etc/shadow root:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:10933:0:99999:7::: smmsp:*:10933:0:99999:7::: lp:*:10933:0:99999:7::: nobody:*:10933:0:99999:7::: admin:$1$synergy$O31nVEgYyKUdmjDRPUq8p.:10933:0:99999:7::: guest:$1$synergy$O31nVEgYyKUdmjDRPUq8p.:10933:0:99999:7::: % cat /mnt/loop/etc/passwd root:x:0:0:root:/root:/bin/ash [...] Par correction pour le fabricant, nous n’avons pas souhaité imprimer la chaîne chiffrée dans le magazine, mais sachez qu’elle est présente dans le fichier. On en conclura qu’avec un peu de patience et de puissance processeur, retrouver le mot de passe n’est qu’une affaire de temps. On peut donc imaginer qu’un accès root sur le serveur FTP permettrait d’avoir un accès en lecture/écriture sur le système. Mieux encore un shell minimal semble avoir été prévu pour ce compte. Malheureusement, on ne peut que le supposer puisque les sources du serveur ne semblent pas présentes dans l’archive mise à disposition par le constructeur. Sur le point de jeter l’éponge, on découvre qu’une partie de la configuration se trouve dans /usr/syno/etc et en particulier des scripts d’init. La plupart semblent se baser sur le contenu d’un fichier /etc/synoinfo. conf, présent dans l’image RAMdisk. Mais ce fichier est illisible et très certainement chiffré d’une manière ou d’une autre (simple XOR ?). Las, on jette un dernier coup d’œil à la racine du système de fichiers et au contenu du fichier /linuxrc.syno. Les premières lignes nous fournissent l’information manquante pour la quatrième partition. C’est la racine du système : RootDevice=/dev/hda4 MountType=»-n -t reiserfs» % cat /mnt/loop/etc/inetd.conf #telnet stream tcp nowait root /usr/sbin/telnetd telnetd Malheureusement, celui-ci doit être présent à des fins de débogage, puisque la ligne correspondante est commentée dans la configuration du super-démon inetd. Il nous reste le serveur FTP. Bien entendu, celui-ci semble « chrooté » et ne permet pas de remonter à la racine du système. Chose surprenante, l’utilisateur root est présent dans /etc/ftpusers. Les deux Numéro 76 / Octobre 2005 Fig. 3 : Le DiskOnChip de M-System, de plus en plus présent dans les périphériques dits « intelligents ». Une solution idéale pour les systèmes embarqués face aux simples mémoires flash sans logique interne. 93 embarqué Analyse Plus loin dans le script qui semble être exécuté pour l’installation du firmware, on a la confirmation concernant le chiffrement : # copy the crypted version to etc. /bin/cp -f /tmp/synoinfo.conf /mnt/etc Plus loin encore, les lignes semblent confirmer que le disque dur est bien utilisé pour booter : # New created or updated root partition [...] # Check partitions failed, boot from ram disk [...] # Else part, already have root partition, boot normally. Abandon et conclusion La lecture de ce dernier fichier est très intéressante, mais aussi très décevante. Il s’avère que le DS-101 démarre effectivement depuis un système GNU/Linux placé sur la quatrième partition du disque et qu’il doit donc être possible de personnaliser cette installation. Ce n’est qu’en cas de problème ou de disque « vierge » que le système est, semble-t-il, chargé de la mémoire flash et exécuté en RAMdisk. Mais cette information ne nous sert plus à grand-chose. Le seul moyen de monter et de personnaliser cette partition est de modifier le support ReiserFS d’un système « normal » en se basant sur les sources modifiées fournies par Synology. L’utilisation d’un firmware personnalisé est une mauvaise voie puisque nous ne pouvons calculer les sommes de contrôle sans doute vérifiées par le système déjà embarqué. De plus, ceci est très risqué et annulera à coup sûr la garantie constructeur. Mais le vrai risque n’est pas là. Un système de fichiers standard modifié et une configuration stockée dans un fichier chiffré, voilà le problème. Le DS-101 pourrait être, de par son architecture, une petite merveille d’ouverture comme les produits de certains autres fabricants. Pire encore, en tant que simple utilisateur, on constate que les données confiées au DS-101 sont très difficiles d’accès en cas de défaillance dudit DS-101. Le périphérique est vendu comme un NAS d’entrée de gamme et une solution de sauvegarde. Au vu des performances en proportion avec le prix du matériel et des protocoles utilisés, le DS-101 ne permet 94 Fig. 4 : Le boîtier DS-101 : un design très élégant et un silence presque parfait en raison de l’absence de ventilation. Fig. 5 : L’interface de configuration du DS-101 est simple d’utilisation et représente la seule manière de configurer le produit. pas de travailler directement sur les données qu’il contient. Il est donc fait pour la sauvegarde ou le stockage. Comment se convaincre de confier ses données à un périphérique qui semble tout faire pour les « verrouiller » ? Il s’agit là de quelque chose de très pénalisant pour le produit : si votre DS-101 venait à rendre l’âme, la seule manière de récupérer vos données serait d’acquérir un autre DS-101 ou un produit compatible (s’il existe). Cela sera-t-il encore possible d’ici un an ? Que se passera-t-il pour vos données placées là sans doute par souci de sécurité, si ce n’est pas le cas ? La durée de vie de vos données est directement liée, non pas à celle du disque dur, mais à celle du produit et/ou du fabricant du boîtier assurant le partage en réseau. GNU Linux Magazine France NAS : passage au crible du Synology DS-101 Voulant améliorer le produit en lui ajoutant un support NFS, nous avons pu constater ses limitations et les risques importants découlant de son utilisation. Un travail qui s’est avéré long, mais finalement payant. Le produit est retourné chez son distributeur... L’avis du fabricant Nous n’avons pas manqué de demander au constructeur du DS-101 la raison pour laquelle un système de fichiers ReiserFS a été utilisé. La réponse fut rapide et parfaitement claire. C’est un point qu’il est important de relever, beaucoup de fabricants nous auraient sans doute demandé si le firewall de Windows XP est activé et si les voyants du boîtier sont allumés ou clignotent avant même de comprendre notre demande. La très étonnante raison avancée par Synology concerne la confidentialité des données que l’utilisateur place dans le DS101. Grâce à l’utilisation d’un ReiserFS modifié, l’utilisateur 2 n’a pas à s’inquiéter de la protection de ses fichiers en cas de vol du périphérique. Victor Chiang de Synology ajoute cependant que la société projette d’ajouter un support Ext3 dans le DS via une mise à jour du firmware. Je vous laisse juge de cette explication en notant toutefois qu’elle a le mérite de mettre l’accent sur un élément important concernant les disques « transportables » quel qu’ils soient : on peut les voler très facilement. Pensez donc à chiffrer les données sensibles et/ou privées qu’ils contiennent. Denis Bodor, sites incontournables / p t / : Toute l’actualité du magazine sur : t www.gnulinuxmag.com H w www.ed-diamond.com w Abonnements et anciens numéros en vente sur : w