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