Firefox content process shows weird characters in process listing (network.IDN.blacklist_chars - should encode content process command line arguments or use alternative means of sending them)

NEW
Unassigned

Status

()

Core
IPC
P3
normal
6 months ago
11 days ago

People

(Reporter: Justin Ossevoort, Unassigned)

Tracking

54 Branch
Points:
---

Firefox Tracking Flags

(firefox57 wontfix, firefox58 fix-optional, firefox59 affected)

Details

Attachments

(1 attachment)

(Reporter)

Description

6 months ago
Created attachment 8877922 [details]
Firefox content process weird characters screenshot from 2017-06-15 09-15-49.png

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0
Build ID: 20170612121707

Steps to reproduce:

Start firefox 54.0 and restored previous session

I use tab tree extension and thus have a lot of tabs open. Most are for our internal ticketing system and source control. One for microsoft project online, an empty tab and an 'about: support' page.


Actual results:

When I looked to see how many processes were running (because apparently Firefox 54.0 might use more than 1 content process) by running 'ps axf' it show the content process with a lot of weird characters in the process name:

      ¼½¾ǃː??։֊׃״؉؊٪۔܁܂܃܄ᅟᅠ᜵           ???‐’․‧??????? ‹›⁁⁄⁒ ⅓⅔⅕⅖⅗⅘⅙⅚?⅜⅝⅞⅟∕∶⎮╱⧶⧸⫻⫽⿰⿱⿲⿳⿴⿵⿶⿷⿸⿹⿺⿻ 。〔〕〳゠ㅤ㈝㈞㎮㎯㏆㏟꞉︔︕︿﹝﹞?./。ᅠ???�

(I don't know how good or bad they survive copy pasting)

Here is also a uuencoded compressed version of the command line, made using:

    $ xz -9 < /proc/9152/cmdline | uuencode -

To show the hex dump run something like:

    $ uudecode <<'EOF' | xz -d | xxd
    begin 664 -
    M_3=Z6%H```3FUK1&`@`A`1P````0SUC,X`8>`LY=`!>=2F=%D8:LSH_Z>JNM
    M)UPY*="+SU'J#D4UHU\X>ZR2B--WPK4R;)81Y[I3]$D>EHME&A<E2[*%_(4;
    MZU`,>XYS+$BHD@B)OVW0<L)%C_1^QP8ZA/(]?FR$'2<S`]K3338ZUC/N5JG2
    M5%`V^)I5'3_O_1'$G`7_/7Q^KN5&.^['M97X+-PLXJ%T'YAJ0K=#PU2]Q*<6
    M<;[Z9SC#VT:%6?\TVY0&E+(FVKDDP,BIU+)W4`L":X46K"S,!^+D)@LYH)\!
    MGH$^D-+)]L43X=P:AV?D=RS@F9D%2F6O!O)/GZTQZGPB!>I8TJE5%=$M9)9@
    M@]$;Z\(P*9\CG/`V<OBO6K;C72,WRB4#0<#.\Z]QG*@YY81P\'K"IC9<X%2]
    M&,6/:H*OMS08)$*XVJ$XDW9R%_7CDG[6JA0G,N;V)\);)Y"2N]0.OW2YUUA1
    MU*/?)W/0XLWH'399R%[)K1/T>Q>Q;=HLIA2M/.6!22E+(/4SERS(Z"N>HU0*
    M-([SVS0RJ"2WHD0#5I3-._-GAB1F]854W/C@W&XJR,G2KM(1%[UFI^_,%^<"
    MWE].P*$VM58)N&S(+%I7G9\E]O%`=%M&4H(%ZI<O8H7,9R`\S+DTL5$#/]2P
    M?$5!<,`W-C_'26KX`IUV!MCD;Q=\H=Q"6MR6#W<D/^1HO=S.5$6L6YL3D!MR
    M%^_QY?IQ6"FT`2==`[/"Z$AH'`5YS:Y0\JPNBR5O[*:WT55%$,-_:>6?7Q68
    M50XPC;OY4:,2U>)+F#U!A@)#CSFY3(0X)/;0#.1@IH[#C_^B_88=+>=63>ZH
    M>9]K["4\Y$BHV7ACW$=E5DX"E=OLZ(I$W,@8U.`@*ZU@'G:LIY4A]!V\'5WF
    MUDSA@E#]S6@MG[:/8T*D>/+;]XL0$60E`?1Z5J=Y>:XU2YRR2/(F`LY`'\UN
    M6G30`.$05&!T-94!0%0WON2K#@VDI41WJ8?[```````53S/H;>,>&0`!Z@6?
    3#```WVM34+'$9_L"``````196@``
    `
    end
    EOF

I don't know where the characters come from and if websites might have control over them.

The reason I'm flagging this as a possible security issue is: If a website is able to put arbitrary binary data in the process listing, than unix users who look at process listings might be open to weird bugs due to terminals interpreting some as control characters. It might be that 'ps' is guarded against this, but there are a lot of tools that do things with process listings.


Expected results:

No weird characters in the content process command line
(Reporter)

Comment 1

6 months ago
For completeness:
The project online tab was also pinned.
None of the pages have show anything close to those characters anywhere, but might have them in some resources they've loaded. The characters look kind of like a unicode character map.

Comment 2

6 months ago
From a quick look, these are 'string prefs' that we send to the content process. So they're the contents of prefs that we ship in via a commandline argument when starting the process. Specifically, it seems the current list of string preferences is approximately (list taken from mozilla-central / nightly, might be different in 54):

[ "media.volume_scale", "network.IDN.blacklist_chars", "network.IDN.restriction_profile", "security.sandbox.content.tempDirSuf…", "app.update.channel" ]

The gobbledygook blobs I assume is network.IDN.blacklist_chars.

None of these prefs are really content/user-controllable (except, kind of, media.volume_scale, which will contain a float represented as a string). So I don't think there's any security risk here, so I'm opening this up.

That said, I wonder if there's a better way to transfer this stuff that doesn't result in something quite as gobbledygook-y in the terminal... maybe we should encode the string prefs somehow?
Group: firefox-core-security
Component: Untriaged → IPC
Flags: needinfo?(jfkthame)
Product: Firefox → Core

Updated

6 months ago
Summary: Firefox content process shows weird characters in process listing → Firefox content process shows weird characters in process listing (network.IDN.blacklist_chars)
Environment variable?
Can't the content process just read the prefs directly?

Wow....looks like we actually have a huge list of prefs that we ship across to the content process in this way:

  https://dxr.mozilla.org/mozilla-central/source/dom/ipc/ContentPrefs.cpp#21-241

I don't know why we need to do that (maybe it's a performance thing?), but it seems ugly to me. Maybe someone who knows about the IPC stuff could clarify.
Flags: needinfo?(jfkthame)

Comment 5

6 months ago
(In reply to Jonathan Kew (:jfkthame) from comment #4)
> Can't the content process just read the prefs directly?
> 
> Wow....looks like we actually have a huge list of prefs that we ship across
> to the content process in this way:
> 
>  
> https://dxr.mozilla.org/mozilla-central/source/dom/ipc/ContentPrefs.cpp#21-
> 241
> 
> I don't know why we need to do that (maybe it's a performance thing?), but
> it seems ugly to me. Maybe someone who knows about the IPC stuff could
> clarify.

--> :mrbkap?
Flags: needinfo?(mrbkap)
(In reply to Jonathan Kew (:jfkthame) from comment #4)
> I don't know why we need to do that (maybe it's a performance thing?), but
> it seems ugly to me. Maybe someone who knows about the IPC stuff could
> clarify.

This is because we don't want to have to send synchronous messages on content process startup. During XPCOM startup, we read a bunch of prefs before a second (asynchronous) message could get from the parent to the child. Those pref values have to get to the child process somehow and we have relatively few mechanisms to do so. We do send the rest of the preferences in a more hidden fashion.

If this is enough of an annoyance, we could try to move the uses of the prefs with non-textual data out of the startup path or something more complex. I don't know who would do that, though.
Flags: needinfo?(mrbkap)
(In reply to Blake Kaplan (:mrbkap) from comment #6)
> If this is enough of an annoyance, we could try to move the uses of the
> prefs with non-textual data out of the startup path or something more
> complex. I don't know who would do that, though.

Storing the prefs in an environment variable, as comment #3 suggested, would stop them from adding clutter to process listings without changing how early in process startup they're available.

Updated

3 months ago
Duplicate of this bug: 1375979

Updated

3 months ago
Summary: Firefox content process shows weird characters in process listing (network.IDN.blacklist_chars) → Firefox content process shows weird characters in process listing (network.IDN.blacklist_chars - should encode content process command line arguments or use alternative means of sending them)

Updated

3 months ago
OS: Unspecified → Linux
Priority: -- → P3
Hardware: Unspecified → All
(In reply to Jed Davis [:jld] (⏰UTC-7) from comment #7)
> Storing the prefs in an environment variable, as comment #3 suggested, would
> stop them from adding clutter to process listings without changing how early
> in process startup they're available.

Doing this on Windows depends on bug 1257276, but we need to fix that for other reasons.
Duplicate of this bug: 1412348
Duplicate of this bug: 1359199
Duplicate of this bug: 1369184
Status: UNCONFIRMED → NEW
Ever confirmed: true
status-firefox57: --- → wontfix
status-firefox58: --- → fix-optional
status-firefox59: --- → affected
OS: Linux → All
Duplicate of this bug: 1421955
You need to log in before you can comment on or make changes to this bug.