1373157 - 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)

Status: RESOLVED WORKSFORME

(Core :: Preferences: Backend, defect, P3)

Description

[Justin Ossevoort]

Attachment: 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

Comment 1

[Justin Ossevoort]

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

[:Gijs (he/him)]

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?

Comment 3

[Mike Hommey [:glandium]]

Environment variable?

Comment 4

[Jonathan Kew [:jfkthame]]

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.

Comment 5

[:Gijs (he/him)]

(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?

Comment 6

[Blake Kaplan (:mrbkap) (inactive)]

(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.

Comment 7

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

(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.

Comment 9

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

(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.

Comment 14

[Nicholas Nethercote [inactive]]

I have a plan and working draft code for this. The plan is to send the prefs data via shared memory. This will then let us get rid of the early/late prefs split (bug 1436911).

Comment 15

[Nicholas Nethercote [inactive]]

(In reply to Nicholas Nethercote [:njn] from comment #14)
> I have a plan and working draft code for this. The plan is to send the prefs
> data via shared memory. This will then let us get rid of the early/late
> prefs split (bug 1436911).

But I've decided I will do this in a separate bug: bug 1438678.

Comment 16

[Nicholas Nethercote [inactive]]

In the end, bug 1436863 fixed this, by changing things so that many fewer prefs are passed via the command line. If a user changes the network.IDN.blacklist_chars pref (hightly unlikely) then it'll come back; bug 1438678 will remove even that possibility.