Forum Linux.noyau Intercepter les syscall

• # re

  Posté par LaBienPensanceMaTuer le 22 juillet 2005 à 15:36. Évalué à 3.

  

  Le mieux que tu ai à faire dans ce cas, c'est de t'inspire des virtuoses de l'interception de syscall j'ai nommé les auteurs du fameux rootkit Adore !
  
  Voir:
  http://linuxfr.org/~hideo/4281.html(...)
  
  Bon courage !

  • [^] # Re: re

    Posté par jcs (site web personnel) le 22 juillet 2005 à 17:41. Évalué à 3.

    

    le lien n'étant pas (plus) disponible tu peux aussi le récupérer ici : http://packetstorm.linuxsecurity.com/groups/teso/(...)

  • [^] # Re: re

    Posté par beagf (site web personnel) le 22 juillet 2005 à 18:09. Évalué à 1.

    

    Helas adore n'intercepte pas les syscall.
    
    Je viens d'y jeter un coup d'oeuil et en fait il ne s'attaque pas directement au syscall, mais il remplace les fonction du vfs par les siennes, ce qui ne resoud pas mon probleme.

    • [^] # Re: re

      Posté par M le 22 juillet 2005 à 20:11. Évalué à 2.

      

      regarde http://www.shirka.org/recycled4linux/,(...) je crois qu'il y avait un script perl qui permettait de les extraire a la compilation.

      • [^] # Re: re

        Posté par beagf (site web personnel) le 22 juillet 2005 à 21:25. Évalué à 1.

        

        Je dois avouer que je ne comprend pas bien ce que tu veux dire par "extraire a la compilation". Les programmes que je dois logger sont deja compilés, de plus je log les syscall qui modifient le fs, donc des syscall ou les parametres sont, la majoritée du temps, dynamique. je ne peux donc pas avoir les infos qui m'interresse au moment de la compilation.
        
        Je suis quand meme aller voir sur le site de recycled4linux, pour voir comment il surveille le fs, il utilise aussi un module, mais le projet ne semble plus maintenu depuis 1 an, et pour le noyal 2.6, il faut appliquer un patch qui exporte la table des syscall et donc recompiler le noyal...

• # ptrace ?

  Posté par Vincent Palatin le 22 juillet 2005 à 21:32. Évalué à 1.

  

  Tu dois pouvoir utiliser l'appel système ptrace.
  (voire la fonction de libc ptrace qui est basée sur le syscall mais plus limitée)
  
  ptrace permet entre autres d'intercepter tous les appels systèmes d'un processus dont on fournit le pid (en utilisant PTRACE_SYSCALL comme requete)
  
  ça remplit le cahier des charges non ?
  
  La page de man pour la fonction de la libc : http://www.linux-france.org/article/man-fr/man2/ptrace-2.html(...)
  Quelques infos sur l'utilisation de ptrace :
  http://www.linuxjournal.com/article/6100(...)
  
  --
  Vincent

  • [^] # Re: ptrace ?

    Posté par beagf (site web personnel) le 22 juillet 2005 à 21:42. Évalué à 1.

    

    C'est la solution que j'utilisait avant, le probleme c'est que ce n'est pas franchement propre et portable, pour recuperer les parametres des syscall, il faut aller lire les registre, ce qui veux dire que pour chaque archi il faut ecrire ce code et le tester, hors je n'ai pas access comme je veux a toutes les machines.
    C'est pour ca que j'etait ensuite partit sur un strace, d'autres on deja fait le bouleau alors pourquoi ne pas en profiter... le probleme c'est que c'est super lourd, par rapport au module noyau avec un kernel 2.4, et j'ai plus vraiment envi d'y revenir...
    Mais bon je sens qu'il va faloir que je m'y fasse (quoique je suis en train de me plonger dans les sources du noyal, et ya peut-etre moyen d'intercepter les appels aux fs, plustot que les syscall, si quelqu'un connait un peu le truc ?)

• # Vilain hack ...

  Posté par LaBienPensanceMaTuer le 23 juillet 2005 à 13:39. Évalué à 2.

  

  Dont j'avais eu l'occasion de me pencher sur le code de Sebek[1].
  Sebek fait partie du projet Honeynet et permet de logguer justement tout ce qu'il se passe sur le système.
  Hélas, ce projet est propre à la branche 2.4 de Linux.
  Par contre, dans leurs code, ils n'attaquaient pas directement la table des syscall via la variable exportée sys_call_table[] mais ils allaient la chercher directement en mémoire.
  Voici la fonction chargée de cette tache:
  
  unsigned long ** get_syscall_table(){
  //----- data structure that holds system call table
  unsigned long **sct;
  
  unsigned long ptr;
  extern int loops_per_jiffy;
  
  //----- find the system call table
  sct = NULL;
  
  for (ptr = (unsigned long)&loops_per_jiffy;
  ptr < (unsigned long)&boot_cpu_data; ptr += sizeof(void *)){
  
  unsigned long *p;
  p = (unsigned long *)ptr;
  //---- orig ver that looked for sys_exit didnt work on stock
  //---- kerns.
  if (p[__NR_close] == (unsigned long) sys_close){
  sct = (unsigned long **)p;
  break;
  }
  }
  
  return sct;
  }
  
  Quand on y réfléchit bien, ce n'est pas bête du tout. En effet, bien que plus exportée, la fameuse sys_call_table[] existe toujours. Et si elle existe toujours, alors elle est calée quelque part en mémoire.
  Attention toutefois, j'ai testé le code de sebek sur un 2.4.30 et celui ci n'ai jamais parvenu à trouver ma table des syscall.
  Pour finir, après avoir modifier le code pour qu'il fonctionne malgré cela, le module à fait paniquer le kernel au bout de 3 ls, donc je pense que ce module n'est pas exploitable en production.
  Sinon, si je me souviens bien, ton but était de logguer les accés aux fichiers ?! Une solution se basant sur le VFS ne pourrait elle pas fonctionner ?
  
  [1] : http://www.honeynet.org/tools/sebek/(...)

  • [^] # Re: Vilain hack ...

    Posté par beagf (site web personnel) le 27 juillet 2005 à 11:56. Évalué à 2.

    

    Pour le hack, j'ai essayer et en effet suivant les noyau des fois il trouve, des fois il ne trouve pas... et quand il trouve ce n'est pas tres stable...
    
    Pour le VFS c'est la piste que je suis en train d'explorer, je vous tiens au courrant.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.