En exécutant le binaire plusieurs fois, nous remarquons que le programme java n’a pas été compilé avec l’option PIE (Position Independent Code), donc le binaire est toujours chargé à la même adresse. Et cela bien qu’ASLR soit activé et que les adresses de toutes les librairies et de la pile soient aléatoires. Ce binaire à adresse fixe est une mine d’or (ou plutôt de gadgets) pour l’analyste. Voyons voir si ce binaire contient un jmp rbx (0xFF 0xE3 en hexadécimal). Pour ce faire, nous allons utiliser un des nombreux désassembleurs [4] pour obtenir une chaîne hexadécimale du binaire puis chercher ce qui nous intéresse.

Lire la suite …

Les deux vulnérabilités CVE-2010-0842 exploitées sous Windows en 32 bits restent-elles toujours exploitables en mode 64 bits avec ASLR ? En théorie, il est bien plus difficile, voire presque impossible de les exploiter de manière réaliste. En pratique, nous verrons que c’est toujours possible facilement.

Introduction

Un des objectifs du langage Java est d’éliminer les risques liés à la gestion de la mémoire manuelle (par exemple, débordement de tampon) comme dans un langage tel que le C. En théorie, un accès direct à la mémoire n’est pas possible et Java utilise un ramasse-miette pour récupérer de la mémoire allouée, mais plus utilisée. En pratique, Java repose sur de nombreuses librairies C/C++ dont le code, lui, peut accéder directement à la mémoire. De plus, ce code risque de contenir des vulnérabilités de type débordement de tampon ce qui contredit un des objectifs de sécurité du langage Java. Dans cet article, nous allons dans un premier temps brièvement présenter l’architecture de la sécurité Java. Ensuite, nous détaillerons les deux vulnérabilités du CVE-2010-0842, trouvées dans du code C/C++, qui permettent de contourner le système de sécurité de Java. Puis, nous expliquerons comment les exploiter en mode 64 bits avec ASLR activé.

Lire la suite …