September 2011 Archives

lundi 19 septembre 2011, 21:06:14 (UTC+0200)

HP TouchPad : accéder localement au shell

Suite à mes premiers pas sur la tablette HP TouchPad, je souhaitais disposer d'un shell accessible localement (c'est-à-dire sans cable USB ni connexion réseau). Le client de base sous webOS étant le navigateur, un shell "webifié" semblait être une bonne solution. Après avoir regardé l'offre côté logiciels libres (et essayé les démos présentes sur le site d'AnyTerm), le logiciel shellinabox a été retenu, dans sa version svn (r239).


Pour mener à bien la manip décrite ci-dessous, il faut :

  • une machine Unix pour réaliser la compilation (ici Ubuntu x86 32 bits)
  • un compilateur cross-platform (ici celui de Sourcery)
  • un HP TouchPad accessible en ligne de commande via SSH ou novaterm (ici v3.0.2)

Première étape, le compilateur cross-platform ! En raison de soucis avec le compilateur inclus dans le PalmPDK, nous utiliserons Sourcery G++ Lite 2011.03-41 for ARM GNU/Linux. Le récapitulatif des différentes étapes :


Télécharger le fichier "IA32 GNU/Linux TAR" et le décompresser :

$> tar xvjf arm-2011.03-41-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2

Se déplacer dans le répertoire où sont stockés les binaires et les renommer afin de manipuler les noms usuels (gcc, objcopy, ...) :

$> cd arm-2011.03/bin
$> rename 's/arm-none-linux-gnueabi-//' *

Modifier $PATH afin de pointer d'abord vers ces binaires :

$> which gcc
/usr/bin/gcc
$> PATH=/home/nicob/arm-2011.03/bin:$PATH
$> export PATH
$> which gcc
/home/nicob/arm-2011.03/bin/gcc

Et voilà, le compilateur cross-platform sera donc appelé par défaut (dans ce shell) quand gcc sera invoqué.


Deuxième étape : OpenSSL ! Preware propose les paquets openssl et libssl, qui sont nécessaires à l'installation d'OpenSSH. Il serait donc possible d'utiliser ces paquets (ou ceux du canal parallèle ipkg-opt), mais cela créérait des problèmes de dépendances. Il faudrait en effet fournir un binaire pour les utilisateurs de Preware et un pour ceux de ikpg-opt, ou restreindre l'utilisation à un seul de ces catalogues alternatifs, ou encore fournir une n-ième version de ces paquets. Il reste aussi la possibilité de réaliser une compilation statique. Mais bon, étant donné que l'objectif est de se connecter localement (c'est-à-dire via l'interface de loopback), on peut tout aussi bien se passer de SSL et de ce problème ;-) Zou, c'est réglé ...


Troisième étape : compiler shellinabox après application des patchs "kivonbien"


On récupère la dernière version disponible sur Google Code :

$> svn checkout http://shellinabox.googlecode.com/svn/trunk/ shellinabox-svn
$> cd shellinabox-svn

On patch le fichier "vt100.js" (entre autres parceque la notion de "bouton droit" n'existe pas sous webOS) en se basant sur l'expérience d'un utilisateur de Reddit :

--- vt100.js.orig       2011-09-19 10:56:56.000000000 +0200
+++ vt100.js    2011-09-19 10:58:58.000000000 +0200
@@ -283,7 +283,7 @@
   this.visualBell           = typeof suppressAllAudio != 'undefined' &&
                               suppressAllAudio;
   this.autoprint            = true;
-  this.softKeyboard         = false;
+  this.softKeyboard         = true;
   this.blinkingCursor       = true;
   if (this.visualBell) {
     this.signature          = Math.floor(16807*this.signature + 1) %
@@ -1124,7 +1124,7 @@
 
 VT100.prototype.resizer = function() {
   // Hide onscreen soft keyboard
-  this.hideSoftKeyboard();
+  // this.hideSoftKeyboard();
 
   // The cursor can get corrupted if the print-preview is displayed in Firefox.
   // Recreating it, will repair it.

On configure pour ne supporter ni SSL ni PAM puis on compile :

$> ./configure --host=arm --disable-ssl --disable-pam 
$> make 

Voilà, il ne reste qu'à copier le fichier sur le TouchPad et à l'exécuter :

$> scp shellinaboxd root@192.168.33.201:
$> ssh root@192.168.33.201
NicolasHPTouchPad root # ./shellinaboxd -b --localhost-only

Vous pouvez désormais lancer accéder via le navigateur à http://127.0.0.1:4200/ (login = root, pas de mot de passe) :




Bon, il y a clairement des problèmes de mapping du clavier (typiquement, le "-" ne marche pas sur le clavier du TouchPad, il faut utiliser le clavier virtuel de l'application), mais ça permet d'avoir un shell minimaliste. Pour un usage au long cours, il faut lancer le binaire au démarrage de la tablette, par exemple en ajoutant une ligne "exec /path/to/shellinaboxd -b --localhost-only" à un script de démarrage quelconque comme celui d'OpenSSH. Pour les pressés et les téméraires qui veulent juste le binaire, il est était disponible ici.


Depuis la semaine dernière, une autre façon de disposer d'un shell local sous HP TouchPad est proposée. En effet, les feeds Stable de Preware ont vu débarquer le triplet gagnant Xecutah / Xserver / Xterm :




Que choisir entre shellinabox et xterm ? Le second est maintenu par la communauté et sera probablement régulièrement actualisé. Mais il a une empreinte système assez importante : environ 33 Mo de RAM et 6% de CPU en tâche de fond, contre 2 Mo et quasiment pas de CPU. Bien sûr, le serveur X sera mutualisé quand d'autres d'applis X tourneront sur la tablette. Autre point négatif pour xterm : les curseurs ne sont pas présents (argh !). Du coup, je fais tourner shellinabox en tâche de fond, avec lancement de xterm si le besoin s'en fait sentir. En tout cas, voilà le problème de l'accès local au Linux sous-jacent résolu !


Note finale : si quelqu'un veut produire une version packagée pour webOS (au format IPK) de shellinabox, je serais ravi ... et ce serait l'occasion de créer un script de démarrage dédié ;-)


Posted by Nicolas Grégoire | Permanent link | File under: touchpad

jeudi 15 septembre 2011, 14:20:20 (UTC+0200)

Failles de type XEE dans SharePoint et DotNetNuke

Microsoft vient de publier les bulletins de sécurité du mois de Septembre, dont MS11-074 concernant (entre autres) SharePoint 2007 et 2010. Je dis "entre autres" car les logiciels impactés par CVE-2011-1892 incluent aussi :

  • côté client : Office Groove 2007 et SharePoint Workspace 2010
  • côté serveur : Office Forms Server 2007, Office Groove (Data Bridge|Management) Server 2007, Office Groove Server 2010
  • côté "cloud" : Office Web Apps 2010

Il est à noter que SharePoint 2003 n'est pas vulnérable, car il n'inclut pas le composant Web Part vulnérable.


Pour les personnes ne pratiquant pas couramment SharePoint, un "Web Part" (parfois appelé "Web Widget" ou "Portlet") est un composant ASP.Net exécuté côté serveur et intégrable depuis un navigateur à toute page accessible en modification. Le composant "XML Web Part" prend en paramètre des données (sous forme XML) et du code de mise en page (sous forme XSL) et renvoie le code XHTML correspondant aux données formatées. Cela permet par exemple d'intégrer un fil Twitter à une page SharePoint, comme décrit ici.


Le problème est causé par les entités XML externes, qui n'étaient pas interdites dans les versions vulnérables. Cela permettait à n'importe quel utilisateur authentifié d'inclure le composant XML Web Part dans une page et de le configurer pour accéder en lecture (avec les droits du compte IIS AppPool) au système de fichiers.


Illustrons le problème avec une capture d'écran et quelques lignes de code. Le composant #2 se contente d'afficher des informations obtenues via "system-property", alors que le #1 (que nous allons détailler) exploite la vulnérabilité :




Côté XML, on définit un champ "doc" dont la valeur correspond à la variable "boom", c'est-à-dire au contenu du fichier déclaré dans le DTD :

<!DOCTYPE doc [
<!ENTITY boom SYSTEM "c:\\windows\\system32\\drivers\\etc\\hosts">
]>
<doc>&boom;</doc>

Et côté XSL, il suffit d'afficher la valeur du champ "doc" :

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
        <xsl:template match="/">
        <xsl:apply-templates/>
                <xsl:value-of select="doc"/>
        </xsl:template>
</xsl:stylesheet>

Les syntaxes "c:\\..." ainsi que "http://..." ou "file://..." fonctionnent.


Evidemment, le bug n'est pas limité aux seuls outils Microsoft. Les autres applications, qu'elles soient "maison" ou "sur étagère", peuvent elles aussi être impactées. Par exemple, DotNetNuke propose un module XML permettant d'afficher le résultat de transformations XSL. La version 06.00.00 de ce module corrige une vulnérabilité similaire à CVE-2011-1892 (d'ailleurs, le même PoC fonctionne). Pas d'advisory, pas de crédit, pas de mention explicite dans le ChangeLog :-( Merci DotNetNuke, je m'en souviendrais si je trouve d'autres vulns dans vos produits ...




Si on regarde le code-source de la version 04.03.05 du module XML de DotNetNUke, on y trouve une fonction XmlSource() (fichier "XmlController.vb") qui appelle XmlReader.Create() avec XmlReaderSettingsWithoutValidation() comme paramètre. Cette dernière fonction est définie comme suit dans "Utils.vbs" :

Dim settings As New XmlReaderSettings()
   settings.ProhibitDtd = False
   settings.ValidationType = ValidationType.None

La documentation Microsoft (System.Xml Security Considerations) est très claire :

XML data can include references to external resources such as a schema file. By default external
resources are resolved using an XmlUrlResolver object with no user credentials. This means that, by
default, you can access any locations that do not require credentials. You can secure this further by
doing one of the following:
- Restrict the resources that the XmlReader can access by setting the XmlReaderSettings::XmlResolver
property to an XmlSecureResolver object.
- Do not allow the XmlReader to open any external resources by setting the XmlReaderSettings::XmlResolver
property to null.

L'ajout à la fonction XmlReaderSettingsWithoutValidation() de la ligne "settings.XmlResolver = null" aurait du coup suffi à corriger le problème, mais les développeurs ont préféré passer à MSXML6, qui interdit par défaut l'utilisation de DTD et du coup bloque l'attaque.


Pour conclure :

  • les XEE ne sont pas morts, bien qu'ils aient été publiquement décrits il y a près de 10 ans. Rien que cette année, j'en ai trouvé 3 (Liferay, DotNetNuke, SharePoint) en analysant des wrappers autour de XSLT et Apple en a corrigé un dans servermgrd pour MacOS X Server. Sans oublier le papier de Kingcope (et oui, un XEE sous Java permet de lister le contenu des répertoires !)
  • même si l'impact se limite à une lecture de fichier, il existe de nombreux cas où cela peut suffire à compromettre pleinement une application, typiquement par obtention d'un fichier "web.config", "server.xml" ou équivalent

EDIT du 15 septembre 2011 à 14h20 : typos diverses, capture d'écran DotNetNuke, ...


Posted by Nicolas Grégoire | Permanent link | File under: vulnérabilités, xslt

webmaster@agarri.fr
Copyright 2010-2019 Agarri