IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Les smartphones exécuteraient un second OS ayant de nombreuses failles
Un chercheur crée un code de 70 octets qui exploite celles-ci

Le , par Cedric Chevalier

27PARTAGES

3  0 
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 ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de transgohan
Expert éminent https://www.developpez.com
Le 18/11/2013 à 13:01
Citation Envoyé par phili_b Voir le message
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).

Citation Envoyé par ram-0000
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é...
3  0 
Avatar de ram-0000
Rédacteur https://www.developpez.com
Le 15/11/2013 à 15:34
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.
2  0 
Avatar de abriotde
Membre chevronné https://www.developpez.com
Le 19/11/2013 à 8:55
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.
1  0 
Avatar de Miistik
Membre émérite https://www.developpez.com
Le 19/11/2013 à 9:22
Citation Envoyé par ram-0000
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.
1  0 
Avatar de transgohan
Expert éminent https://www.developpez.com
Le 19/11/2013 à 9:57
Citation Envoyé par Miistik Voir le message
Citation Envoyé par ram-000
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 ?
1  0 
Avatar de Bestel74
Membre confirmé https://www.developpez.com
Le 19/11/2013 à 10:01
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 ?
1  0 
Avatar de singman
Membre averti https://www.developpez.com
Le 21/11/2013 à 9:48
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.
1  0 
Avatar de phili_b
Expert éminent https://www.developpez.com
Le 15/11/2013 à 15:57
Ben c'est une sorte de BIOS ou de Firmware ?! Rien de nouveau non ?
0  0 
Avatar de Icky Thump
Nouveau membre du Club https://www.developpez.com
Le 19/11/2013 à 11:22
Citation Envoyé par transgohan Voir le message
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.
0  0