http://www.futura-sciences.com/new [...] s_9340.php
 
MA GNI FIQUE
 
Edit : http://www.futura-sciences.com/new [...] r_8086.php
 

ni debian ni suse ni kde pour ma part

les articles cités sont tellement précis que les copier ici est par contre risible.
(c'est surement d'ailleurs l'origine du enfin j'espère .. )

de la merde en barre c'est 2 articles...

en plus c'est pas une faille puisque l'exploitation de la faille ne fonctionne meme pas sur suse elle est juste presente. ...en plus il faut etre local bonjour la faille......  
 
autant  dire que voler une voiture quand on a deja les clef est possible...
 
 
c'est du meme niveau

Tant mieux. Sans critiques du genre, le kernel paraitrait trop-beau-pour-etre-vrai

 
comme ton orthographe/grammaire ? Elle est open-source peut-être (ceci expliquerait la qualité) ;o)))

Je vois qu'on a a faire a un intellectuel une fois de plus )
 
Retourne jouer avec ton pack windows xp, ici on est pas dans ton monde.
 
PS : Debian n'est pas foutu d'avoir des kernels up-to-date dans leur infra, on le sait, ca finirait forcément par arriver
 
PS2 : Y'a encore de woody qui trainent...

si vous voulez on peut vous prêter un serveur windows 2003 avec IIS6, ca sera plus sécurisé que votre OS bourré de failles la ;o))))

Kick-Ban-Sodo-Gravier

bah voyons un serveur debian qui serais sur un 2.6.x
retourne donc sur prog

j'ai demandé à ce qu'ils viennent récupérer leur boulet, on a déjà les notres

il a le droit de lire hein (bon pas de poster depuis peu )

merci mikala

 
non merci, on vous le laisse

 
oué enfin on peut être aussi ici et là-bas. Envoyez le plutôt sur WS&R Il y sera plus à sa place.    

plutôt sur discu dans la cat foot

ou alors sur seti

 

 
Non c'est bon ... on les a totalement éradiqués, à part un ou deux spams de temps en temps on est complétement clean maintenant !!!
On est tellement civilisés qu'on est la seule cat en quasi-autogestion d'HFR
 
C'est pas pour tout repourrir en nous balançant vos vieilleries !

> pinguin007 : juste pour mieux comprendre, qu'y aurait-il de surprenant à ce qu'un serveur Debian tourne sur un kernel 2.6.x ?

 
Si tu commence à négliger les failles locales c'est par la que passera le mec qui aura eu un compte en exploitant un service pas à jour un de ces 4...
C'est pas vraiment comme avoir les clefs d'une voiture mais plutôt trouver les clefs sous le pare soleil on va dire

non l'acces physique a la machine est necessaire c'est pas attaquable de l'exterieur c'est ca le probleme. avoir acces physique a la machine c'est pas une faille c'est un jacking comme le carjaking  
 
c'est comme les password il suffit a quelqu'un de te voir le taper assez lentement pourqu'il puisse le memoiriser et utiliser ta machine pendant que tu es parti pisser ....
 
la c'est pareil.... aucune possibilite d'utiliser la faille ailleur que sur la machine elle meme pas utilisable depuis ni un programme ni un reseau.
 
en plus depuis le temps que la nezs est sortie elle est deja en cours de correction si ce n'est pas deja corrige d'ailleur...
j'ai pas verifie

Si un service est corrompu depuis Internet (Apache...) le pirate pourra à l'aide de cette faille devenir root sur la machine.
Donc il n'est pas nécessaire d'être physiquement sur la machine.

Dans cette histoire de compromission, le fautif serait plutôt le développeur qui s'est fait détourner son compte utilisateur sur le serveur. S'il n'avait pas utilisé un mot de passe en bois, l'attaquant n'aurait certainement pas pu obtenir un accès local et par conséquent n'aurait pas pu exploiter cette fameuse faille concernant les noyau 2.6.13 à 2.6.16.
 
 

N'empêche qu'un serveur sous une bonne vieille Debian Sarge avec le 2.6.8 par défaut n'aurait pas été affecté par ce problème là (oui bien sûr il y en a d'autres)  

 
Clairement c'est le gros risque, surtout avec les CMS et autres softs de forums de type passoire ( style phpBB )
 
Aujourd'hui sur un serveur web mal sécurisé c'est assez facile d'avoir un accès user s'il y a pas mal de choses qui tournent dessus, donc c'est très problématique. J'ai déjà vu un hébergeur à l'époque de ptrace dans le 2.4.18 ( même principe ) se faire retourner une baie entière de serveur par ce qu'il avait pu accéder à un l'un d'entre eux via une faille PHP.

Chroot ?

en théorie oui mais là concrétement pour cette faille précise seule l'adresse localhost 127.0.0.1 permet de la declancher donc tu tombes hors sujet, hors du cas de cettefaille là en tout cas.
 
car lors d'acces depuis le réseau local ou externe cette faille là ne fonctionne pas.
 

 
Ben clair ouai... +1

 
Je voudrais bien que tu m'expliques la chose techniquement, parce que là je vois vraiment pas le rapport entre la faille et une adresse IP
 
D'autre part, pour ton information ce qui fonctionne :
 
- un binaire "prtcl" compilé uploadé sur la machine
- un PHP qui contient juste : <?system('prctl 1> /tmp/log 2> /tmp/err')?>;
 
j'appelle la page par le net, ça mouline et.... oh....  
 
$ cat /tmp/log
Linux Kernel 2.6.x PRCTL Core Dump Handling - Local r00t
By: dreyer & RoMaNSoFt
[ 10.Jul.2006 ]
 

• Creating Cron entry
• Sleeping for aprox. one minute (** please wait **)
• Running shell (remember to remove /tmp/sh when finished) ...

$ cat /tmp/err
sh: no job control in this shell
sh-2.05b# exit
$ ls -alh /tmp/sh
-rwsr-xr-x  1 root root 611K 2006-08-02 10:28 /tmp/sh
 
 
Tiens c'est marrant, y'a un sh setuid root qui traine maintenant sur la machine...
 
P.S. : C'est une machine de test hein

 
chroot c'est le bien ouais, par contre quand y'a du monde qui utilise le même service sur le même serveur le problème reste le même localement entre ces personnes dans le même chroot.
 
Dans tous les cas y'a des moyens de toute manière de gérer correctement la sécurité sur un web, mais tout le monde ne les utilise pas ( pour des raisons diverses )

 
Brièvement les points essentiels ?

 
Je sais pas comment ça marche vu que le detaill de la faille n'est pas publié mais dans l'explication il était ecrit que seule le localhost (ou par son ip 127.0.0.1) ça ouvrait. c'est tout....
 

Bien souvent, le "retournement" d'un hôte (serveur, un équipement réseau ou autre équipement à "fonctionnalités limitées/bien définies", c'est déjà bcp moins évident à réaliser), ne résulte pas d'une attaque directe, mais combine plusieurs attaques/exploitations de failles enchainées.
 
Schématiquement, on a affaire à un scénario qui est fréquemment le suivant :
1/ Prendre pied, "en local", via un user aux droits très limités
:
:
n/ Monter en privilèges de façon suffisante (root ?), via des failles typées "privilege ecalation", mêmes locales ...
 
Avec autant d'étapes, que nécessaire.

 
Non t'as rien compris au therme local exploit, ça veut pas dire que t'as besoin d'etre present physiquement devant la machine mais que tu as besoin d'un compte sur la machine pour l'exacuter.
 
Dans ce cas l'exploit se passe en 2 temps : exemple -> 1)  exploit de apache, tu te retrouve loggé avec les droits de www-data.
2) Tu lance cet exploit sous le compte www-data et tu obtiens un shell root.

 

ce n'est pas une question de  
TERME !!!! sortez vous les doigts du cul et lisez les articles entiers ! et surtout sur plusieurs sources differentes et on tombe sur ça notement :
 
 
mais bien d'explication je cite

 
même si l'escalade de privilège est une cause de faille elle n'est pas utilisable depuis par exemple une session rsh ou un plugin lancé sur le serveur apache hormis lancement local par un utilisateur logué physiquement sur la machine (donc par aucun protocole LAN comm ssh ou autre)  
 

 
Parceque localhost pour toi ça veut dire etre present physiquement devant la machine ?
 
Essai de prendre une machine a distance et fait un ping 127.0.0.1 dessus tu verra si ça marche pas

 
 
Mais je sais ça mais c'est pas du tout la question !
 
ICI dans le cas qui nous interesse :
 
 
Il est écrit que la faille ne passe pas à travers les résaux et qu'elle ne marche qu'en local !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
 
 
si tu te logues à distance la faille ne marche pas !!!!!!
 
J'y peux rien moi c'est les expert qui on decrit la faille qui le disent c'est pas moi
 
 
   

Une local exploit ça veut pas du tout dire que la faille ne passe pas par le reseau, ça veut simplement dire qu'il faut etre loggé sur la machine pour pouvoir l'executer, que ça soit à distance ou sur une chaise devant la console ça ne change absolument rien. En gros dans ce genre d'exploit les mecs arrivent à avoir un shell sous un compte limité puis font un wget sur l'exploit et la lance pour obtenir le shell root.

 
1) Arrête de prendre au mot et de croire un article unique parce qu'il écrit "localhost" ( qui d'ailleurs devrait plutôt être "local" )
2) Comment tu expliques que ça passe quand je teste sur des serveurs qui sont à 500 km de ma console ?
3) Renseigne toi vraiment sur la faille elle même avant de soutenir mordicus n'importe quoi.
 
Merci.
 
P.S. : dans l'article collé ici je n'ai pas vu le mot "localhost" ceci dit, juste "local" qui signifie avoir un user local à la machine pour obtenir les privilèges.