Les failles applicatives touchent, comme leur nom l'indique, les programmes et les applications. Ces failles sont souvent dues à des erreurs de programmation ou à un manque de connaissances de la part du programmeur.
Nous exposons ici quelques vulnérabilités applicatives ainsi que leur exploitation, et leur sécurisation.
Ecrit par Heurs le 06/08/2009 - Voir les commentaires (2)
Dans le domaine des buffer overflow, les kernel overflow sont parmis les plus dangereux mais aussi les plus difficiles à exploiter. Malheureusement ce sujet est rarement abordé, il en découle il vision extrèmement complexe pour quelque chose qui au final n'est pas sorcier !Ecrit par Heurs le 21/02/2008 - Poster un commentaire
La format string est une vulnérabilité un peu particulière, les principes des buffer overflow ne peuvent pas être réutilisés et le principe même de l'écrasement de l'adresse de retour est particulier. Pour toutes ces raisons la format string est une vulnérabilité particulièrement intéressante à étudier !Ecrit par Heurs le 14/09/2007 - Télécharger en PDF - Voir les commentaires (2)
Je profite d'avoir Visual C++ 2005 Express sous la main pour étudier plus en détail les attaques par débordement de tampon quand le flag GS est activé (ce qui est le cas par défaut sous cet IDE). Bon, il ne faut pas se voiler la face, le security check (flag GS) apporte une bonne sécurité au programme. Bien qu'en théorie les buffer overflow devaient finir par connaitre le meme sort que les dinosaures, ils sont toujours présents et nous allons voir comment ils ont survécu...
Ecrit par Heurs le 22/03/2007 - Télécharger en PDF - Voir les commentaires (3)
L'off by one est une faille applicative assez dur à classer. Certains la qualifient d'under-overflow ; personnellement je considère que c'est un "mini-overflow". En fait, c'est un débordement de tampon sur un seul octet. Cette contrainte fait que l'exploitation de cette vulnérabilité est plus compliquée qu'un simple buffer overflow. Cet article l'explique en détails.
Ecrit par Trance le 07/08/2006 - Voir les commentaires (8)
Cet article présente LA vulnérabilité applicative par excellence : les Buffer Overflows, "BOFS" pour les intimes, ou encore "Débordements de tampon". Cette faille est due à une erreur tellement triviale qu'on peut se demander pourquoi c'est encore la cause majeure des exploitations de type applicatif.
Vous découvrirez ici le principe de base, l'exploitation ainsi que la correction de ce type de faille. Il est nécessaire d'en savoir un peu sur la pile et d'avoir quelques notions asembleur.
Ecrit par Trance le 16/07/2006 - Voir les commentaires (3)
Une faille de sécurité est présente dans la fonction system() de Linux. En effet, cette fonction permet d'exécuter une commande passée en argument, mais utilise les variables d'environnement pour la localiser, dont PATH et IFS.
Cette particularité est alors une vulnérabilité dès lors que le programme appelant est Set-UID, et nous allons voir comment, de manière très simple, exploiter cette faille.
Ecrit par Heurs le 11/07/2006 - Poster un commentaire
Le Ret Onto Ret est une faille que l'on exploite de manière assez originale. Ayant apprécié son exploitation, qui donne des possibilités redoutables, j'ai décidé de vous en faire part. Bien que l'exemple que nous donnerons soit peu crédible en terme de réalisme, il reste possible de retrouver ce genre d'exploitation dans certaines routines. Elle n'est donc pas à négliger.
Ecrit par Heurs le 08/07/2006 - Voir les commentaires (5)
C'est une faille encore peu exploitée mais redoutable. En effet, elle permet à n'importe quel utilisateur, sous Unix, de s'élever les droits sur un fichier. Une sécurisation a été trouvée mais comme vous le verrez elle est insufisante. A l'heure actuelle aucune protection logicielle (à ma connaissance) n'est efficace contre ce genre d'attaque.
Ecrit par Heurs le 04/07/2006 - Voir les commentaires (2)
Les Return into libc font partie des techniques d'exploitation des buffer overflows, sous Linux.
Mais pourquoi utiliser le return into libc, étant donné que nous possédons les shellcodes ? La réponse est simple : l'évolution des sécurités. PaX a réussit à rendre la pile non executable :( Dommage... Une parade a été trouvé : les Return Into Libc.
