Bonsoir à tous, après avoir écumé plusieurs documentations, ainsi que
plusieurs questions auprès de gens travaillant sur le kernel, un problème
reste sans réponse.
L'opération, qui a lieu au cours d'un pen test est la suivante :
1) Le système est installé neuf et à jour quelques heures avant
2) Un accès de type shell utilisateur standard a pu être obtenu
3) Après un nombre important de tests et d'opérations sur le systême, et
bien qu'ayant tjs les memes uid/gid/euid, je me retrouve dans la
possibilité d'utiliser la commande chown, et uniquement celle ci n'importe
où sur le système et dans les 2 sens.
4) je peux donc faire un chown toto.users de n'importe quel fichier afin de
le modifier (exemple : /etc/shadow) et refaire derrière un chown root.root
du fichier.
5) Après déconnexion du système puis reconnexion avec le même utilisateur,
cette opération est toujours possible.
6) Ce cas a pu n'être produit que 2 fois par votre serviteur, une fois sur
une Debian équipée d'un kernel 2.4.18, et une fois sur la dernière redhat.
7) Toutes les discussions que j'ai peu avoir avec des gens travaillant
autour de la sécurité du noyau, m'affirment, que, outre le fait que ce
comportement soit "quasi" impossible, cela ne devrait pas perdurer après
déconnexion/reconnexion de l'utilisateur
Ma question est simple : comment est ce possible, et de quel coté chercher ?
Pour information, de nombreux tests avaient été effectués sur la machine
avant de se retrouver dans cet état, notamment des outils de recherche de
type buffer overflow comme bfbtester ou divers exploits kernel (ptrace par
exemple) avec diverses modifications avaient été effectués avant. Je ne
sais pas à partir de quel moment est intervenu ce bug, puisque je m'en suis
rendu compte par hasard.
Le 20-09-2005, à propos de information securite kernel 2.4.x, Christophe Casalegno écrivait dans fr.comp.securite :
Bonjour,
Bonsoir à tous, après avoir écumé plusieurs documentations, ainsi que plusieurs questions auprès de gens travaillant sur le kernel, un problème reste sans réponse.
L'opération, qui a lieu au cours d'un pen test est la suivante :
1) Le système est installé neuf et à jour quelques heures avant 2) Un accès de type shell utilisateur standard a pu être obtenu 3) Après un nombre important de tests et d'opérations sur le systême, et bien qu'ayant tjs les memes uid/gid/euid, je me retrouve dans la possibilité d'utiliser la commande chown, et uniquement celle ci n'importe où sur le système et dans les 2 sens. 4) je peux donc faire un chown toto.users de n'importe quel fichier afin de le modifier (exemple : /etc/shadow) et refaire derrière un chown root.root du fichier. 5) Après déconnexion du système puis reconnexion avec le même utilisateur, cette opération est toujours possible. 6) Ce cas a pu n'être produit que 2 fois par votre serviteur, une fois sur une Debian équipée d'un kernel 2.4.18, et une fois sur la dernière redhat. 7) Toutes les discussions que j'ai peu avoir avec des gens travaillant autour de la sécurité du noyau, m'affirment, que, outre le fait que ce comportement soit "quasi" impossible, cela ne devrait pas perdurer après déconnexion/reconnexion de l'utilisateur
Ma question est simple : comment est ce possible, et de quel coté chercher ?
Pour information, de nombreux tests avaient été effectués sur la machine avant de se retrouver dans cet état, notamment des outils de recherche de type buffer overflow comme bfbtester ou divers exploits kernel (ptrace par exemple) avec diverses modifications avaient été effectués avant. Je ne sais pas à partir de quel moment est intervenu ce bug, puisque je m'en suis rendu compte par hasard.
Si quelqu'un à une piste, elle est la bienvenue.
S'il s'agit de la même machine, voir du côté du disque dur, de la mémoire ou du cache processeur. J'ai déjà pu observer de telles joyeusetés (moi, c'était plutôt, root n'a plus le droit de modifier ses propres fichiers). Que disent dmesg et /var/log/auth.log (sur la debian) ?
Cordialement,
JKB
Le 20-09-2005, à propos de
information securite kernel 2.4.x,
Christophe Casalegno écrivait dans fr.comp.securite :
Bonjour,
Bonsoir à tous, après avoir écumé plusieurs documentations, ainsi que
plusieurs questions auprès de gens travaillant sur le kernel, un problème
reste sans réponse.
L'opération, qui a lieu au cours d'un pen test est la suivante :
1) Le système est installé neuf et à jour quelques heures avant
2) Un accès de type shell utilisateur standard a pu être obtenu
3) Après un nombre important de tests et d'opérations sur le systême, et
bien qu'ayant tjs les memes uid/gid/euid, je me retrouve dans la
possibilité d'utiliser la commande chown, et uniquement celle ci n'importe
où sur le système et dans les 2 sens.
4) je peux donc faire un chown toto.users de n'importe quel fichier afin de
le modifier (exemple : /etc/shadow) et refaire derrière un chown root.root
du fichier.
5) Après déconnexion du système puis reconnexion avec le même utilisateur,
cette opération est toujours possible.
6) Ce cas a pu n'être produit que 2 fois par votre serviteur, une fois sur
une Debian équipée d'un kernel 2.4.18, et une fois sur la dernière redhat.
7) Toutes les discussions que j'ai peu avoir avec des gens travaillant
autour de la sécurité du noyau, m'affirment, que, outre le fait que ce
comportement soit "quasi" impossible, cela ne devrait pas perdurer après
déconnexion/reconnexion de l'utilisateur
Ma question est simple : comment est ce possible, et de quel coté chercher ?
Pour information, de nombreux tests avaient été effectués sur la machine
avant de se retrouver dans cet état, notamment des outils de recherche de
type buffer overflow comme bfbtester ou divers exploits kernel (ptrace par
exemple) avec diverses modifications avaient été effectués avant. Je ne
sais pas à partir de quel moment est intervenu ce bug, puisque je m'en suis
rendu compte par hasard.
Si quelqu'un à une piste, elle est la bienvenue.
S'il s'agit de la même machine, voir du côté du disque dur, de la mémoire ou
du cache processeur. J'ai déjà pu observer de telles joyeusetés (moi,
c'était plutôt, root n'a plus le droit de modifier ses propres fichiers).
Que disent dmesg et /var/log/auth.log (sur la debian) ?
Le 20-09-2005, à propos de information securite kernel 2.4.x, Christophe Casalegno écrivait dans fr.comp.securite :
Bonjour,
Bonsoir à tous, après avoir écumé plusieurs documentations, ainsi que plusieurs questions auprès de gens travaillant sur le kernel, un problème reste sans réponse.
L'opération, qui a lieu au cours d'un pen test est la suivante :
1) Le système est installé neuf et à jour quelques heures avant 2) Un accès de type shell utilisateur standard a pu être obtenu 3) Après un nombre important de tests et d'opérations sur le systême, et bien qu'ayant tjs les memes uid/gid/euid, je me retrouve dans la possibilité d'utiliser la commande chown, et uniquement celle ci n'importe où sur le système et dans les 2 sens. 4) je peux donc faire un chown toto.users de n'importe quel fichier afin de le modifier (exemple : /etc/shadow) et refaire derrière un chown root.root du fichier. 5) Après déconnexion du système puis reconnexion avec le même utilisateur, cette opération est toujours possible. 6) Ce cas a pu n'être produit que 2 fois par votre serviteur, une fois sur une Debian équipée d'un kernel 2.4.18, et une fois sur la dernière redhat. 7) Toutes les discussions que j'ai peu avoir avec des gens travaillant autour de la sécurité du noyau, m'affirment, que, outre le fait que ce comportement soit "quasi" impossible, cela ne devrait pas perdurer après déconnexion/reconnexion de l'utilisateur
Ma question est simple : comment est ce possible, et de quel coté chercher ?
Pour information, de nombreux tests avaient été effectués sur la machine avant de se retrouver dans cet état, notamment des outils de recherche de type buffer overflow comme bfbtester ou divers exploits kernel (ptrace par exemple) avec diverses modifications avaient été effectués avant. Je ne sais pas à partir de quel moment est intervenu ce bug, puisque je m'en suis rendu compte par hasard.
Si quelqu'un à une piste, elle est la bienvenue.
S'il s'agit de la même machine, voir du côté du disque dur, de la mémoire ou du cache processeur. J'ai déjà pu observer de telles joyeusetés (moi, c'était plutôt, root n'a plus le droit de modifier ses propres fichiers). Que disent dmesg et /var/log/auth.log (sur la debian) ?
Cordialement,
JKB
Patrick Mevzek
Ma question est simple : comment est ce possible, et de quel coté chercher ?
Je dis peut-être une connerie, mais ca ne serait pas possible avec les ``capabilities'' positionnées sur un process login ou sshd (selon la connexion employée) et récupérés par le shell de connexion ?
Dans capability.h je trouve: /* In a system with the [_POSIX_CHOWN_RESTRICTED] option defined, this overrides the restriction of changing file ownership and group ownership. */
#define CAP_CHOWN 0
[..]
/* Transfer any capability in your permitted set to any pid, remove any capability in your permitted set from any pid */
#define CAP_SETPCAP 8
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Ma question est simple : comment est ce possible, et de quel coté chercher ?
Je dis peut-être une connerie, mais ca ne serait pas possible avec les
``capabilities'' positionnées sur un process login ou sshd (selon la
connexion employée) et récupérés par le shell de connexion ?
Dans capability.h je trouve:
/* In a system with the [_POSIX_CHOWN_RESTRICTED] option defined, this
overrides the restriction of changing file ownership and group
ownership. */
#define CAP_CHOWN 0
[..]
/* Transfer any capability in your permitted set to any pid,
remove any capability in your permitted set from any pid */
#define CAP_SETPCAP 8
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Ma question est simple : comment est ce possible, et de quel coté chercher ?
Je dis peut-être une connerie, mais ca ne serait pas possible avec les ``capabilities'' positionnées sur un process login ou sshd (selon la connexion employée) et récupérés par le shell de connexion ?
Dans capability.h je trouve: /* In a system with the [_POSIX_CHOWN_RESTRICTED] option defined, this overrides the restriction of changing file ownership and group ownership. */
#define CAP_CHOWN 0
[..]
/* Transfer any capability in your permitted set to any pid, remove any capability in your permitted set from any pid */
#define CAP_SETPCAP 8
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Christophe Casalegno
JKB wrote:
S'il s'agit de la même machine, voir du côté du disque dur, de la mémoire ou du cache processeur. J'ai déjà pu observer de telles joyeusetés (moi, c'était plutôt, root n'a plus le droit de modifier ses propres fichiers). Que disent dmesg et /var/log/auth.log (sur la debian) ?
Ce n'était pas "la même", cependant il est possible que certains composants étaient les mêmes. Je n'ai plus accès à ces machines, j'avais bien pensé à l'influence possible du matériel, sans toutefois trouver une piste réellement probante.
Ces manifestations qui te sont arrivées sont arrivées suite à des opérations particulières ?
S'il s'agit de la même machine, voir du côté du disque dur, de la mémoire
ou du cache processeur. J'ai déjà pu observer de telles joyeusetés (moi,
c'était plutôt, root n'a plus le droit de modifier ses propres fichiers).
Que disent dmesg et /var/log/auth.log (sur la debian) ?
Ce n'était pas "la même", cependant il est possible que certains composants
étaient les mêmes. Je n'ai plus accès à ces machines, j'avais bien pensé à
l'influence possible du matériel, sans toutefois trouver une piste
réellement probante.
Ces manifestations qui te sont arrivées sont arrivées suite à des opérations
particulières ?
S'il s'agit de la même machine, voir du côté du disque dur, de la mémoire ou du cache processeur. J'ai déjà pu observer de telles joyeusetés (moi, c'était plutôt, root n'a plus le droit de modifier ses propres fichiers). Que disent dmesg et /var/log/auth.log (sur la debian) ?
Ce n'était pas "la même", cependant il est possible que certains composants étaient les mêmes. Je n'ai plus accès à ces machines, j'avais bien pensé à l'influence possible du matériel, sans toutefois trouver une piste réellement probante.
Ces manifestations qui te sont arrivées sont arrivées suite à des opérations particulières ?
Je dis peut-être une connerie, mais ca ne serait pas possible avec les ``capabilities'' positionnées sur un process login ou sshd (selon la connexion employée) et récupérés par le shell de connexion ?
Est t'il possible, en théorie, de changer le positionnement des capability dynamiquement ?
Je dis peut-être une connerie, mais ca ne serait pas possible avec les
``capabilities'' positionnées sur un process login ou sshd (selon la
connexion employée) et récupérés par le shell de connexion ?
Est t'il possible, en théorie, de changer le positionnement des capability
dynamiquement ?
Je dis peut-être une connerie, mais ca ne serait pas possible avec les ``capabilities'' positionnées sur un process login ou sshd (selon la connexion employée) et récupérés par le shell de connexion ?
Est t'il possible, en théorie, de changer le positionnement des capability dynamiquement ?
Je dis peut-être une connerie, mais ca ne serait pas possible avec les ``capabilities'' positionnées sur un process login ou sshd (selon la connexion employée) et récupérés par le shell de connexion ?
Est t'il possible, en théorie, de changer le positionnement des capability dynamiquement ?
This program can be used to set the process capabilities of running processes. In order to work, it needs to be executing with CAP_SETPCAP raised, and the only capabilities that this program can bestow on others are a subset of its effective set. This program is mostly intended as an example -- a safe use of CAP_SETPCAP has yet to be demonstrated!
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Je dis peut-être une connerie, mais ca ne serait pas possible avec les
``capabilities'' positionnées sur un process login ou sshd (selon la
connexion employée) et récupérés par le shell de connexion ?
Est t'il possible, en théorie, de changer le positionnement des capability
dynamiquement ?
This program can be used to set the process capabilities of running
processes. In order to work, it needs to be executing with CAP_SETPCAP
raised, and the only capabilities that this program can bestow on others
are a subset of its effective set. This program is mostly intended as an
example -- a safe use of CAP_SETPCAP has yet to be demonstrated!
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Je dis peut-être une connerie, mais ca ne serait pas possible avec les ``capabilities'' positionnées sur un process login ou sshd (selon la connexion employée) et récupérés par le shell de connexion ?
Est t'il possible, en théorie, de changer le positionnement des capability dynamiquement ?
This program can be used to set the process capabilities of running processes. In order to work, it needs to be executing with CAP_SETPCAP raised, and the only capabilities that this program can bestow on others are a subset of its effective set. This program is mostly intended as an example -- a safe use of CAP_SETPCAP has yet to be demonstrated!
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Nicob
On Tue, 20 Sep 2005 16:24:11 +0000, Christophe Casalegno wrote:
Est t'il possible, en théorie, de changer le positionnement des capability dynamiquement ?
Oui. Mais dans le cas classique de modification dynamique des 'capabilities', on est plutôt du côté de la suppression de droits (par l'admin, pour durcir sa machine) que du côté de l'ajout (pirate activant sa backdoor).
Pour la suppression, il existe des outils conviviaux comme 'lcap' :
http://packages.debian.org/stable/admin/lcap.html
Pour l'ajout :
* soit le process dispose de CAP_SYS_RAWIO, et il peut écrire dans /dev/mem pour s'ajouter des droits directement dans le noyau
* soit un process disposant de CAP_SETPCAP lui modifie ses capabilities, via l'outil 'setcaps' ou l'appel système capset()
* soit le flot d'exécution du process 'init' (PID=1) a été modifié (en dur sur le disque ou via exploitation d'un bof) afin qu'il modifie le "capability bounding set" (la valeur globale)
* soit l'exploitation d'une faille dans le noyau est utilisée pour modifier ses droits en RAM (équivalent à #1, mais via une vuln)
Toujours est-il qu'un UID différent de 0 ne signifie plus de nos jours (sous Linux en tout cas) que l'utilisateur en question ne dispose pas de plus de privilèges que le compte root :-)
Nicob
On Tue, 20 Sep 2005 16:24:11 +0000, Christophe Casalegno wrote:
Est t'il possible, en théorie, de changer le positionnement des capability
dynamiquement ?
Oui. Mais dans le cas classique de modification dynamique des
'capabilities', on est plutôt du côté de la suppression de droits (par
l'admin, pour durcir sa machine) que du côté de l'ajout (pirate activant
sa backdoor).
Pour la suppression, il existe des outils conviviaux comme 'lcap' :
http://packages.debian.org/stable/admin/lcap.html
Pour l'ajout :
* soit le process dispose de CAP_SYS_RAWIO, et il peut écrire dans
/dev/mem pour s'ajouter des droits directement dans le noyau
* soit un process disposant de CAP_SETPCAP lui modifie ses capabilities,
via l'outil 'setcaps' ou l'appel système capset()
* soit le flot d'exécution du process 'init' (PID=1) a été modifié (en
dur sur le disque ou via exploitation d'un bof) afin qu'il modifie le
"capability bounding set" (la valeur globale)
* soit l'exploitation d'une faille dans le noyau est utilisée pour
modifier ses droits en RAM (équivalent à #1, mais via une vuln)
Toujours est-il qu'un UID différent de 0 ne signifie plus de nos jours
(sous Linux en tout cas) que l'utilisateur en question ne dispose pas de
plus de privilèges que le compte root :-)
On Tue, 20 Sep 2005 16:24:11 +0000, Christophe Casalegno wrote:
Est t'il possible, en théorie, de changer le positionnement des capability dynamiquement ?
Oui. Mais dans le cas classique de modification dynamique des 'capabilities', on est plutôt du côté de la suppression de droits (par l'admin, pour durcir sa machine) que du côté de l'ajout (pirate activant sa backdoor).
Pour la suppression, il existe des outils conviviaux comme 'lcap' :
http://packages.debian.org/stable/admin/lcap.html
Pour l'ajout :
* soit le process dispose de CAP_SYS_RAWIO, et il peut écrire dans /dev/mem pour s'ajouter des droits directement dans le noyau
* soit un process disposant de CAP_SETPCAP lui modifie ses capabilities, via l'outil 'setcaps' ou l'appel système capset()
* soit le flot d'exécution du process 'init' (PID=1) a été modifié (en dur sur le disque ou via exploitation d'un bof) afin qu'il modifie le "capability bounding set" (la valeur globale)
* soit l'exploitation d'une faille dans le noyau est utilisée pour modifier ses droits en RAM (équivalent à #1, mais via une vuln)
Toujours est-il qu'un UID différent de 0 ne signifie plus de nos jours (sous Linux en tout cas) que l'utilisateur en question ne dispose pas de plus de privilèges que le compte root :-)
Nicob
Christophe Casalegno
Nicob wrote:
Est t'il possible, en théorie, de changer le positionnement des capability dynamiquement ?
Oui. Mais dans le cas classique de modification dynamique des 'capabilities', on est plutôt du côté de la suppression de droits (par l'admin, pour durcir sa machine) que du côté de l'ajout (pirate activant sa backdoor).
Dans le cas que je cite, il n'y avait pas de backdoor, la machine venait même d'être réinstallée et mise à jour juste avant. Un utilisateur peut il concrêtement effectuer ce type de modifications ?
Se peut t'il que l'utilisation "aléatoire" de certains outils est pu provoquer cet état, état qui persistait même après deconnexion/reconnexion de l'utilisateur ?
Pour l'ajout :
* soit le process dispose de CAP_SYS_RAWIO, et il peut écrire dans /dev/mem pour s'ajouter des droits directement dans le noyau
* soit un process disposant de CAP_SETPCAP lui modifie ses capabilities, via l'outil 'setcaps' ou l'appel système capset()
* soit le flot d'exécution du process 'init' (PID=1) a été modifié (en dur sur le disque ou via exploitation d'un bof) afin qu'il modifie le "capability bounding set" (la valeur globale)
* soit l'exploitation d'une faille dans le noyau est utilisée pour modifier ses droits en RAM (équivalent à #1, mais via une vuln)
Oui, mais en théorie aucune de ces modifications ne peut être effectuée par un utilisateur lambda, sans modifications préalables du système. La machine et ses binaires ayant été torturés pendant près de 48H00 non stop, je pensais à un comportement "aléatoire", cependant cela continue de m'intriguer.
Est t'il possible, en théorie, de changer le positionnement des
capability dynamiquement ?
Oui. Mais dans le cas classique de modification dynamique des
'capabilities', on est plutôt du côté de la suppression de droits (par
l'admin, pour durcir sa machine) que du côté de l'ajout (pirate activant
sa backdoor).
Dans le cas que je cite, il n'y avait pas de backdoor, la machine venait
même d'être réinstallée et mise à jour juste avant. Un utilisateur peut il
concrêtement effectuer ce type de modifications ?
Se peut t'il que l'utilisation "aléatoire" de certains outils est pu
provoquer cet état, état qui persistait même après deconnexion/reconnexion
de l'utilisateur ?
Pour l'ajout :
* soit le process dispose de CAP_SYS_RAWIO, et il peut écrire dans
/dev/mem pour s'ajouter des droits directement dans le noyau
* soit un process disposant de CAP_SETPCAP lui modifie ses capabilities,
via l'outil 'setcaps' ou l'appel système capset()
* soit le flot d'exécution du process 'init' (PID=1) a été modifié (en
dur sur le disque ou via exploitation d'un bof) afin qu'il modifie le
"capability bounding set" (la valeur globale)
* soit l'exploitation d'une faille dans le noyau est utilisée pour
modifier ses droits en RAM (équivalent à #1, mais via une vuln)
Oui, mais en théorie aucune de ces modifications ne peut être effectuée par
un utilisateur lambda, sans modifications préalables du système. La machine
et ses binaires ayant été torturés pendant près de 48H00 non stop, je
pensais à un comportement "aléatoire", cependant cela continue de
m'intriguer.
Est t'il possible, en théorie, de changer le positionnement des capability dynamiquement ?
Oui. Mais dans le cas classique de modification dynamique des 'capabilities', on est plutôt du côté de la suppression de droits (par l'admin, pour durcir sa machine) que du côté de l'ajout (pirate activant sa backdoor).
Dans le cas que je cite, il n'y avait pas de backdoor, la machine venait même d'être réinstallée et mise à jour juste avant. Un utilisateur peut il concrêtement effectuer ce type de modifications ?
Se peut t'il que l'utilisation "aléatoire" de certains outils est pu provoquer cet état, état qui persistait même après deconnexion/reconnexion de l'utilisateur ?
Pour l'ajout :
* soit le process dispose de CAP_SYS_RAWIO, et il peut écrire dans /dev/mem pour s'ajouter des droits directement dans le noyau
* soit un process disposant de CAP_SETPCAP lui modifie ses capabilities, via l'outil 'setcaps' ou l'appel système capset()
* soit le flot d'exécution du process 'init' (PID=1) a été modifié (en dur sur le disque ou via exploitation d'un bof) afin qu'il modifie le "capability bounding set" (la valeur globale)
* soit l'exploitation d'une faille dans le noyau est utilisée pour modifier ses droits en RAM (équivalent à #1, mais via une vuln)
Oui, mais en théorie aucune de ces modifications ne peut être effectuée par un utilisateur lambda, sans modifications préalables du système. La machine et ses binaires ayant été torturés pendant près de 48H00 non stop, je pensais à un comportement "aléatoire", cependant cela continue de m'intriguer.
Si quelqu'un à une piste, elle est la bienvenue. EN TOUT PREMIER LIEU
il faut ABSOLUMENT obtenir une démarche REPRODUCTIBLE déjà pour toi et surtout pour les autres. Sans possibilité de reproduction du phénomène, inutile d'en parler.
En clair, il faut une PROCEDURE détaillée permettant à quiconque, et ntoamment, aux développeurs qui << survivent >> sur le 2.4 de reproduire le phénomène. Ce que tu as observé peut-être TRES grave et si cela est reconductible sur le 2.6 et permettre des intrusions non encore observées.
db
--
Courriel : usenet blas net
[...]
Si quelqu'un à une piste, elle est la bienvenue.
EN TOUT PREMIER LIEU
il faut ABSOLUMENT obtenir une démarche REPRODUCTIBLE déjà pour toi et
surtout pour les autres.
Sans possibilité de reproduction du phénomène, inutile d'en parler.
En clair, il faut une PROCEDURE détaillée permettant à quiconque, et
ntoamment, aux développeurs qui << survivent >> sur le 2.4 de reproduire
le phénomène.
Ce que tu as observé peut-être TRES grave et si cela est reconductible
sur le 2.6 et permettre des intrusions non encore observées.
Si quelqu'un à une piste, elle est la bienvenue. EN TOUT PREMIER LIEU
il faut ABSOLUMENT obtenir une démarche REPRODUCTIBLE déjà pour toi et surtout pour les autres. Sans possibilité de reproduction du phénomène, inutile d'en parler.
En clair, il faut une PROCEDURE détaillée permettant à quiconque, et ntoamment, aux développeurs qui << survivent >> sur le 2.4 de reproduire le phénomène. Ce que tu as observé peut-être TRES grave et si cela est reconductible sur le 2.6 et permettre des intrusions non encore observées.
db
--
Courriel : usenet blas net
Nicob
On Tue, 20 Sep 2005 21:30:40 +0000, Christophe Casalegno wrote:
Dans le cas que je cite, il n'y avait pas de backdoor, la machine venait même d'être réinstallée et mise à jour juste avant.
Pas de backdoor connue, je dirais. Je me souviens d'un pilier de ce forum qui faisait du MITM sur des personnes téléchargeant les sources du noyau Linux et qui leur filait une version backdoorée qui s'arrêtait avec un beau message en plein 'init' ;-)
[Note aux inquiets : oui, c'était tout à fait légal]
Ce que je veux dire, c'est que "réinstallé et mis à jour juste avant", ce n'est pas vraiment une garantie de l'absence de backdoor. Il faut déterminer la provenance des médias, vérifier l'intégrité des paquets, ...
Se peut t'il que l'utilisation "aléatoire" de certains outils est pu provoquer cet état, état qui persistait même après deconnexion/reconnexion de l'utilisateur ?
Tout est possible, même que des singes écrivent du Shakespear en tapant comme des idiots sur un clavier. Donc si certains des exploits touchent à /dev/mem ou exploitent le noyau, c'est possible. Mais toutefois peu probable, car on rentre là dans le domaine du 'local r00t' inconnu et exploité par hasard.
[...] je pensais à un comportement "aléatoire" [...]
Comme le disait Dominique Blas, sans reproduction possible, il sera quasiment impossible de tracer un éventuel problème. En tout cas, si tu as de nouveau sous la main ce type de machine "possédée", une sauvegarde intégrale (dont RAM, swap, ...) du système est à réaliser en vue d'analyse ultérieure !
Nicob
On Tue, 20 Sep 2005 21:30:40 +0000, Christophe Casalegno wrote:
Dans le cas que je cite, il n'y avait pas de backdoor, la machine venait
même d'être réinstallée et mise à jour juste avant.
Pas de backdoor connue, je dirais. Je me souviens d'un pilier de ce forum
qui faisait du MITM sur des personnes téléchargeant les sources du noyau
Linux et qui leur filait une version backdoorée qui s'arrêtait avec un
beau message en plein 'init' ;-)
[Note aux inquiets : oui, c'était tout à fait légal]
Ce que je veux dire, c'est que "réinstallé et mis à jour juste avant",
ce n'est pas vraiment une garantie de l'absence de backdoor. Il faut
déterminer la provenance des médias, vérifier l'intégrité des paquets, ...
Se peut t'il que l'utilisation "aléatoire" de certains outils est pu
provoquer cet état, état qui persistait même après
deconnexion/reconnexion de l'utilisateur ?
Tout est possible, même que des singes écrivent du Shakespear en tapant
comme des idiots sur un clavier. Donc si certains des exploits touchent à
/dev/mem ou exploitent le noyau, c'est possible. Mais toutefois peu
probable, car on rentre là dans le domaine du 'local r00t' inconnu et
exploité par hasard.
[...] je pensais à un comportement "aléatoire" [...]
Comme le disait Dominique Blas, sans reproduction possible, il sera
quasiment impossible de tracer un éventuel problème. En tout cas, si tu
as de nouveau sous la main ce type de machine "possédée", une sauvegarde
intégrale (dont RAM, swap, ...) du système est à réaliser en vue
d'analyse ultérieure !
On Tue, 20 Sep 2005 21:30:40 +0000, Christophe Casalegno wrote:
Dans le cas que je cite, il n'y avait pas de backdoor, la machine venait même d'être réinstallée et mise à jour juste avant.
Pas de backdoor connue, je dirais. Je me souviens d'un pilier de ce forum qui faisait du MITM sur des personnes téléchargeant les sources du noyau Linux et qui leur filait une version backdoorée qui s'arrêtait avec un beau message en plein 'init' ;-)
[Note aux inquiets : oui, c'était tout à fait légal]
Ce que je veux dire, c'est que "réinstallé et mis à jour juste avant", ce n'est pas vraiment une garantie de l'absence de backdoor. Il faut déterminer la provenance des médias, vérifier l'intégrité des paquets, ...
Se peut t'il que l'utilisation "aléatoire" de certains outils est pu provoquer cet état, état qui persistait même après deconnexion/reconnexion de l'utilisateur ?
Tout est possible, même que des singes écrivent du Shakespear en tapant comme des idiots sur un clavier. Donc si certains des exploits touchent à /dev/mem ou exploitent le noyau, c'est possible. Mais toutefois peu probable, car on rentre là dans le domaine du 'local r00t' inconnu et exploité par hasard.
[...] je pensais à un comportement "aléatoire" [...]
Comme le disait Dominique Blas, sans reproduction possible, il sera quasiment impossible de tracer un éventuel problème. En tout cas, si tu as de nouveau sous la main ce type de machine "possédée", une sauvegarde intégrale (dont RAM, swap, ...) du système est à réaliser en vue d'analyse ultérieure !
Nicob
Christophe Casalegno
Dominique Blas wrote:
Si quelqu'un à une piste, elle est la bienvenue. EN TOUT PREMIER LIEU
il faut ABSOLUMENT obtenir une démarche REPRODUCTIBLE déjà pour toi et surtout pour les autres. Sans possibilité de reproduction du phénomène, inutile d'en parler.
En clair, il faut une PROCEDURE détaillée permettant à quiconque, et ntoamment, aux développeurs qui << survivent >> sur le 2.4 de reproduire le phénomène. Ce que tu as observé peut-être TRES grave et si cela est reconductible sur le 2.6 et permettre des intrusions non encore observées.
Si c'était reproductible via une séquence que je connaitrais, je n'aurai pas eu besoin d'aide pour comprendre :), j'aurai effectué l'analyse moi même.
Je n'y ai été confronté que 2 fois, dans les 2 cas, le seul "point commun", est le passage de presque tous les binaires du système à des outils de type bfbtester, dont chown, chmod et compagnie.
Cela dit tous les gens avec qui j'ai pu en parler et qui travaillent autour du kernel m'ont dit que l'architecture du noyau était faite de telle manière, que, si cela se produisait, la déconnexion/reconnexion aurait du annuler cet "état". Je tiens à préciser que *seul* la commande chown était concernée, tout le reste, fonctionnait sans possibilité de donner des droits supplémentaires (exemple chmod)
Pour ceux qui cherchent des possibilité d'intrusions reproductibles et non encore observées, je leur conseille plutot d'aller fouiller du coté du code des pilotes "exotiques", on y trouve parfois des trucs pas très sains :).
Si quelqu'un à une piste, elle est la bienvenue.
EN TOUT PREMIER LIEU
il faut ABSOLUMENT obtenir une démarche REPRODUCTIBLE déjà pour toi et
surtout pour les autres.
Sans possibilité de reproduction du phénomène, inutile d'en parler.
En clair, il faut une PROCEDURE détaillée permettant à quiconque, et
ntoamment, aux développeurs qui << survivent >> sur le 2.4 de reproduire
le phénomène.
Ce que tu as observé peut-être TRES grave et si cela est reconductible
sur le 2.6 et permettre des intrusions non encore observées.
Si c'était reproductible via une séquence que je connaitrais, je n'aurai pas
eu besoin d'aide pour comprendre :), j'aurai effectué l'analyse moi même.
Je n'y ai été confronté que 2 fois, dans les 2 cas, le seul "point commun",
est le passage de presque tous les binaires du système à des outils de type
bfbtester, dont chown, chmod et compagnie.
Cela dit tous les gens avec qui j'ai pu en parler et qui travaillent autour
du kernel m'ont dit que l'architecture du noyau était faite de telle
manière, que, si cela se produisait, la déconnexion/reconnexion aurait du
annuler cet "état". Je tiens à préciser que *seul* la commande chown était
concernée, tout le reste, fonctionnait sans possibilité de donner des
droits supplémentaires (exemple chmod)
Pour ceux qui cherchent des possibilité d'intrusions reproductibles et non
encore observées, je leur conseille plutot d'aller fouiller du coté du code
des pilotes "exotiques", on y trouve parfois des trucs pas très sains :).
Si quelqu'un à une piste, elle est la bienvenue. EN TOUT PREMIER LIEU
il faut ABSOLUMENT obtenir une démarche REPRODUCTIBLE déjà pour toi et surtout pour les autres. Sans possibilité de reproduction du phénomène, inutile d'en parler.
En clair, il faut une PROCEDURE détaillée permettant à quiconque, et ntoamment, aux développeurs qui << survivent >> sur le 2.4 de reproduire le phénomène. Ce que tu as observé peut-être TRES grave et si cela est reconductible sur le 2.6 et permettre des intrusions non encore observées.
Si c'était reproductible via une séquence que je connaitrais, je n'aurai pas eu besoin d'aide pour comprendre :), j'aurai effectué l'analyse moi même.
Je n'y ai été confronté que 2 fois, dans les 2 cas, le seul "point commun", est le passage de presque tous les binaires du système à des outils de type bfbtester, dont chown, chmod et compagnie.
Cela dit tous les gens avec qui j'ai pu en parler et qui travaillent autour du kernel m'ont dit que l'architecture du noyau était faite de telle manière, que, si cela se produisait, la déconnexion/reconnexion aurait du annuler cet "état". Je tiens à préciser que *seul* la commande chown était concernée, tout le reste, fonctionnait sans possibilité de donner des droits supplémentaires (exemple chmod)
Pour ceux qui cherchent des possibilité d'intrusions reproductibles et non encore observées, je leur conseille plutot d'aller fouiller du coté du code des pilotes "exotiques", on y trouve parfois des trucs pas très sains :).
