Discussion :

[Cedric Chevalier]

Saviez-vous que votre smartphone exécutait un second système d'exploitation ?
un chercheur crée un code de 70 octets pour tirer profit de ses nombreuses vulnérabilités

Lorsqu’on parle de sécurité pour les plateformes mobiles, machinalement on pense à Android, iOS, Windows Phone. Combien savent qu’à leur insu le smartphone qu’ils tiennent en main exécute un second système d’exploitation qui gère le matériel en relation avec les composants responsables de la fonctionnalité sans fil (à l’exemple de la pile de protocole de télécommunication) ? Probablement pas beaucoup.

Ce second système s’exécute sur une puce spéciale de nom générique « BaseBand processor » dont les plus grands fournisseurs sont Qualcomm, Mediatek et Infineon.

Mais pourquoi focaliser l’attention sur un second système d’exploitation que les revues spécialisées mentionnent peu ou peut-être même pas ? La réponse est simple : il constitue une source de vulnérabilités insoupçonnée.

En effet, les standards qui définissent comment communiquent les « BaseBand processor » datent des années 80 à 90. Époque à laquelle les considérations sur les questions de sécurité n’étaient pas les mêmes qu’aujourd’hui. Ajouté à cela, le second système d’exploitation, en plus d’être propriétaire, est très peu connu et peu documenté, ce qui justifie le fait que jusqu’à maintenant on ait pas observé beaucoup d’exploits qui tirent partie de ses vulnérabilités.

Cette situation est en train de changer. Un jeune chercheur de l’université du Luxembourg s’est penché sur la question et après ses études il est parvenu à exploiter les différentes failles du second système d’exploitation. C’est ainsi qu’il a pu démontrer qu’un message de 73 octets pouvait permettre à un hacker d’exécuter du code arbitraire à distance sur un smartphone.

Avec de telles recherches on espère seulement que des mesures seront prises assez rapidement pour protéger les utilisateurs.


Sources : OS News, étude PDF des BaseBand Processor

Et vous ?

Qu'en pensez-vous ?

[ram-0000]

De toute façon, partout où il y a du code, il y a des bugs. Après est-ce que ces bugs sont exploitables par un hacker ? C'est une autre histoire.

Une carte réseau ethernet aussi contient du code, peut être qu'il y a des paquets magiques qui permettront une exécution de code à distance sur ma machine.

Le problème est que bien souvent, les développeurs de code embarqué ont peu ou pas de notions de sécurité (buffer overflow par exemple) et de développement sécurisé (validation des input par exemple) et on se retrouve avec ce genre de problème.

Cela me rappelle une news sur une chaudière : Faille de sécurité critique dans les systèmes de chauffage. Dans ce cas, ce n'était pas le logiciel embarqué qui était en cause mais le serveur WWW de pilotage de la chaudière.

[phili_b]

Ben c'est une sorte de BIOS ou de Firmware ?! Rien de nouveau non ?

[transgohan]

Ben c'est une sorte de BIOS ou de Firmware ?! Rien de nouveau non ?

Non rien à voir. C'est bien un OS qui fonctionne sur un autre processeur (une autre carte dans ce cas là même).

Le problème est que bien souvent, les développeurs de code embarqué ont peu ou pas de notions de sécurité (buffer overflow par exemple) et de développement sécurisé (validation des input par exemple) et on se retrouve avec ce genre de problème.

C'est malheureusement trop vrai... Je suis dans ce domaine et je n'ai pas de formation (même basique) sur la sécurité.
Et quand on en demande on nous répond que c'est pas notre domaine...
Donc les plus sérieux se documentent dans la littérature ou sur le net mais c'est carrément une minorité...

[abriotde]

Tout programme, comme toute banque, possède des failles. Une rêgle de sécurité base est d'être mieux protéger que son voisin. Les attaquants s'attaquerons toujours au plus vulnérable. Jusqu'ici les OS principaux étaient plus simple a exploiter que le reste, le jour ou cela ne sera plus le cas les failles des autres OS seront exploités. Ca a été le cas avec les PC, on a vu apparaître les exploits de failles de BIOS quand les OS sont devenus assez bien protégés.

[Miistik]

Le problème est que bien souvent, les développeurs de code embarqué ont peu ou pas de notions de sécurité (buffer overflow par exemple) et de développement sécurisé (validation des input par exemple) et on se retrouve avec ce genre de problème.

On ne peut mieux d'accord.

Néanmoins, les développeurs de code embarqué n'ont pas nécessairement les ressources pour aborder ces notions de sécurité.
Je m'explique : les composants dans les systèmes informatisés embarqués sont assez onéreux. Rajouter 10 Mo de mémoire pour sécuriser un minima, peut faire perdre un marché au niveau du prix de vente.

Après, je ne travaille pas dans ce domaine. Mais cette réalité doit exister.

[transgohan]

Le problème est que bien souvent, les développeurs de code embarqué ont peu ou pas de notions de sécurité (buffer overflow par exemple) et de développement sécurisé (validation des input par exemple) et on se retrouve avec ce genre de problème.

On ne peut mieux d'accord.

Néanmoins, les développeurs de code embarqué n'ont pas nécessairement les ressources pour aborder ces notions de sécurité.
Je m'explique : les composants dans les systèmes informatisés embarqués sont assez onéreux. Rajouter 10 Mo de mémoire pour sécuriser un minima, peut faire perdre un marché au niveau du prix de vente.

Après, je ne travaille pas dans ce domaine. Mais cette réalité doit exister.

Dois-t-on en conclure que tu sécurise les buffer overflow par le rajout de mémoire ?

[Bestel74]

Oui en embarqué je confirme que l'on fait plus attention à la fiabilité/légèreté du code qu'à sa sécurité (pourtant fiabilité et sécurité ne sont pas si loin en terme technique, un appelle à strncpy() est plus fiable et plus sécuritaire par ex.).

Beaucoup de fonctions dépréciées sont encore beaucoup utilisées car beaucoup considère les fonctions standard comme "figées" dans le temps, alors qu'elles évoluent et sont remplacées.

scanf() et strcpy() en sont des exemples flagrants.

D'ailleurs n'est-il pas possible de demander à gcc d’émettre un Warning lors de l'utilisation de ce genre de fonction ?

[Icky Thump]

Dois-t-on en conclure que tu sécurise les buffer overflow par le rajout de mémoire ?

L'idée est là, je suppose qu'il voulait dire que l'ajout de sécurités rajoute de la consommation de ressources (que ça soit de la mémoire ou de la "vitesse d'exécution"), et que si c'est négligeable en informatique classique, en embarqué ça peut faire une différence.

[singman]

Une petite précision : le message de 73 octets que le hacker injecte ne permet d'executer que du code sur le second OS de la plateforme, et n'a pas d'incidence sur l'OS principal.