Java a-t-il des débordements de tampon? Si oui, pouvez-vous me donner des scénarios?
Réponses:
Étant donné que les chaînes Java sont basées sur des tableaux de caractères et que Java vérifie automatiquement les limites des tableaux, les dépassements de mémoire tampon ne sont possibles que dans des scénarios inhabituels:
Les langages gérés tels que Java et C # ne présentent pas ces problèmes, mais les machines virtuelles spécifiques (JVM / CLR / etc) qui exécutent réellement le code peuvent.
À toutes fins utiles, non.
Java a une vérification des limites du tableau qui vérifiera que les données ne sont pas accessibles à partir de la zone en dehors du tableau alloué. Quand on essaie d'accéder à une zone qui dépasse la taille du tableau, unArrayOutOfBounds exception sera levée.
S'il y a un dépassement de la mémoire tampon, c'est probablement à cause d'un bogue dans la machine virtuelle Java, et ce n'est, à ma connaissance, pas le comportement prévu qui est écrit dans les spécifications du langage Java ni dans les spécifications de la machine virtuelle Java.
Oui et non. Non, dans la mesure où vous ne pouvez pas vraiment créer par erreur, vous ouvrir à une vulnérabilité de dépassement de tampon car il s'agit d'un modèle de mémoire gérée. Cependant, il peut y avoir des vulnérabilités de débordement de tampon dans la JVM et le JDK. Voir cet avis Secunia:
http://secunia.com/advisories/25295
Ou consultez ces anciens avis sur plusieurs vulnérabilités JDK et JRE précédentes:
Les vulnérabilités de débordement d'entier et de mémoire tampon dans l'utilitaire de décompression JAR "unpack200" de l'environnement d'exécution Java (JRE) peuvent entraîner une augmentation des privilèges https://download.oracle.com/sunalerts/1020225.1.html
Les vulnérabilités d'entier et de dépassement de mémoire tampon dans l'environnement d'exécution Java (JRE) avec des applets de décompression et des applications Java Web Start à l'aide de l'utilitaire de décompression JAR "unpack200" peuvent permettre à une applet ou une application non approuvée d'élever des privilèges. Par exemple, une applet non approuvée peut s'octroyer des autorisations pour lire et écrire des fichiers locaux ou exécuter des applications locales accessibles à l'utilisateur exécutant l'applet non approuvée.
Sun remercie «regenrecht» de travailler avec iDefense VCP ( http://labs.idefense.com/vcp/ ) et Chris Evans de Google pour avoir porté ces problèmes à notre attention.
Plusieurs vulnérabilités ont été identifiées dans Sun Java Development Kit (JDK) et Java Runtime Environment (JRE). https://security.gentoo.org/glsa/200705-23
Une vulnérabilité non spécifiée impliquant une "utilisation incorrecte des classes système" a été signalée par l'équipe de sécurité de Fujitsu. De plus, Chris Evans de l'équipe de sécurité Google a signalé un débordement d'entier entraînant un dépassement de la mémoire tampon dans l'analyseur ICC utilisé avec les fichiers JPG ou BMP, et un appel open () incorrect à / dev / tty lors du traitement de certains fichiers BMP.
Un débordement de tampon au sens strict de l'écrasement de la pile ou du tas lui-même nécessiterait soit:
Un débordement de tampon dans le sens où vous avez du code utilisant un tampon et votre code est responsable de son analyse correcte, mais ne pas le faire est possible. Par exemple, vous pourriez écrire un analyseur XML et quelqu'un pourrait vous fournir une requête mal formée (ou légitime mais rare) qui, en raison de la conception de votre analyseur, écrase les données précédemment validées avec une charge utile qui entraînerait un mauvais comportement de votre application.
Cette dernière forme est moins probable, mais une fonction de nettoyage de chaîne SQL mal écrite largement distribuée qui avait un problème comme celui-ci serait une cible invitante.
Les machines virtuelles Java (et .Net) interceptent le code qui tente d'écrire en dehors de la mémoire réservée. Les applications qui ne gèrent pas cela correctement peuvent toujours causer des problèmes de sécurité. Si des utilisateurs malveillants peuvent déclencher des exceptions en entrant une entrée non valide, ils peuvent par exemple effectuer des attaques par déni de service.
Comme cela a déjà été souligné, Java a, en tant que langage, la vérification des limites de tous les accès mémoire, et s'il y a une erreur ici, c'est la JVM qui est en faute et non le programme. Cependant, ce qu'il faut noter, qui est un argument similaire aux fuites de mémoire en Java; bien qu'il ne soit pas possible de briser la pile, une ArrayOutOfBoundsException au mauvais endroit, qui n'est pas gérée correctement, peut encore finir par bousiller votre système.
Vous pourriez éventuellement provoquer un débordement de tampon dans un programme Java si vous utilisiez la fonction Java Native Interace (JNI) pour appeler du code externe et que le code externe présentait un problème exploitable. Ceci est assez rare, car la plupart des applications évitent d'utiliser JNI lorsque cela est possible.
Il est possible pour une méthode d'écrire dans des entrées valides d'un tableau qu'elle n'avait pas l'intention d'écrire, généralement par débordement d'entier.
Par exemple, ce qui suit n'est pas suffisant pour vérifier les limites:
/* !! WRONG !! */ 0 <= off && 0 <= len && off+len <= buff.length /* !! WRONG !! */L'IIRC a StringBufferdéjà eu un bogue comme celui-là, mais il n'y avait rien d'intéressant que vous puissiez en faire.
0 <= off && 0 <= len && off <= buff.length-lenJe pense. Ne me citez pas. Cela a la même apparence mais il n'y a pas de débordement possible (dans l'original off + len pourrait devenir négatif et donc évidemment plus petit que la longueur du tableau). Assurez-vous qu'aucun programmeur de maintenance ne le «range» sous la forme évidente. Je trouve le débordement d'entier extrêmement déroutant. Je dois y réfléchir pendant un moment, puis il y a le soupçon tenace que je me trompe. Mais bien sûr, il devrait y avoir un autre réviseur et le programmeur d'origine - ensemble, il n'y a bien sûr aucun moyen qu'une erreur puisse passer! (not)
L'une des principales fonctionnalités de JAVA est la sécurité. Les programmes écrits dans des langages interprétés ne sont pas sujets à l'exploit de buffer overflow, mais vous pouvez toujours provoquer un buffer overflow dans Interpreter lui-même. Bien que ce soit difficile. De même, Python est également un langage interprété et est à l'abri du dépassement de tampon.