Allwinner, une société chinoise qui conçoit des Socs, utilisés principalement dans des smartphones, et tablettes Android bon marché, mais aussi dans les Orange Pi, semble avoir livré une version du noyal avec une backdoor suuuuuuuuuuuper facile a utiliser en local, un:
echo "rootmydevice" > /proc/sunxi_debug/sunxi_debug
permet passer root.
Pour les systèmes concernés, je vous copie-colle texto, je suis trop occupé à rire.
*NB, je pense que quelqu’un a oublié de virer du code de test, d’où mon ricanement.
http://forum.armbian.com/index.php/topic/1108-security-alert-for-allwinner-sun8i-h3a83th8/
http://arstechnica.com/security/2016/05/chinese-arm-vendor-left-developer-backdoor-in-kernel-for-android-pi-devices/
# Oups
Posté par Frank-N-Furter . Évalué à 9.
J'ai oublié de coller la description des systèmes potentiellement concernés.
This security flaw is currently present in every OS image for H3, A83T or H8 devices that rely on Kernel 3.4: this applies to all OS images available for Orange Pis (except Armbian 5.10 available since yesterday), any for FriendlyARM's NanoPi M1, SinoVoip's M2+ and M3, Cuebietech's Cubietruck + and Linksprite's pcDuino8 Uno
Depending on the time of day, the French go either way.
# Code source
Posté par Olivier Esver (site web personnel) . Évalué à 8.
Pour info, le code source est toujours dispo dans le cache de google
S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.
[^] # Re: Code source
Posté par arnaudus . Évalué à 6.
Je ne connais rien au développement de gros projets par des gens sérieux, mais est-il acceptable d'écrire ce genre de code sans l'entourer de petits #ifdef ALPHA_VERSION ou autres garde-fous de base pour éviter la possibilité même que le code puisse passer en production par inadvertance?
[^] # Re: Code source
Posté par gUI (Mastodon) . Évalué à 10.
Et oui c'est possible…
Toujours pareil, l'engineering a certains besoins (debug, automatisation) qui vont à l'encontre des règles de sécurité. Donc l'engineering va développer des backdoor là ou ça l'intéresse.
Si c'est une équipe différente (orientée produit) qui est en charge de récupérer le boulot de l'engineering pour le packager (éventuellement l'adapter) et le livrer au client, il y aura toujours des soucis de communication possible.
"On croyait que vous alliez nettoyer", "on croyait que vous nous aviez pas livré de la merde".
De plus, les tests (automatisé souvent) de qualité sont particulièrement orientés fonctionnalités (ça marche ou ça marche pas ?), souvent orienté performance (conso elec, perfos globales), mais rarement sécurité. Et ça se comprend aussi, parce que sécurité… que tester ? Comment automatiser un mec ingénu qui est capable de passer des semaines/mois à contourner des barrières qu'on a mis en place ? Donc il y a 2-3 sanity checks qui sont effectués (par exemple SELinux activé ? les bonnes partitions read-only ?), mais globalement on teste pas d'aller farfouiller partout pour voir si une backdoor traîne pas.
Le soucis principal est réellement de la communication (documenter, écrire une méthode de nettoyage, se mettre d'accord sur des #ifdef etc), mais comme souvent ce sont des équipes différentes, voire des entités (département) différentes… bin ça peut foirer… oui :(
(vous noterez mon expertise dans le sujet… je suis le co-auteur d'une faille bien involontaire qui a permis quelques root de tablettes… pas la peine de demander plus de précision, vous ne saurez rien de plus :) )
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Code source
Posté par pushmepullme . Évalué à 1.
Ça rappelle à quel point, une équipe de relecteur ce n'est jamais du luxe..
[^] # Re: Code source
Posté par gUI (Mastodon) . Évalué à 5.
Mais tu les mets où tes relecteurs ?
Dans l'équipe engineering ? C'est déjà fait, et elle laisse passer ça pour exactement la même raison que le codeur l'a fait.
Dans l'équipe de livraison ? Impossible, trop de truc à relires et pas assez d'expertise technique.
Pas facile…
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Code source
Posté par pushmepullme . Évalué à 1.
Coté engineering. Mais je suis moins d'accord avec toi quand tu dis qu'elle laisse passer ça..
Oui et non, c'est un peu son boulot de signaler ce genre de travers. Mais j'en conviens, c'est loin d'être évident.
[^] # Re: Code source
Posté par Tonton Benoit . Évalué à 0.
Qui a dit que c'était destiné aux développeurs ?
Pour certains utilisateurs d'Android, la possibilité de devenir root est une fonctionnalité majeure.
[^] # Re: Code source
Posté par groumly . Évalué à 5.
Pour les utilisateurs de linux, windows et macosx aussi.
C'est pas pour autant qu'on peut devenir root avec un simple echo sur ces plate-formes pour autant.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Code source
Posté par Tonton Benoit . Évalué à 2. Dernière modification le 12 mai 2016 à 21:58.
Je dit pas que c'est malin, juste que ça explique peut-être la présence de ce code dans les versions publiques.
Personnellement j'ai bien le process de root des Nexus, c'est facile et officiel, mais en échange toutes les données utilisateurs sont effacées.
[^] # Re: Code source
Posté par Sufflope (site web personnel) . Évalué à 2.
Dans l'espoir que tu comprennes la différence, ainsi que ton moinssage :
le culles étapes précédentes totalement inaperçue[^] # Re: Code source
Posté par Tonton Benoit . Évalué à 2.
T'a pas vu que dans mon message au dessus, je parles déjà de la "bonne façon de faire" ?
Bon mon clavier Android a avalé mon "j'aime" en "j'ai", mais ça reste compréhensible.
TB
[^] # Re: Code source
Posté par vlad59 (site web personnel) . Évalué à -2.
Le vrai problème vient du fait qu'à la base ces puces Allwinner sont prévues pour Android et rooter un Android peut être assez utile de temps en temps.
Donc pour moi c'est volontaire pour le kernel android et ça a été laisser quand ils ont fait des kernel plus classique.
[^] # Re: Code source
Posté par groumly . Évalué à 6.
Ah oui, ya plein de gens qui vont trouver ca super utiles, j'en suis sur. Tu met une appli à la con sur le store, et paf, t'es root, tu peux finalement faire ce que tu veux avec les données des gens.
D'ailleurs, le fbi aurait trouvé ça super utile sur l'iPhone de san bernardino aussi, c'est bien la preuve que c'est une bonne feature.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Code source
Posté par arnaudus . Évalué à 3.
Qu'est-ce qu'on s'embête à mettre des mots de passe root! On devrait carrément se logguer en root, d'ailleurs…
[^] # Re: Code source
Posté par Maclag . Évalué à 6.
Quoi? Mais pourquoi faire aussi compliqué??
La machine devrait directement et automatiquement te loguer en root dès le démarrage! C'est en rajoutant toutes ces étapes inutiles qu'on fait fuir les utilisateurs!
[^] # Re: Code source
Posté par lasher . Évalué à 2.
Finalement, je pense revenir à DOS.
[^] # Re: Code source
Posté par Marotte ⛧ . Évalué à 2. Dernière modification le 22 mai 2016 à 01:48.
Note que pas mal d’utilisateurs d’Haiku demandent à ce que le système reste mono-utilisateur.
« Specific focus on personal computing »
https://www.haiku-os.org/about
On peut imaginer que des applications gèrent des fichiers chiffrés, il suffit que le système demande la passphrase à chaque ouverture/écriture/suppression du fichier… Il faut que le FS permette que certains fichiers marqués "protégés" requièrent l’entrée d’une passphrase au clavier (ou lecture d’un autre fichier) pour passer du disque à la mémoire vive (et dans l’autre sens)…
Je ne sais pas à quel point c’est envisageable, je ne connais pas le FS d’Haiku. Je sais juste que c’est celui repris de BeOS. BeOS qui comme comme chacun sait faisait déjà tout… depuis… pffiou…
On peut aussi imagine stocker aussi, chiffrées ou non, sur des volumes portables (clé USB, carte, …) ses documents et applications personnels… ils seront même ainsi peut-être mieux sécurisés !
```
[^] # Re: Code source
Posté par Chris K. . Évalué à 2.
Ouch… la notion de droits utilisateurs c'est tout de même une petite base bien pratique et éprouvée pour la sécurité. Ça sent la fausse bonne idée cette histoire. Soit ça prend la direction des anciens Windows avec des trous de partout, soit ils sont partis pour inventer un nouveau type de roue… reste a savoir si elle roulera et si elle sera vraiment moins complexe à monter.
[^] # Re: Code source
Posté par Maclag . Évalué à 5.
Bien évidemment: elle aura une forme arrondie avec des plats de chaque côté, comme toute roue.
Ils ajouteront une poignée pour la rendre plus maniable. Un des plats sera plein et l'autre ouvert, avec un couvercle.
Ils privilégieront la céramique ou la porcelaine comme matériau de fabrication.
Est-ce qu'elle roulera?
Sans aucun doute: BeOS faisait tourner les théières il y a 15ans déjà!
[^] # Re: Code source
Posté par Prosper . Évalué à 3.
ils ont aussi oublié de le virer de la branche A83T https://github.com/allwinner-zh/linux-3.4-sunxi/blob/A83T/arch/arm/mach-sunxi/sunxi-debug.c .
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.