| goblin_rieur |
black_lord a écrit :
non, pas du tout. c'est plus que réducteur et faux.
Imagine que tu analyses tes access logs (action à posteriori donc); et que tu mettes l'UA dans une variable pour l'afficher (c'est un exemple, pas un PoC) : te voila vulnérable. il n'y a pas un besoin impératif d'interactivité, et encore moins de PHP obligatoirement.
|
j'ai effectivement pris un énorme raccourci ....
L'experience démontre qu'une faille n'a d'interet/danger selon le coté où on se place que si elle est exploitable depuis l'exterieur... si tu as un accès physique à une machine il n'existera jamais de protection à quoi que ce puisse etre...
la seule exploitation distante démontrée de bout en bout est bien pour l'instant l'utilisation via une page auto-hebergée, à ma connaissance.
y'a des tas d'exemples mais qui ne marchent que dans des conditions parfaites sous entendant entre autre avoir déjà franchis un éventuel routage pour ne citer que l'erreur de base de 90% des démonstrations "failed"
Mais ça n'empèche en rien oui évidement en local toute utilisation de bash sans le correctif (y compris l'accès en réseau local et sessions réseau actives bien sur) d'avoir la faille active, je ne prétends absoluement pas du tout le contraire... :hello:
Les conditions de l'exploitation à minima : (documentés dans le patch)
no security services, like selinux, and have a netwok listenning service active, or an application (even webapps) launching a bash script |
|