Sous-processus suspect de Firefox (il s’est avéré que le comportement FF était légitime)
Je l'ai découvert hier, car il générait une charge système sur une machine de bureau Ubuntu 14.04 inactive, sinon.
Aujourd'hui, j'ai confirmé ce comportement également sur une autre instance Ubuntu (17.10 dans Virtualbox VM)
Le sous-processus en ligne de commande ressemble à celui ci-dessous (je l'ai mis comme image ci-dessous intentionnellement pour empêcher askubuntu.com de changer/d'échapper au contenu)
Pour moi, cela ressemble à exploit/malware. Ou du moins, il y a quelque chose à cacher.
cela se produit même pour les URL https://www.google.com/
Ceci est lié à la fonctionnalité multi-processus de Firefox, suivez le lien officiel suivant.
https://support.mozilla.org/en-US/questions/1147868#answer-938004
Il existe de nombreux autres threads Linux à ce sujet, avec le même résultat que vous avez posté, tous liés à la fonctionnalité multi-processus de Firefox.
Les versions récentes de Firefox exécutent plusieurs processus au lieu d’un seul processus.
Le multi-processus est applicable à tous les utilisateurs de Firefox depuis Firefox 54 a été lancé en juin 2017 . La documentation Multiprocess Firefox indique que Firefox exécute l'interface utilisateur du navigateur dans un processus distinct du contenu Web. Par conséquent, les utilisateurs peuvent voir le "sous-processus suspect" dans la liste des processus.
De nombreux utilisateurs finaux semblent s'intéresser à la partie cryptique du sous-processus, telle qu'elle est évoquée dans ce forum sur mozillaZine et ce fil de discussion sur le support Mozilla ; juste trop pour être cité ici.
Réponses directes
Pour moi, cela ressemble à exploit/malware (le sous-processus est-il malveillant?)
Non, les versions récentes du comportement de Firefox sont comme ça.
Ou du moins, il y a quelque chose à cacher (y a-t-il quelque chose à cacher?)
Non. Les utilisateurs finaux peuvent voir les choses différemment de ce que les développeurs voient. très peu d'utilisateurs ont peut-être remarqué qu'il n'y a rien de caché.
Comment peut être sûr
Il y a deux raisons pour lesquelles nous pouvons être sûrs:
Le fait que les développeurs ne se donnent pas la peine d'expliquer les détails du sous-processus est la raison pour laquelle nous pouvons être sûrs que ce n'est pas malveillant. Au moins, je n'ai pas trouvé de tels détails à cette date.
Cette réponse partielle de TT Farreo au débordement de pile à la fin de 2017 a laissé entendre que la partie cryptique du sous-processus est liée à la liste des caractères en liste noire de Mozilla.
De la réponse partielle à Stack Overflow:
La liste des caractères étranges semble correspondre aux caractères de la liste noire répertoriés dans http://kb.mozillazine.org/Network.IDN.blacklist_chars [...]
Maintenant, nous pouvons donner un sens aux personnages étranges:
- Voir ces caractères de fraction? Vérifié.
- Voir ces caractères de bloc binaires? Vérifié.
- Voir ces espaces invisibles? Vérifié.
- Voir l'unité écrasée de radian thingy? Vérifié.
- Voir le point d'interrogation en caractère de diamant noir? Vérifié.
La réponse chez Stack Overflow a également inclus un lien vers le processus de code source du contenu utilisé par Firefox. Les utilisateurs finaux n’apprécieraient généralement pas autant de détails, c’est pourquoi la réponse proposée à Ask Ubuntu serait suffisante.
Le sous-processus est normal, c'est tout ce qui compte.
J'ai remarqué la même chose la nuit dernière et j'ai commencé à l'inspecter avec xxd. Ma meilleure hypothèse aurait été qu'il s'agissait d'un moyen de communiquer des pointeurs sur des ressources partagées ou de s'identifier (des emplacements virtuels adjacents et une longueur constante causeraient une périodicité), mais certaines choses m'ont convaincu du contraire.
c783 cb90 3f3f d689 d68a d783
d7b4 d889 d88a d9aa db94 dc81
dc82 dc83 dc84 e185 9fe1 85a0
e19c b5e2 8080 e280 81e2 8082
e280 83e2 8084 e280 85e2 8086
e280 87e2 8088 e280 89e2 808a
3f3f 3fe2 8090 e280 99e2 80a4
e280 a73f 3f3f 3f3f 3f3f e280
afe2 80b9 e280 bae2 8181 e281
84e2 8192 e281 9fe2 8593 e285
94e2 8595 e285 96e2 8597 e285
98e2 8599 e285 9a3f e285 9ce2
859d e285 9ee2 859f e288 95e2
88b6 e28e aee2 95b1 e2a7 b6e2
a7b8 e2ab bbe2 abbd e2bf b0e2
bfb1 e2bf b2e2 bfb3 e2bf b4e2
bfb5 e2bf b6e2 bfb7 e2bf b8e2
bfb9 e2bf bae2 bfbb e380 80e3
8082 e380 94e3 8095 e380 b3e3
82a0 e385 a4e3 889d e388 9ee3
8eae e38e afe3 8f86 e38f 9fea
9e89 efb8 94ef b895 efb8 bfef
b99d efb9 9e3f efbc 8eef bc8f
efbd a1ef bea0 3f3f 3fef bfbc
efbf bd0a
J'ai coupé jusqu'à la nouvelle ligne précédente (et l'ai laissée, 0a, à la fin.) Je l'ai alignée en fonction de la répétition, c'est-à-dire 12 octets par ligne jusqu'à la 25e ligne partielle. La raison pour laquelle j'ai espacé les octets comme je l'ai fait, c'est pour montrer qu'il y a (à quoi ça ressemble) continuations UTF8 (le tableau en bas.) Cependant, il convient de mentionner que suivre la convention d'un Un encodage bien connu offre le même avantage: vous pouvez représenter des valeurs importantes tout en conservant des valeurs réduites. D'autre part, pour une raison quelconque, ils semblent enchaîner ? et uniquement des octets supérieurs à 80. La section suivante de cette page Wikipedia indique qu'il existe des caractères imprimables dans cette plage, mais moins nombreux et plus éloignés les uns des autres. Je ne crois pas que l'objectif ait été lié à la composition de caractères UTF8 très larges, mais au contraire, c'est comme s'ils évitaient les caractères plus universellement imprimables du jeu ASCII. À ce stade, le mieux que je puisse dire, c'est qu'ils savaient qu'ils devraient encoder et incorporer des chaînes de longueur arbitraire, à savoir 'stringPrefs', et ils auraient peut-être opté pour l'utilisation d'octets hauts pris en sandwich par des octets bas, ce qui facilite l'extraction. Autant que je sache, les ? servent à la fois de délimiteurs et de bourrages.
Je ne suis pas satisfait, mais je n'ai pas beaucoup plus à offrir. Pour ma part, j'ai commencé à remplacer les personnages les plus courants et il est un peu plus facile de voir ce qui se passe:
c783 cb90 d689 d68a d783
d7b4 d889 d88a d9aa db94 dc81
dc82 dc83 dc84 e185 9fe1 85a0
e19c b5++ ---- ++-- 81++ --82
++-- 83++ --84 ++-- 85++ --86
++-- 87++ --88 ++-- 89++ --8a
++ --90 ++-- 99++ --a4
++-- a7 ++--
af++ --b9 ++-- ba++ 8181 ++81
84++ 8192 ++81 9f++ 8593 ++85
94++ 8595 ++85 96++ 8597 ++85
98++ 8599 ++85 9a ++85 9c++
859d ++85 9e++ 859f ++88 95++
88b6 ++8e ae++ 95b1 ++a7 b6++
a7b8 ++ab bb++ abbd ++bf b0++
bfb1 ++bf b2++ bfb3 ++bf b4++
bfb5 ++bf b6++ bfb7 ++bf b8++
bfb9 ++bf ba++ bfbb e3-- --e3
--82 e3-- 94e3 --95 e3-- b3e3
82a0 e385 a4e3 889d e388 9ee3
8eae e38e afe3 8f86 e38f 9fea
9e89 efb8 94ef b895 efb8 bfef
b99d efb9 9e efbc 8eef bc8f
efbd a1ef bea0 ef bfbc
efbf bd0a
Je vois beaucoup plus de structure que ce que je pouvais attendre de chaînes cryptées et encodées, à moins qu'il ne s'agisse d'une sorte de stéganographie. Si quelqu'un peut prendre le relais, je lui en serai reconnaissant, et pas seulement parce que je suis curieux - j'aimerais savoir plus tôt s'il y a quelque chose qui vaut la peine se cacher là-bas.