Suite à mon article au titre agressif "A l'avenir, Linux et Firefox seront-ils plus sensible que Windows/IE au logiciel malveillant." (http://linuxfr.org/~syj/23365.html ), le débat qui s'en est suivi me permet de tirer une conclusion en dehors du débat " Linux Vs Windows ".
Un système sécurisé doit contrôler les droits des utilisateurs exécutant des programmes
mais il doit aussi restreindre le nombre de point où un logiciel malveillant pourrait s'installer afin de limiter ce qu'on pourrait appeler "la zone d'accroche".
C'est à dire les zones où il pourrait s'assurer d'être lancer régulièrement.
L'idéal est que celle ci soit restreinte mais que çà structure permette de la contrôler de manière automatique.
D'un manière général, les scripts étant simple à corrompre agrandisse cette zone. C'est pourquoi l'architecture de Firefox dangereuse à l'avenir car elle agrandit énormément cette zone.
De plus et pour finir, le danger des scripts est la facilité à générer et régénérer automatiquement leur code. Ce qui rend la mise en place de contrôle par empreinte du code inopérant ou très difficile.
Journal Un système véritablement sécurisé devrait...
22
déc.
2006
# Mouai
Posté par nats . Évalué à 4.
Il aussi trés simple de le faire avec un binaire et le résultat est sans doute plus convaincant et plus chiant à traiter. Faut pas s'enteter sur les script, parce que rien qu'a vu d'oeil tu peux savoir si il est "louche".
Pour firefox c'est l'éternel débat (troll ?) de la fonctionnalité et de la sécurité...
Moi j'arrête pour ce débat.
[^] # Re: Mouai
Posté par syj . Évalué à -2.
ils pourront rentrer rapidement dans une base de virus.
Dernier point, il est plus difficile à ma connaissance pour un programme de patcher un autre programme sous forme binaire afin de s'injecter dedans.
[^] # Re: Mouai
Posté par Krunch (site web personnel) . Évalué à 2.
> un autre programme sous forme binaire afin de s'injecter dedans.
Pas vraiment non. Pour un être humain c'est effectivement plus difficile mais pour un programme ça revient au même.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Mouai
Posté par Alex . Évalué à 1.
man ptrace
CreateRemoteThread & consors sous win si ma mémoire est bonne
cest un peu chiant mais vraiment pas difficile à mettre en oeuvre, mais il éxiste également des moyens de s'en proteger : PaX, ptrace sur soit-même et surement d'autres.
[^] # Re: Mouai
Posté par syj . Évalué à -2.
L'appel-système ptrace fournit au processus parent un moyen de contrôler l'exécution d'un autre processus et d'éditer son image mémoire. L'utilisation primordiale de cette fonction est l'implémentation de points d'arrêt pour le débugging.
donc çà ne marche pas.
Vous êtes serieux quand vous soutenez qu'il est plus simple de modifier un binaire de manière automatique que dinserer un morceau de script dans un script !
J'hallucine ! les c0wb0yz !
[^] # Re: Mouai
Posté par M . Évalué à 3.
Si tu lisais la suite du man, tu trouverais surement les fonctions qui vont bien (PTRACE_POKE*, PTRACE_SETREGS, ...).
Vous êtes serieux quand vous soutenez qu'il est plus simple de modifier un binaire de manière automatique que dinserer un morceau de script dans un script !
Pour les binnaires elf, il existe une modif triviale : tu édites la chaine décrivant le loader (/lib/ld-linux.so.2) et tu le fais pointer vers ton loader perso (dans lequel tu peux faire ce que tu _veux_)...
Ca revient dans un script a changer la ligne decrivant le parseur (celle qui commence par #!).
PS : Au lieu de troller, mets y un peu du tien en recherchant des infos pertinentes sur le net.
[^] # Re: Mouai
Posté par syj . Évalué à 0.
Même si c'est simple pour toi. Je sais ce qui est simple pour moi.
Manipuler un programme sous la forme d'une chaine de caractères et l'executer avec un eval(...) . C'est à ma portée donc à priori à la portée de plein personne qui s'étime bien supérieur à moi au vu de leur langage.
Cette facilité et cette difficulté à identifier, ce type de menace est quand même la chose que je soutiens depuis le début de cette longue discussion.
Toutefois, tu m'expliqueras comment tu peux faire varier l'empreinte de ton loader qui sera probablement le point d'identification pour les antivirus.
Enfin quid de la portabilité du code sur d'autre système ,une infection sous forme de script se moque du type de loader, de gestion des librairies dynamique ou du type du système d'exploitation tant qu'elle a accès à l'essentiel.
Ce qui la rend beaucoup plus attractifs
[^] # Re: Mouai
Posté par nats . Évalué à 2.
Non plus serieusement les vrais dangers viennent d'exploits qui se passent de l'interface chaise clavier et en script ca parait peu probable.
[^] # Re: Mouai
Posté par Alex . Évalué à 1.
???
n'est ce pas éxactement ce qu'on veut, ou j'ai pas compris ?
Il n'a pas dit que c'était plus facile, il a dit que pour un programme (binaire éxecutable ou script) ça revenait au même.
[^] # Re: Mouai
Posté par syj . Évalué à -1.
ref à ma réponse au-dessus.
# rbac
Posté par Alex . Évalué à 2.
[^] # Re: rbac
Posté par syj . Évalué à 1.
[^] # Re: rbac
Posté par Alex . Évalué à 3.
mais en fait je pensais surement a des mac ( mandatory access control http://fr.wikipedia.org/wiki/Mandatory_access_control )
en simplifiant, c'est un système de rôle pour les process (ou fichiers, ou utilisateurs, mais dans notre cas cest les process qui interesse), un rôle permet d'affecter certains droits : par exemple de dire "mon firefox ne peut pas binder de ports, acceder uniquement au port 80, et ne pas écrire sur le fs en dehors de /dev/null"
bon en pratique c'est (très) chiant a mettre en place, mais certaines distribs tel gentoo ou fedora implémentent des profils par défaut pour leurs outils serveurs
[^] # Re: rbac
Posté par syj . Évalué à 1.
çà pourrait régler une partie des problèmes pour Firefox.
Par contre pour les autres scripts qui sont executé par un programme tel que bash ou une autre machine virtuel. La gestion des droits d'accès est plus difficile à mettre en oeuvre.
Merci pour cet info.
[^] # Re: rbac
Posté par syj . Évalué à 1.
gradm2 - Administration program for the grsecurity2 RBAC based ACL system
Il va falloir que j'essaie.
http://www.grsecurity.net/
[^] # Re: rbac
Posté par Alex . Évalué à 1.
tout le prob est dans la conf qui est inchiable à faire :
( http://www.grsecurity.net/gracldoc.pdf )
et l'outil de learning par defaut n'est pas encore au point
Mais cela reste faisable meme pour des scripts, tu peux "aisément" leur faire une sandbox et leur interdire de binder de ports, ou encore avoir un shell permissif pour les programmes sur, et un autre plus secure
le gros prob est qu'il faudrait d'en l'idéal faire du cas pas cas
# Pour un ordinateur plus sûr
Posté par Nicolas Schoonbroodt . Évalué à 4.
[^] # Re: Pour un ordinateur plus sûr
Posté par jms . Évalué à 2.
[^] # Re: Pour un ordinateur plus sûr
Posté par Etre-ange . Évalué à 3.
# l'architecture de Firefox dangereuse
Posté par Paul Rouget . Évalué à 1.
Ho ho, j'aimerais bien voir comment tu vas faire ça.
Pffff... cette histoire de script, n'importe quoi. Utiliser un script au démarage, la majorité des soft sous Linux le font: .vimrc, .bashrc, .xsession, les fichiers de conf de Gnome, certainement de KDE... Ne pensons qu'au script .bashrc, comment veux tu prétéger ça ? Ne pas donner les droits aux utilisateurs ?
[^] # Re: l'architecture de Firefox dangereuse
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
À mon avis, il parle de paladium et cie... Bref, il ne sait pas que finalement ça existe déjà, et que ça débarque pour de bon dans Vista.
[^] # Re: l'architecture de Firefox dangereuse
Posté par syj . Évalué à 1.
[^] # Re: l'architecture de Firefox dangereuse
Posté par Obsidian . Évalué à 2.
[^] # Re: l'architecture de Firefox dangereuse
Posté par syj . Évalué à 1.
Fournir à l'utilisateur avertie la possibilité de scripter tout, c'est bien mais je cherche à souligner les problèmes que çà souleve d'un point de vue sécurité.
Je me repete mes sous Windows, il existe des outils pour identifier les programmes qui seront executé au démarrage.
Tu peux pas lancer un script à partir d'un service.
[^] # Re: l'architecture de Firefox dangereuse
Posté par Anonyme . Évalué à 3.
Sauf qu'ils ne marchent pas. Enfin, il est tres simple de creer un programme qui sera execute a chaque demarrage, mais qui ne sera pas liste par cet outil.
Faut vraiment etre naif pour penser qu'un outil va pouvoir te permettre de lister absolument tous les programmes executes au cours du demarrage.
[^] # Re: l'architecture de Firefox dangereuse
Posté par syj . Évalué à 0.
C'est sur que si tu les considères comme admin. Là, il n'y a pas soucis pour eux.
Mais sous Windows, comme sous Linux, tu peux te limiter au compte user.
C'est pourquoi, je suggère qu'il faut penser un système de manière à limiter ces points d'ancrage et de les rendre analysable simplement.
Au moin au niveau de l'utilisateur, une fois qu'un programme a des droits système, il peut partir du principe qu'il peut faire ce qu'il veut et même se cacher des outils de detections.
[^] # Re: l'architecture de Firefox dangereuse
Posté par moo2 . Évalué à 0.
De mémoire (ça fait longtemps que j'ai pas touché à ça) il existait un script batch sous windows utilisé à chaques démarrages. En plus de ça il y a la belle base de registre qui te permet facilement de remplacer un des programmes que tu lance par défaut par un autre ... bref sur ce point Linux et Windows (et bien d'autres je suppose) même combat.
Maintenant ce qu'il faudrait compendre c'est que si un programme a le droit d'écrire a ces emplacements alors le programme lancé depuis ce script a les mêmes droits. Ca ne concernera donc que l'utilisateur qui a lancé le programme en question (bon ok c'est jamais agréable de perdre tous ses fichiers). Bon après que peut faire un tel script du spam ? La majorité des utilisateurs n'ont pas de MTA configuré correctement. Un DOS ? tu as une floppé d'utilitaire de surveillance de réseau. Un keyloggeur ? Ben le seul moyen de l'empecher c'est d'interdir à un programme lancé en utilisateur d'avoir les XEvents ... ça va pas aider Linux à être user-friendly.
Perso je suis derrière un routeur, avec le javascript activé seulement quand je veux, pas de java, et j'utilise un compte gmail. Non je ne suis pas parano, c'est juste que j'en ai besoin, que je n'aime pas la pub, que java sapusailentmaissailibre, et gmail pour le filtre à spam.
Ce que tu crois être un problème n'en est pas. C'est comme dans la vie tu as une part de risque en sortant dans un parc. Ben la c'est pareil quand tu lance n'importe quel programme tu as une part de risque. Bon après en te baladant dans certains coins à certaines heures tu prends plus de risques c'est un choix à faire sans ça tu fini comme ceux qui passe leurs journées devant le JT. Chez eux enfermé a double tours sans jamais voir personne et en n'utilisant aucun objet dont tu ne connais pas la provenance.
[^] # Re: l'architecture de Firefox dangereuse
Posté par syj . Évalué à 1.
>n'utilisant aucun objet dont tu ne connais pas la provenance.
Je ne dis pas qu'il faut rien faire.
Je dis juste qu'il faut envisager ce type de problème et modifier nos habitudes pour limiter ce type de problème à l'avenir.
Sur certain système, ce type de changement est déjà anticipé:
- Limite l'accès au cron pour les utilisateurs
- Blocage de l'édition de .bashrc et des autres scripts lancé au démarrage.
- écraser régulierement les fichiers de Firefox de l'utilisateur pouvant contenir un virus.
Tu vas pas me dire que c'est monstrueux et bloquant comme securité.
[^] # Re: l'architecture de Firefox dangereuse
Posté par z a . Évalué à 2.
tant qu'à faire, virer cron, pas vrai ?
« - Blocage de l'édition de .bashrc et des autres scripts lancé au démarrage. »
c'est quoi l'interêt du .bashrc alors ?
(d'ailleurs moi on peut pas m'y mettre de virus, j'utilise pas bash :p )
« - écraser régulierement les fichiers de Firefox de l'utilisateur pouvant contenir un virus. »
idem que pour le bashrc, personne ne t'empêche te mettre ton /home en lecture seule (ça revient au même qu'écraser les fichiers souvent)
petit malin d'essayer d'enterrer l'autre journal où tu racontes tant de merde, çuilà est pareil en fait
[^] # Re: l'architecture de Firefox dangereuse
Posté par syj . Évalué à 0.
Non, serieux, j'ai déjà vu des distribs où c'était configuré par défaut de cette manière.
> c'est quoi l'interêt du .bashrc alors ?
Mon .bashrc, je dois le modifier qu'une fois ou deux fois après la création de mon compte.
Je vois pas beaucoup non plus l'interêt de le laisser en écriture
> "personne ne t'empêche te mettre ton /home en lecture seule (ça
> revient au même qu'écraser les fichiers souvent)
Pas tout à fait, tu le reconnaitras. Au même titre que les cookies, tu peux avoir plusieurs attitudes les refuser, les supprimer à chaque redemarrage ou les laisser en permanences.
Je dois reconnaitres que je ne sais pas si Firefox réecrit souvent prefs.js ?
> petit malin d'essayer d'enterrer l'autre journal où tu racontes tant de
> merde, çuilà est pareil en fait
Etre grossier ou impoli ne comble pas un manque d'argument.
[^] # Re: l'architecture de Firefox dangereuse
Posté par z a . Évalué à 2.
[^] # Re: l'architecture de Firefox dangereuse
Posté par moo2 . Évalué à 2.
Après je serais curieux de savoir quels sont ces système où il n'y a pas de cron/at pour l'utilisateur. A mon avis c'est pas un soucis de sécurité mais plutôt un manque de config de base. Avec ça, ton problème reste le même en quoi un programme qui se lance X fois est plus dangereux qu'un prog ne se lançant qu'une fois ? (Je rappel que un crontab en utilisateur lance le programme avec l'uid de l'utilisateur)
Je suis d'accord que firefox est une porte ouverte si tu veux installer un programme malveillant sur l'ordi d'un autre, mais je pense que c'est un point commun à tout les navigateurs web supportant des technologie, ou des formats permettant l'execution de code depuis la machine cliente.
Il n'y a pas de bonne manière de bloquer ça (si tu vire le Js de tout le web les marketeux vont avoir du mal à vendre leur AAX ouaibeuh 2.0)
Enfin bref perso si je voulais placer une backdoor chez des gens je la placerai discretement dans un programme libre. Tu place le paquet dans des repo tenu par les communautés. Et après plus qu'à attendre, les paquets seront installé en root eux, c'est quand même plus intéressant.
Après ça reste le même problème pourquoi je modifierais mes habitudes puisque je ne vois pas vraiment le problème. La seule chose que je craigne vraiment c'est qu'on efface mes fichiers. Et je fais des backups.
# ouarf
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
booo le fud..
Dis moi, de quoi tu parles ? les scripts de quoi ? Ceux dans le chrome ? hors chrome ? greasemonkey ?
[^] # Re: ouarf
Posté par syj . Évalué à 1.
Il suffit que tu ais une fois un programme qui t'infecte un de ces scripts en exploitant une faille ou une erreur de ta part pour que tu ais peu de chance de t'en appercevoir un de ces jours ...
Et tu seras d'accord avec moi que dans un ces fichiers là, tu es en dehors de la sandbox des javascript de Firefox donc tu peux faire quasiment tout ce que l'utilisateur peut faire :)
[^] # Re: ouarf
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 5.
Dans ce cas, là, c'est pareil pour tout les programmes qui utilisent pour beaucoup des scripts, sans parler des scripts php ruby, python des applis web etc... Tu en a plein des programmes basés sur des scripts.
Et bien souvent, y a même pas à modifier les scripts, les fichiers de conf suffisent. Par exemple, modifier le fichier bookmarks.xml de Konqueror en remplacant toutes les urls sites de banques par celles de sites frauduleux... Du pishing discret quoi..
Ou alors modifier les fichiers de conf de tels ou tels programmes pour installer discretos des plugins, extensions acceptés par ces programmes etc...
Et tout ça, tu peux le faire sur n'importe quel os.
Bref, Je vois pas pourquoi taper sur linux et firefox en particulier.
M'enfin si on t'écoutait, il ne faudrait plus utiliser sa bécane quoi...
[^] # Re: ouarf
Posté par syj . Évalué à 1.
Principe des virus exploitait des failles phpBB. Il était à ma connaissance jamais root mais il faisait quand même énormement de degat.
> M'enfin si on t'écoutait, il ne faudrait plus utiliser sa bécane quoi...
Tout ceux qui sont passer d'un système avec droit d'admin par défaut à un système avec droit utilisateur restreint. Ce font la même reflexion.
[^] # Re: ouarf
Posté par Mathieu Pillard (site web personnel) . Évalué à 2.
De mémoire prefs.js n'est pas éxecuté en tant que JavaScript classique, il est juste parsé comme un fichier de conf, i.e. il ne peut que assigner des variables. Je n'ai pas plus d'infos parceque ca remonte à loin, il faudrait quelqu'un touchant au code de gecko pour répondre, toujours de mémoire je crois que c'etait pour des raisons de perfs et de sécu, justement.
[^] # Re: ouarf
Posté par Paul Rouget . Évalué à 1.
Il n'empêche qu'il y a d'autres solutions pour exécuter du code au démarage (générer une extension dans le profil par exemple).
[^] # Re: ouarf
Posté par syj . Évalué à 0.
# Souplesse / sécurité
Posté par Aurélien Bompard (site web personnel) . Évalué à 4.
[^] # Re: Souplesse / sécurité
Posté par briaeros007 . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.