je suis sous redhat 7.3 et je ne sais pas si ma version de kernel est
touché par la derniere faille decouverte aujourdhui et ou telecharger le
correctif en rpm
ma config:
2.4.20-18.7smp #1 SMP Thu May 29 07:49:23 EDT 2003
Oups ! Il faut bien évidemment lire "faille remote dans rsyncd". Désolé ...
Tu m'as fait peur là... J'ai un certain nombre de dhcpds et comme j'avais rien vu passer sur une éventuelle faille...
Nicob
On Thu, 04 Dec 2003 22:39:12 +0000, Emmanuel Florac wrote:
Oui, oui. Enfin il suffit de passer au 2.4.23, ce qui ne pose pas de problème (fait aujourd'hui chez moi).
Mais il y a une différence entre "chez soi" et sur une architecture de plusieurs dizaines de machines en prod et avec des SLA de disponibilité à respecter.
Et on peut parfaitement chrooter apache (c'est même conseillé si on est un peu parano).
Le chroot ne fera pas tout (cf. l'article de Misc 9 à ce sujet)
Et on pourra encore une fois louer la célérité avec laquelle la faille a été comblée.
Désolé de casser ton délire, mais la faille était connue depuis le mois de Septembre. Tu parles d'une célérité :(
Pour preuve, le Changelog du noyau 2.6.0-test6, qui est daté du 27 Septembre 2003 :
Au fait, des détails techniques sur cette faille :
http://isec.pl/papers/linux_kernel_do_brk.pdf
Nicob
On Thu, 04 Dec 2003 22:39:12 +0000, Emmanuel Florac wrote:
Oui, oui. Enfin il suffit de passer au 2.4.23, ce qui ne pose pas de
problème (fait aujourd'hui chez moi).
Mais il y a une différence entre "chez soi" et sur une architecture de
plusieurs dizaines de machines en prod et avec des SLA de disponibilité
à respecter.
Et on peut parfaitement chrooter apache (c'est même conseillé si on
est un peu parano).
Le chroot ne fera pas tout (cf. l'article de Misc 9 à ce sujet)
Et on pourra encore une fois louer la célérité avec laquelle la
faille a été comblée.
Désolé de casser ton délire, mais la faille était connue depuis le
mois de Septembre. Tu parles d'une célérité :(
Pour preuve, le Changelog du noyau 2.6.0-test6, qui est daté du 27
Septembre 2003 :
On Thu, 04 Dec 2003 22:39:12 +0000, Emmanuel Florac wrote:
Oui, oui. Enfin il suffit de passer au 2.4.23, ce qui ne pose pas de problème (fait aujourd'hui chez moi).
Mais il y a une différence entre "chez soi" et sur une architecture de plusieurs dizaines de machines en prod et avec des SLA de disponibilité à respecter.
Et on peut parfaitement chrooter apache (c'est même conseillé si on est un peu parano).
Le chroot ne fera pas tout (cf. l'article de Misc 9 à ce sujet)
Et on pourra encore une fois louer la célérité avec laquelle la faille a été comblée.
Désolé de casser ton délire, mais la faille était connue depuis le mois de Septembre. Tu parles d'une célérité :(
Pour preuve, le Changelog du noyau 2.6.0-test6, qui est daté du 27 Septembre 2003 :
Au fait, des détails techniques sur cette faille :
http://isec.pl/papers/linux_kernel_do_brk.pdf
Nicob
Erwan David
Emmanuel Florac écrivait :
Et on pourra encore une fois louer la célérité avec laquelle la faille a été comblée. Je vous rappelle qu'il y au moins une dizaine de failles répertoriées depuis des mois sur les systèmes micromou.
Justement non. Là l'équipe linux a quand même bien merdé puisque la faille est connue depuis septembre, quelques jours avant la sortie du 2.4.22 et qu'elle a été gardée sous le coude pour ne pas retarder le 2.4.22...
Emmanuel Florac <eflorac@verisign.com> écrivait :
Et on pourra encore une fois louer la célérité avec laquelle la faille a
été comblée. Je vous rappelle qu'il y au moins une dizaine de failles
répertoriées depuis des mois sur les systèmes micromou.
Justement non. Là l'équipe linux a quand même bien merdé puisque la
faille est connue depuis septembre, quelques jours avant la sortie du
2.4.22 et qu'elle a été gardée sous le coude pour ne pas retarder le
2.4.22...
Et on pourra encore une fois louer la célérité avec laquelle la faille a été comblée. Je vous rappelle qu'il y au moins une dizaine de failles répertoriées depuis des mois sur les systèmes micromou.
Justement non. Là l'équipe linux a quand même bien merdé puisque la faille est connue depuis septembre, quelques jours avant la sortie du 2.4.22 et qu'elle a été gardée sous le coude pour ne pas retarder le 2.4.22...
[Sauron De Mordor]
Emmanuel Florac wrote:
Dans article , disait...
C'est tout ? Je trouve ça au contraire super grave, vu le nombre de manière dont on dispose pour obtenir un shell sur une machine.
A ta guise, dans ce cas tu n'as qu'à passer au 2.4.23, ça ne prend guère de temps.
mauvaise reponse, si a la maison on change de kernel comme de chemise, sur un environement plus contraint, cela peu etre moins evident, (release notes, perfs, compatibilites.....)
mais un pb de secu reste un pb de secu quelque soit l OS.
ce qui est important n ets pas de patche ou non, ni la facilite qu on a a obtenir les acces, mais de quel type d acces on obtient, et en combient de temps le crorectif est disponible. ensuite, a l admin de gerer cela.
le pb avec M$ c est qu il y a encore bcp de bug secu sortit cet ete qui sont encore non patchable. sous Linux ou les Unix, la reactivite est plus forte ( en genmeral)
Pour une machine à la maison ça n'a aucune importance.
Gni ? Un trojan pourrait exploiter cette faille pour passer root et faire ce qu'il a à faire...
Pour la beauté du geste, alors, parce qu'il est quand même plus facile de trouver une faille exploitable sur un bête sendmail.
c est une legende, ce n est plus vrai depuis bien longtemps.
sendmail n a pas plus de pb de securite que les autres appli desormais.
Emmanuel Florac wrote:
Dans article <pan.2003.12.04.10.00.05.713651@cartel-securite.fr>,
blancher@cartel-securite.fr disait...
C'est tout ? Je trouve ça au contraire super grave, vu le nombre de
manière dont on dispose pour obtenir un shell sur une machine.
A ta guise, dans ce cas tu n'as qu'à passer au 2.4.23, ça ne prend guère
de temps.
mauvaise reponse, si a la maison on change de kernel comme de chemise,
sur un environement plus contraint, cela peu etre moins evident,
(release notes, perfs, compatibilites.....)
mais un pb de secu reste un pb de secu quelque soit l OS.
ce qui est important n ets pas de patche ou non, ni la facilite qu on a
a obtenir les acces, mais de quel type d acces on obtient, et en
combient de temps le crorectif est disponible. ensuite, a l admin de
gerer cela.
le pb avec M$ c est qu il y a encore bcp de bug secu sortit cet ete qui
sont encore non patchable. sous Linux ou les Unix, la reactivite est
plus forte ( en genmeral)
Pour une machine à la maison ça n'a aucune importance.
Gni ?
Un trojan pourrait exploiter cette faille pour passer root et faire ce
qu'il a à faire...
Pour la beauté du geste, alors, parce qu'il est quand même plus facile de
trouver une faille exploitable sur un bête sendmail.
c est une legende, ce n est plus vrai depuis bien longtemps.
sendmail n a pas plus de pb de securite que les autres appli desormais.
C'est tout ? Je trouve ça au contraire super grave, vu le nombre de manière dont on dispose pour obtenir un shell sur une machine.
A ta guise, dans ce cas tu n'as qu'à passer au 2.4.23, ça ne prend guère de temps.
mauvaise reponse, si a la maison on change de kernel comme de chemise, sur un environement plus contraint, cela peu etre moins evident, (release notes, perfs, compatibilites.....)
mais un pb de secu reste un pb de secu quelque soit l OS.
ce qui est important n ets pas de patche ou non, ni la facilite qu on a a obtenir les acces, mais de quel type d acces on obtient, et en combient de temps le crorectif est disponible. ensuite, a l admin de gerer cela.
le pb avec M$ c est qu il y a encore bcp de bug secu sortit cet ete qui sont encore non patchable. sous Linux ou les Unix, la reactivite est plus forte ( en genmeral)
Pour une machine à la maison ça n'a aucune importance.
Gni ? Un trojan pourrait exploiter cette faille pour passer root et faire ce qu'il a à faire...
Pour la beauté du geste, alors, parce qu'il est quand même plus facile de trouver une faille exploitable sur un bête sendmail.
c est une legende, ce n est plus vrai depuis bien longtemps.
sendmail n a pas plus de pb de securite que les autres appli desormais.
[Sauron De Mordor]
Emmanuel Florac wrote:
Dans article , disait...
La dernière faille permet à un utilisateur local de passer root, c'est tout... Pour une machine à la maison ça n'a aucune importance.
Sauf si on combine ça avec, par exemple, une faille Apache permettant d'obtenir les droits d'un utilisateur normalement peu privilégié ...
yup et aussi mettre /tmp, /var en no exec, nosuid, ca evite aussi a bcp de faille d etre exploitable
et si on est parano, les qq patch de grsecurity devrais etre ok ?
j ai pas essaye l exploit chez moi, est ce que qq un a un kernel grsec et a essayer l exploit distribue sur securityfocus ?
Oui, oui. Enfin il suffit de passer au 2.4.23, ce qui ne pose pas de problème (fait aujourd'hui chez moi). Et on peut parfaitement chrooter apache (c'est même conseillé si on est un peu parano). Et on pourra encore une fois louer la célérité avec laquelle la faille a été comblée. Je vous rappelle qu'il y au moins une dizaine de failles répertoriées depuis des mois sur les systèmes micromou.
Emmanuel Florac wrote:
Dans article <pan.2003.12.04.09.34.23.850728@I.hate.spammers.com>,
nicob@I.hate.spammers.com disait...
La dernière faille permet à un utilisateur local de passer root, c'est
tout... Pour une machine à la maison ça n'a aucune importance.
Sauf si on combine ça avec, par exemple, une faille Apache permettant
d'obtenir les droits d'un utilisateur normalement peu privilégié ...
yup
et aussi mettre /tmp, /var en no exec, nosuid, ca evite aussi a bcp de
faille d etre exploitable
et si on est parano, les qq patch de grsecurity devrais etre ok ?
j ai pas essaye l exploit chez moi, est ce que qq un a un kernel grsec
et a essayer l exploit distribue sur securityfocus ?
Oui, oui. Enfin il suffit de passer au 2.4.23, ce qui ne pose pas de
problème (fait aujourd'hui chez moi). Et on peut parfaitement chrooter
apache (c'est même conseillé si on est un peu parano).
Et on pourra encore une fois louer la célérité avec laquelle la faille a
été comblée. Je vous rappelle qu'il y au moins une dizaine de failles
répertoriées depuis des mois sur les systèmes micromou.
La dernière faille permet à un utilisateur local de passer root, c'est tout... Pour une machine à la maison ça n'a aucune importance.
Sauf si on combine ça avec, par exemple, une faille Apache permettant d'obtenir les droits d'un utilisateur normalement peu privilégié ...
yup et aussi mettre /tmp, /var en no exec, nosuid, ca evite aussi a bcp de faille d etre exploitable
et si on est parano, les qq patch de grsecurity devrais etre ok ?
j ai pas essaye l exploit chez moi, est ce que qq un a un kernel grsec et a essayer l exploit distribue sur securityfocus ?
Oui, oui. Enfin il suffit de passer au 2.4.23, ce qui ne pose pas de problème (fait aujourd'hui chez moi). Et on peut parfaitement chrooter apache (c'est même conseillé si on est un peu parano). Et on pourra encore une fois louer la célérité avec laquelle la faille a été comblée. Je vous rappelle qu'il y au moins une dizaine de failles répertoriées depuis des mois sur les systèmes micromou.
Neky
Cedric Blancher wrote:
Ce n'est pas parce que la faille demande des conditions supplémentaires pour être exploitées (i.e. avoir un shell sur la machine) que son impact en est diminué.
Mais euh avoir un shell sur la machine, c'est faisable à distance n'importe comment avec ce qu'on appelle les shellcodes, non ? Où je me trompe complètement ?
Cedric Blancher wrote:
Ce n'est pas parce que la faille demande des conditions supplémentaires
pour être exploitées (i.e. avoir un shell sur la machine) que son impact
en est diminué.
Mais euh avoir un shell sur la machine, c'est faisable à distance
n'importe comment avec ce qu'on appelle les shellcodes, non ?
Où je me trompe complètement ?
Ce n'est pas parce que la faille demande des conditions supplémentaires pour être exploitées (i.e. avoir un shell sur la machine) que son impact en est diminué.
Mais euh avoir un shell sur la machine, c'est faisable à distance n'importe comment avec ce qu'on appelle les shellcodes, non ? Où je me trompe complètement ?
Frederic Giquel
Emmanuel Florac wrote:
Dans article , disait...
La dernière faille permet à un utilisateur local de passer root, c'est tout... Pour une machine à la maison ça n'a aucune importance.
Sauf si on combine ça avec, par exemple, une faille Apache permettant d'obtenir les droits d'un utilisateur normalement peu privilégié ...
yup et aussi mettre /tmp, /var en no exec, nosuid, ca evite aussi a bcp de faille d etre exploitable
Il y a aussi l'option nodev qui peut être utilisée pour les partitions qui ne contiennent pas de fichier de périphérique.
Concernant l'option noexec, son efficacité est toute relative sachant que la commande "/lib/ld-linux.so.2 foobar" exécutera le programme foobar même si celui-ci se situe sur une partition "non-exécutable".
Fred
Emmanuel Florac wrote:
Dans article <pan.2003.12.04.09.34.23.850728@I.hate.spammers.com>,
nicob@I.hate.spammers.com disait...
La dernière faille permet à un utilisateur local de passer root, c'est
tout... Pour une machine à la maison ça n'a aucune importance.
Sauf si on combine ça avec, par exemple, une faille Apache permettant
d'obtenir les droits d'un utilisateur normalement peu privilégié ...
yup
et aussi mettre /tmp, /var en no exec, nosuid, ca evite aussi a bcp de faille d
etre exploitable
Il y a aussi l'option nodev qui peut être utilisée pour les partitions
qui ne contiennent pas de fichier de périphérique.
Concernant l'option noexec, son efficacité est toute relative sachant
que la commande "/lib/ld-linux.so.2 foobar" exécutera le programme
foobar même si celui-ci se situe sur une partition "non-exécutable".
La dernière faille permet à un utilisateur local de passer root, c'est tout... Pour une machine à la maison ça n'a aucune importance.
Sauf si on combine ça avec, par exemple, une faille Apache permettant d'obtenir les droits d'un utilisateur normalement peu privilégié ...
yup et aussi mettre /tmp, /var en no exec, nosuid, ca evite aussi a bcp de faille d etre exploitable
Il y a aussi l'option nodev qui peut être utilisée pour les partitions qui ne contiennent pas de fichier de périphérique.
Concernant l'option noexec, son efficacité est toute relative sachant que la commande "/lib/ld-linux.so.2 foobar" exécutera le programme foobar même si celui-ci se situe sur une partition "non-exécutable".
