1517144 - [Linux] Running firefox from command line in an invalid directory causes all instances to crash.

Status: RESOLVED WORKSFORME

(Core :: Widget: Gtk, defect, P5)

Description

[Scott Marshall]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:66.0) Gecko/20100101 Firefox/66.0

Steps to reproduce:

Run firefox from desktop or command line. Doesn't matter.   Open a command line (in my case I use KDE/kconsole.  make a temporary directory, and cd into it.   Open a second command line and delete the temp directory you created.    Go back to the previous command line (which now has invalid CWD (current working directory)  and attempt to run firefox from the command line. 



Actual results:

All firefox instances crash and a dialog comes up asking to report it.


Expected results:

A new instance of firefox should have opened up without crashing the others?

Comment 1

[Sylvestre Ledru [:Sylvestre]]

Could you please share your crash id ?
(you will find it in about:crashes)
thanks

Comment 2

[Scott Marshall]

Made a new one. I didn't report the original.  Here is the link:   https://crash-stats.mozilla.com/report/index/40c42612-b35e-45b6-bba2-dc2ca0190102

Comment 3

[Sylvestre Ledru [:Sylvestre]]

The interesting part of the stacktrace is:
1 libxul.so	nsXRemoteService::HandleNewProperty(unsigned long, _XDisplay*, unsigned long, unsigned long, nsIWeakReference*)	toolkit/components/remote/nsXRemoteService.cpp:140
2 libxul.so	nsGTKRemoteService::HandlePropertyChange(_GtkWidget*, _GdkEventProperty*, nsIWeakReference*)	toolkit/components/remote/nsGTKRemoteService.cpp:109 

Martin, rings a bell ? thanks

Moving as a potential security issue, socorro says:
 interesting - This is super sensitive data! Be careful how you use it!

Comment 4

[Martin Stránský [:stransky] (ni? me)]

Sure, I'll look at it, but I guess the crash is pretty much expected in this case - it least I experienced that with various command line tools before.

Comment 5

[Martin Stránský [:stransky] (ni? me)]

I was seeing it before with different apps but can't reproduce it now on my recent up-to date system (Fedora 29 / glibc-2.28-26). I see those lines instead of the crash:

$ firefox -P t1
shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
ERROR: error getting working directory name: no such file or directory
shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory

Comment 6

[Martin Stránský [:stransky] (ni? me)]

Scott, can you reproduce that it other applications or is that Firefox only?

Comment 7

[Al Billings [:abillings - ex-MoCo]]

This doesn't seem to be an exploitable security issue.

Comment 8

[Martin Stránský [:stransky] (ni? me)]

I got a feedback from Scott by mail:

> just tried creating a new profile and did the same test.  It did what it
> should have. Complained about bad CWD and exit.  No crash.  So an Addon is
> causing the issue.  If this satisfies you/others that its not a firefox
> issue but an addon causing it, feel free to close the issue.   I'll still
> get the full backtrace with debugging in a little bit.  Been busy all day
> watching my stepdad while mom does her grocery shopping. I'm about to head
> into dinner so I'll work on it an hour give or take.

And there's the backtrace from Scott (a related part):

Thread 1 (Thread 0x7f6639fb9740 (LWP 3892)):
#0  0x00007f663a11b715 in __strlen_avx2 () at /usr/lib/libc.so.6
#1  0x00007f6631d085f9 in nsRemoteService::HandleCommandLine(char const*, nsIDOMWindow*, unsigned int) () at /opt/firefox-nightly/libxul.so
#2  0x00007f6631d09003 in nsXRemoteService::HandleNewProperty(unsigned long, _XDisplay*, unsigned long, unsigned long, nsIWeakReference*) () at /opt/firefox-nightly/libxul.so
#3  0x00007f6631d0805c in nsGTKRemoteService::HandlePropertyChange(_GtkWidget*, _GdkEventProperty*, nsIWeakReference*) () at /opt/firefox-nightly/libxul.so

the related code is:

  int32_t argc = TO_LITTLE_ENDIAN32(*reinterpret_cast<const int32_t*>(aBuffer));
  const char *wd   = aBuffer + ((argc + 1) * sizeof(int32_t));

  nsCOMPtr<nsIFile> lf;
  nsresult rv = NS_NewNativeLocalFile(nsDependentCString(wd), true,
                                      getter_AddRefs(lf));

where nsDependentCString(wd) calls __strlen_avx2 on wd and we get wd (working directory) as a part of XRemote command. So we get a malformed XRemote command which causes the strlen crash.

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

Closing because no crashes reported for 12 weeks.