Journal libc et sécurité...

Posté par forc3 le 17 décembre 2004 à 09:52.

Étiquettes : aucune

déc.

2004

Yop, amis coders !

Combien sommes nous à utiliser une autre bibliothèque C que celle
standard ? Suis-je le seul à me rendre compte que tous les bugs
sont dus exclusivement, à la mauvaise utilisation des fonctions de
la libc. (toute plateforme confondue)

Que dès qu'un programme se veut secure, la première chose qu'il
implémente soit une bibliothèque ? Pourquoi ne sont elle jamais
réutilisées ?

Ne jamais réinventer la roue c'est ce qui se dit, mais je vois
surtout que c'est quelque-chose de très fréquent dès qu'il s'agit
d'un programme ''secure''. Pour s'en convaincre il suffit de voir
le nombre d'implémentations différentes dans la gestion de buffers
disponibles dans le monde des LL.

Suis-je réellement le seul malade à ne plus utiliser stdio.h et
string.h ?

J'utilise actuellement et essentiellement
http://www.fefe.de/libowfat/.(...) Et vous qu'utilisez vous ? ( ca fait
slogan pourri, mais j'aime bien !)

# glib

Posté par Colin Leroy (site web personnel) le 17 décembre 2004 à 11:51. Évalué à 4.

ftp://ftp.gtk.org/pub/gtk/v2.4/glib-2.4.8.tar.bz2(...)
- [^] # Re: glib
  
  Posté par Nicolas Boulay (site web personnel) le 17 décembre 2004 à 13:11. Évalué à 2.
  
  la glib repose sur la libc non ?
  "La première sécurité est la liberté"
  - [^] # Re: glib
    
    Posté par M le 17 décembre 2004 à 13:24. Évalué à 3.
    
    oui, le but n'est pas de reinplementer toute les fonctions standards du C, mais de proposer des API de plus haut niveau...
  - [^] # Re: glib
    
    Posté par ckyl le 17 décembre 2004 à 13:29. Évalué à 2.
    Au risque de te decevoir un fichier pris au hasard de libowfat
```
#include <unistd.h>
#include <fcntl.h>
#include "io_internal.h"

int io_appendfile(int64* d,const char* s) {
  long fd=open(s,O_WRONLY|O_APPEND|O_CREAT,0600);
  if (fd != -1) {
    *d=fd;  
    return 1;
  }
  return 0;
}
```
    Le but n'est pas de ne pas utiliser la libc, ca serait un travail tres/trop important de la rendre portable, mais d'éviter que le programmeur n'utilise la libc qui à un API merdique et incohérente pour des raisons historiques. Autrement la glib c'est pas mal mais il manque le reseau par exemple.
    - [^] # Re: glib
      
      Posté par Guillaume Knispel le 17 décembre 2004 à 14:17. Évalué à 2.
      
      Ouai enfin open est surtout une primitive des systèmes unix.
      - [^] # Re: glib
        
        Posté par ckyl le 17 décembre 2004 à 14:44. Évalué à 3.
        
        Et pour l'appeler il utilise la libc plutôt que de mettre ses gentils arguments dans les registres et faire ses syscalls a la main. L'enrobage de syscall c'est long par ce que tout les noyaux ont leur subtilités et ne sont pas strictement POSIX.
        
        Pour les fonctions de plus haut niveau il est clair que dans la majorité des cas il va plus vite de les réécrire; la majorité c'est des exercices de première année de C.
        
        Si tu veux des trucs plus net, il utilise au moins : printf, malloc, realloc avec trois grep au hasard. Il ne fourni pas d'allocateur mémoire à ma connaissance. Il n'a donc pas vocation à ne pas utiliser la libc mais simplement rajouter une couche dessus.
        
        Bref la glib utilise la libc, libowfat utilise la libc c'etait juste ou je voulais en venir.
        
        [^] # Re: glib
        
        Posté par forc3 le 17 décembre 2004 à 16:21. Évalué à 1.
        
        La dessus je ne te contredis pas cyklo.
        Le propos de ce journal c'est plus sur l'idee que chaque gros
        développement a choisi de refaire des choses que l'on trouve
        dans la libC de base.
        
        Je veux juste mettre l'accent sur le fait qu'il n'y ai pas vraiment de raison
        pour lesquelles l'argument de réinventer la roue ne s'applique
        pas ici...
        
        _ Programme pourri, utilise libc et fonctions de string pourries
        _ Programme 'secure', recode un lib de base...
        
        Pourquoi ne pas avoir fait dans la libc un lib 'secure' ?
        Dans enormément de cas c'est l'API qu'il faut remettre en cause,
        pourquoi ne pas diriger les jeunes developpeurs vers des apis
        mieux faites ?
        
        (parce que si t'es jeune tu penses que le java c'est ultime ...)
        
        [^] # Re: glib
        
        Posté par ckyl le 17 décembre 2004 à 17:01. Évalué à 1.
        
        > Pourquoi ne pas avoir fait dans la libc un lib 'secure' ?
        
        Raisons historiques. J'etais pas la mais il me semble quand même qu'au moment de normaliser c'était déjà trop tard y'avait des implémentations pourries. Et le C c'est ultra conservateur à chaque fois qu'on risque de peter quelque chose on rajoute une tartine dans le norme pour rien casser. K&R & co n'avait pas prévu que leur langage sortirait de leur labo apparement :-)
        
        > Dans enormément de cas c'est l'API qu'il faut remettre en cause
        
        l'API de la libc est une sous merde. Je connais pas win32 mais je pense pas qu'il y ait plus utilisé et aussi mauvais que la libc; même dans les extensions sont attroces. Quand tu vois les socket par exemple...
        
        Comme ca evolue pas, on se retrouve avec des extensions partout; et les uns ne veulent surtout pas des extensions des autres, c'est beaucoup plus pratique comme ca !
        
        > pourquoi ne pas diriger les jeunes developpeurs vers des apis
        mieux faites ?
        
        Par ce que la plupart des profs de C sont completement a côté de la plaque et ne savent même pas utiliser strncpy(3) ou qu'il n'y a pas forcement de '\0'. Ca fait maintenant 3 ans que je fais du C en milieu scolaire j'ai jamais entendu prononcé une fois "buffer overflow" ou sécurité... Tu peux avoir 17 en programmant un shell qui repose sur des longjmp() dans un sighandler sans se proteger... La sécurité ca doit exister dans un monde parallèle mais pas ici.
        
        Il est clair qu'une bonne alternative à la libc serait interessante. Je n'ai jamais mis la main sur un lib suffisament complète et documentée pour le moment par contre. Le mot de la fin, le C c'est le conservatisme à l'état pur, pour le meilleur comme pour le pire !
    - [^] # Re: glib
      
      Posté par fredix le 18 décembre 2004 à 01:52. Évalué à 1.
      
      Autrement la glib c'est pas mal mais il manque le reseau par exemple.
      
      Tu peux utiliser le lib Gnet qui utilise la glib :
      http://www.gnetlibrary.org/(...)
      
      Maintenant si tu veux un truc tout intégré utilise python ou ruby ...
- [^] # Re: glib
  
  Posté par Franck le 17 décembre 2004 à 13:27. Évalué à 2.
  
  Idem.
  
  malloc => g_malloc
  free => g_free
  allocation + sprintf => g_strdup_printf
  malloc sur structure => g_new
  l'infâme strtok => g_strsplit
  
  Etc...
  - [^] # Re: glib
    
    Posté par Nicolas Boulay (site web personnel) le 17 décembre 2004 à 13:38. Évalué à -2.
    
    ouais mais la glib, c'est du GPL...
    "La première sécurité est la liberté"
    - [^] # Re: glib
      
      Posté par Matthieu Moy (site web personnel) le 17 décembre 2004 à 14:23. Évalué à 6.
      
      s/GPL/LGPL/
- [^] # Re: glib
  
  Posté par forc3 le 17 décembre 2004 à 14:40. Évalué à 2.
  
  Humm oui,
  le problème de cette lib, c'est qu'elle utilise trop d'assert,
  qu'elle est bloated, et que surtout elle ne segfault pas quand
  elle devrait...
  
  C'est pas un hasard si enormement d'appli GTK sorte des warning
  sur ton terminal... Trop d'appli ne sont pas corrigée parceque justement ce ne sont pas des erreurs bloquantes.
  
  Un strlen sur un string NULL _doit_ segfaulter...
  
  Trop de flexibilité rends les programmeurs trop lazy ...
  C'est mon point de vue. On peut ne pas etre d'accord. Mais mon
  experience me conforte dans cette idée.
  - [^] # Re: glib
    
    Posté par Franck le 17 décembre 2004 à 15:31. Évalué à 3.
    
    Un strlen sur un string NULL _doit_ segfaulter...
    
    De quelle fonction parles-tu ? Je ne vois nulle g_strlen ou approchant là-dessous :
    
    http://developer.gnome.org/doc/API/2.0/glib/glib-String-Utility-Fun(...)
    
    De plus Gnome lui-même utilise des strlen. Cherche sur koders.com par exemple.
    - [^] # Re: glib
      
      Posté par forc3 le 17 décembre 2004 à 16:11. Évalué à 1.
      
      Excuse moi, le strlen etait peut etre mal choisi,
      ce que je veux dire c'est que cette lib rends le developpement
      un peu trop permissif a mon gout, Et que des bugs ne sont
      jamais corriges car non bloquant.
      
      Maintenant Glib fournit des g_string, qui sont beaucoup mieux
      que de simple char *.
- [^] # Re: glib
  
  Posté par Pinaraf le 17 décembre 2004 à 17:10. Évalué à 3.
  
  ftp://ftp.gtk.org/pub/gtk/v2.6/glib-2.6.0.tar.gz(...) c'est mieux non ? :)
  Sorti aujourd'hui !
# Plus simple

Posté par Ramso le 17 décembre 2004 à 21:02. Évalué à 2.

Je ne programme plus en C !

Suivre le flux des commentaires

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