Krdytkyu

I've discovered this yesterday, as it was generating system load on otherwise idle Ubuntu 14.04 Desktop machine.

Today, I've confirmed such behavior also on another Ubuntu instance (17.10 in Virtualbox VM)

The sub-process in command line looks like below ( I've put this as picture below intentionally to prevent askubuntu.com from changing/escaping the content )

For me it looks like exploit/malware. Or at least there is something to hide.

this happens even for url https://www.google.com/

This is related to multi-process feature of Firefox, go through the following official link.

https://support.mozilla.org/en-US/questions/1147868#answer-938004

There are many other Linux threads on this, with same output as you posted, all related to multi-process feature of Firefox.

Recent versions of Firefox are running multi-process instead of a single process.

The multi-process is applicable to all Firefox users since Firefox 54 was debuted in June 2017. The Multiprocess Firefox documentation describes that Firefox run the browser UI in a separate process from web content. As a result, users may see the "suspicious subprocess" in process list.

Many end users seem to be concerned with the cryptic part of the subprocess, as raised in this forum on mozillaZine and this forum thread on Mozilla Support; just too many to be quoted here.

Direct answers

For me it looks like exploit/malware (Is the subprocess malicious?)

No, recent versions of Firefox behaviour is like that.

Or at least there is something to hide (Is there something to hide?)

No. End users may see differently than what developers see; very few users may have noticed that there is nothing hidden.

How can be sure

There are two reasons that we can be sure:

1. The fact that the developers do not bother to explain the detail of the subprocess, is the reason we can be sure that is not malicious. At least, I have not found such detail to this date.




2. This partial answer by TT Farreo at Stack Overflow in late-2017 has hinted that the cryptic part of subprocess is related to the list of blacklisted characters by Mozilla.

From the partial answer at Stack Overflow:

The list of weird looking characters seems to correspond to the blacklisted characters listed in http://kb.mozillazine.org/Network.IDN.blacklist_chars [...]

Now we can make sense of the strange characters:

• See those fraction characters? Checked.


• See those binary block characters? Checked.


• See those invisible spaces? Checked.


• See the squished unit of radian thingy? Checked.


• See the question mark in black diamond character? Checked.

The answer at Stack Overflow has also included a link to the source code of content process used by Firefox. End users usually would not dive into that much detail, which is why this answer at Ask Ubuntu would be good enough as it is.

The subprocess is normal, that is all matters.

I noticed the same thing last night and I started inspecting it with xxd. My best guess would have been that this is a way of communicating pointers to shared resources or identifying themselves (adjacent virtual locations and constant length would cause periodicity) but a few things convinced me otherwise.

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

I trimmed up to the preceding newline (and left it, 0a, at the end.) I aligned it based only on the repetition, that's 12 bytes per line up to the partial 25th line. The reason I spaced the bytes the way I did was to show that there are (what look like) UTF8 continuations (the table at the bottom.) However, it's worth mentioning that following the convention of an established and well-known encoding offers the same benefit: you can represent large values but keep small ones compact. On the other hand, for some reason they appear to be stringing together ? and only bytes greater than 80. The next section of that Wikipedia page shows that there are printable characters within this range, but fewer and farther between. I don't believe the goal had anything to do with composing very wide UTF8 characters, but instead, it's as if they were avoiding the more universally-printable characters in the ASCII set. At this point the best I can come up with is that they knew they would have to encode and embed strings of arbitrary length, namely 'stringPrefs', and maybe opted to use high bytes sandwiched by low bytes just made it easier to extract. As far as I can tell, the ? serve as both delimiters and padding.

I'm not satisfied, but I don't have much more to offer. For my benefit, I started to replace the most common characters and it's a little easier to see what's going on:

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

I see a lot more structure than I could expect of encrypted and encoded strings, unless this is some kind of steganography. If anyone can take the baton, I'd be grateful, and not just because I'm curious - I'd like to know earlier than later if there's anything worth hiding in there.