Donc pour les mal comprenants il y a un leak d'un compteur de référence qui pourrait amener le noyau à libérer de la mémoire utilisée. Cette mémoire pourrait donc être réutilisée par quelque chose d'autre et si on a bien calculé son coup on peut potentiellement faire exécuter du code arbitraire.
Le payload n'a pas besoin d'être dans le paquet UDP. Il peut très bien se retrouver dans la mémoire du noyal via l'utilisation d'un service existant sur le même système (dans un header HTTP par exemple au hasard).
Bon en pratique si quelqu'un arrive à écrire un exploit pour ça, je demande quand même à voir.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
On a une démo d'une console CQL ici si ça intéresse des gens (possible qu'on rajoute des données plus intéressantes dans les jours qui viennent) : http://cqldemo.acunu.com/
Oui, c'est comme du SQL avec des trucs en moins de ce que j'ai compris. ça simplifie beaucoup l'utilisation par rapport à l'API natif.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Une autre possibilité c'est d'attacher strace au process(es) seulement quand le problème a lieu. Obtenir un core au moment du problème est aussi une bonne idée (gdb et/ou gcore).
Sinon perso j'ai tendance à rajouter les options "-v -s1024 -tt -T" à strace.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Dans tous les cas, si ton programme génère des données de manière soutenue tel que le récepteur (ta carte SD) ne peut pas suivre, tu vas devoir soit bloquer soit perdre de l'information. Si la vitesse de génération des données est « raisonnable » pour le récepteur sur un temps donné, il suffit d'avoir un buffer en conséquence entre les deux (ce qui peut se faire dans le programme, dans la bibliothèque qui se charge des I/O, avec un programme intermédiaire ou au niveau du noyau).
Après en pratique C10K donne un bon résumé des options possibles sous Unix même si la problèmatique est un peu différente : http://www.kegel.com/c10k.html
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[leaf] permet de signifier qu'une fonction ne va fait appel à aucune autre fonction.
À une autre fonction dans la même unité de compilation. Elle peut toujours faire appel à une fonction dans une autre unité de compilation (tant qu'elle ne revient pas dans l'unité courante).
Comment on fait pour tenir compte de la durée de vie d'un développeur vs la durée de vie d'une barrette de RAM ? Une tonne de développeurs morts coûte sans doute plus cher à obtenir qu'une tonne de barrette morte.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Genre va expliquer a une personne qu'il faut couper l'eau du robinet pendant qu'on se lave les dents si de toute façon ça ne lui coûte rien...
Je n'ai pas de compteur et je paie un prix fixe quelle que soit ma consommation d'eau. Je ferme le robinet quand je me brosse les dents même si ça ne me coûte pas moins cher.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Les processus peuvent partager des pages entre eux donc c'est pas forcément très précis non plus. Dans ton exemple, une grosse partie de la mémoire consommée par Xorg provient sans doute en fait de seamonkey, mono et npviewer.
[^] # Re: Comment est-ce possible?
Posté par Krunch (site web personnel) . En réponse au journal [MS11-083] Vulnérabilité dans la pile TCP/IP de Windows permettant l'execution distante de code. Évalué à 7.
Donc pour les mal comprenants il y a un leak d'un compteur de référence qui pourrait amener le noyau à libérer de la mémoire utilisée. Cette mémoire pourrait donc être réutilisée par quelque chose d'autre et si on a bien calculé son coup on peut potentiellement faire exécuter du code arbitraire.
Le payload n'a pas besoin d'être dans le paquet UDP. Il peut très bien se retrouver dans la mémoire du noyal via l'utilisation d'un service existant sur le même système (dans un header HTTP par exemple au hasard).
Bon en pratique si quelqu'un arrive à écrire un exploit pour ça, je demande quand même à voir.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Vraie concurrence
Posté par Krunch (site web personnel) . En réponse au journal Hacker le développement des entreprises. Évalué à 4.
La vaste majorité des startups qui réussissent sont formées par des gens qui ont monté des startups qui se sont plantées.
http://www.paulgraham.com/articles.html
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# faut suivre les bonnes ml
Posté par Krunch (site web personnel) . En réponse au message Site de sécurité pour s'entraine. Évalué à 6.
Il y a eu un thread sur le sujet récemment sur une certaine liste dont les archives ne sont pas publiques.
http://www.overthewire.org/wargames/
OWASP webgoat
Foundstone hackmebank
OWASP hackademic challenges
http://smashthestack.org/
- Moth
- Metasploitable
- Kioptrix (3 different VMs/levels)
- DVWA
- DVL
http://www.webantix.net/war-games-current-and-past-hacking-simulators-and-challanges/
http://www.goriya.com/flash/tictactoe.shtml
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# CQL
Posté par Krunch (site web personnel) . En réponse à la dépêche 1.0 et 2.0 (Cassandra et Mercurial). Évalué à 4.
On a une démo d'une console CQL ici si ça intéresse des gens (possible qu'on rajoute des données plus intéressantes dans les jours qui viennent) : http://cqldemo.acunu.com/
Oui, c'est comme du SQL avec des trucs en moins de ce que j'ai compris. ça simplifie beaucoup l'utilisation par rapport à l'API natif.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: sous-domaines seulement ?
Posté par Krunch (site web personnel) . En réponse au journal Qui veut de l'hébergement libriste et abordable ?. Évalué à 4.
Pour information, au moins OVH (uniquement pour les clients belges ?) et le Chaos Computer Club procèdent comme ça et ça marche bien.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: tcpdump
Posté par Krunch (site web personnel) . En réponse au message Load balancing de deux ISP. Évalué à 2.
Ça ne nous dit toujours pas où les paquets se perdent.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# tcpdump
Posté par Krunch (site web personnel) . En réponse au message Load balancing de deux ISP. Évalué à 2.
Si on sait pas ce qui se passe on va avoir du mal de savoir comment corriger le problème.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: normal
Posté par Krunch (site web personnel) . En réponse au journal Microsoft et les virus, une longue histoire d'amour.. Évalué à 3.
Je te suggère la lecture quotidienne de http://blogs.msdn.com/b/oldnewthing/
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: strace
Posté par Krunch (site web personnel) . En réponse au message service httpd. Évalué à 2.
Le fichier va grossir très vite. L'astuce c'est d'utiliser rotatelog, possiblement avec ce patch : https://issues.apache.org/bugzilla/show_bug.cgi?id=47170
Une autre possibilité c'est d'attacher strace au process(es) seulement quand le problème a lieu. Obtenir un core au moment du problème est aussi une bonne idée (gdb et/ou gcore).
Sinon perso j'ai tendance à rajouter les options "-v -s1024 -tt -T" à strace.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Ca vous rapelle personne ?
Posté par Krunch (site web personnel) . En réponse au journal Journal bookmark The Stallman Dialogues. Évalué à 2.
C'est qui ? Il est dans quel changelog ?
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# wikipedia a pas l'air a jour
Posté par Krunch (site web personnel) . En réponse au journal Robert Lamoureux bronsonisé. Évalué à 3.
Pas un mot sur sa carrière artistique ni sa mort http://en.wikipedia.org/wiki/Robert_Love
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: /etc/mtab
Posté par Krunch (site web personnel) . En réponse au message Mount et fstab. Évalué à 3.
Typiquement c'est l'initrd qui a merdé un truc lors du changement de racine.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Des exemples ?
Posté par Krunch (site web personnel) . En réponse au journal Journal bookmark The Stallman Dialogues. Évalué à 0.
http://www.snopes.com/music/artists/vanhalen.asp
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# buffers et théorie des files d'attente
Posté par Krunch (site web personnel) . En réponse au message Ecritures disques non bloquants. Évalué à 2.
Dans tous les cas, si ton programme génère des données de manière soutenue tel que le récepteur (ta carte SD) ne peut pas suivre, tu vas devoir soit bloquer soit perdre de l'information. Si la vitesse de génération des données est « raisonnable » pour le récepteur sur un temps donné, il suffit d'avoir un buffer en conséquence entre les deux (ce qui peut se faire dans le programme, dans la bibliothèque qui se charge des I/O, avec un programme intermédiaire ou au niveau du noyau).
Après en pratique C10K donne un bon résumé des options possibles sous Unix même si la problèmatique est un peu différente : http://www.kegel.com/c10k.html
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Un peu d'explications sur le bug introduit
Posté par Krunch (site web personnel) . En réponse au journal Merci aux développeurs de la GNU libc !. Évalué à 5.
Le reproche principal c'est qu'il y a un changement qui a été fait en plein freeze sans raison valable apparente.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Un peu d'explications sur le bug introduit
Posté par Krunch (site web personnel) . En réponse au journal Merci aux développeurs de la GNU libc !. Évalué à 3.
Sauf que ça a été appliqué à *printf() aussi si j'ai bien suivi.
http://www.gnu.org/s/hello/manual/libc/Customizing-Printf.html
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Un peu d'explications sur le bug introduit
Posté par Krunch (site web personnel) . En réponse au journal Merci aux développeurs de la GNU libc !. Évalué à 2.
À une autre fonction dans la même unité de compilation. Elle peut toujours faire appel à une fonction dans une autre unité de compilation (tant qu'elle ne revient pas dans l'unité courante).
Voir aussi http://www.hpl.hp.com/techreports/2004/HPL-2004-209.html
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Implémentation de référence
Posté par Krunch (site web personnel) . En réponse au journal Le java officiel est sorti de debian…. Évalué à 5.
C'est pas comme s'il y avait beaucoup de logiciels qui fonctionnaient 100% conformément à leurs spécifications non plus.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Java = Flash ?
Posté par Krunch (site web personnel) . En réponse au journal Le java officiel est sorti de debian…. Évalué à 4.
Comment on fait pour tenir compte de la durée de vie d'un développeur vs la durée de vie d'une barrette de RAM ? Une tonne de développeurs morts coûte sans doute plus cher à obtenir qu'une tonne de barrette morte.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Eau
Posté par Krunch (site web personnel) . En réponse au journal Quelques mesures sociales.... Évalué à 6.
Je n'ai pas de compteur et je paie un prix fixe quelle que soit ma consommation d'eau. Je ferme le robinet quand je me brosse les dents même si ça ne me coûte pas moins cher.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# ssh+otp+vim
Posté par Krunch (site web personnel) . En réponse au message éditeur de code source en ligne. Évalué à 2.
Fonctionne même en 56k.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Meilleure estimation de la mémoire utilisée
Posté par Krunch (site web personnel) . En réponse au message Mémoire consommée mais par quoi/qui ??? Incompréhensible. Évalué à 3.
Les processus peuvent partager des pages entre eux donc c'est pas forcément très précis non plus. Dans ton exemple, une grosse partie de la mémoire consommée par Xorg provient sans doute en fait de seamonkey, mono et npviewer.
Sinon il y a Matt Mackall qui a fait une bonne talk sur le sujet à ELC2009 : http://free-electrons.com/blog/elc-2009-videos/
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# mieux
Posté par Krunch (site web personnel) . En réponse au journal Commit Logs From Last Night . Évalué à 5.
http://whatthecommit.com/
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: facile
Posté par Krunch (site web personnel) . En réponse au message Exercice à résoudre !!!. Évalué à 2.
init=/usr/bin/systemd
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# Linux ate my RAM
Posté par Krunch (site web personnel) . En réponse au message Mémoire consommée mais par quoi/qui ??? Incompréhensible. Évalué à 10.
http://www.linuxatemyram.com/
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.