1322784 - Crash in libc-2.24.so@0xda657 (utime)

Status: RESOLVED FIXED

(Core :: Security: Process Sandboxing, defect)

Description

[Rok Garbas [:garbas]]

This bug was filed from the Socorro interface and is 
report bp-49304330-ed12-47f4-9444-027cd2161210.
=============================================================

Comment 1

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

$ grep -w $[0x84] /usr/include/asm/unistd_64.h
#define __NR_utime 132

I don't understand why GConf/ORBit would need to modify the filesystem to query the value of a configuration directive.

But, if the “stack” (really just the list of things found in stack memory that look like return addresses, because the crash dump processor doesn't have unwind info for the system libraries) is reasonably close to the truth, the underlying cause is something in content trying to use the nsProtocolProxyService.

And if I had to guess what in a content process would be trying to do that, it'd be WebRTC[1], because I've run into that before, but that doesn't actually show up in the crash so I could be wrong about that.

[1] http://searchfox.org/mozilla-central/rev/3e157ac240611f80df409ae76221d46a31c20dfc/media/webrtc/signaling/src/peerconnection/PeerConnectionMedia.cpp#295

Comment 2

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

On further inspection of the call stack, the thing using the proxy service looks like the NPAPI plugin host: http://searchfox.org/mozilla-central/source/dom/plugins/base/nsPluginHost.cpp#281

Comment 3

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

(In reply to Jed Davis [:jld] (⏰UTC-6) from comment #2)
> On further inspection of the call stack, the thing using the proxy service
> looks like the NPAPI plugin host:

This was fixed in bug 778201, but we're still seeing occasional crashes in utime via GConf/ORBit from WebRTC (bug 1325242).

Comment 4

[Rok Garbas [:garbas]]

I can confirm that this is not an issue for packaging Firefox nightly for NixOS anymore.
I can check (in next week) if this are any problem with WebRTC, since I'm using appear.in service quite a lot.

Comment 5

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

Attachment: Bug 1322784 - Gently fail utime(), to deal with GConf/ORBit.

Review commit: https://reviewboard.mozilla.org/r/144372/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/144372/

Comment 6

[Gian-Carlo Pascutto [:gcp]]

Comment on attachment 8872867 [details]
Bug 1322784 - Gently fail utime(), to deal with GConf/ORBit.

https://reviewboard.mozilla.org/r/144372/#review148804

Question still remains why it's doing this. Maybe to avoid re-reading config files for changes or something? I guess we can live with this given that it will end up being remoted.

Comment 7

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

For reference, this is from a function named giop_tmpdir_init in src/orb/GIOP/giop.c in the orbit2 source:

#if defined (HAVE_UTIME_H) && !defined (G_OS_WIN32)
                /* This seems pretty useless, forget it on Win32 */

                { /* Hide some information ( apparently ) */
                        struct utimbuf utb;
                        memset (&utb, 0, sizeof (utb));
                        utime (newname, &utb);
                }
#endif          

And there's something similar (minus the "pretty useless" comment, which was added several years later) in a function named make_local_tmpdir in linc2/src/linc-protocols.c

The git history goes back to a commit in 2001 that says only “copy from ORBit-stable”.

What it's actually doing (in both cases) is zeroing the mtime and atime on a newly created temporary directory.  I'm not sure what the point is of trying to conceal when the directory was created, but it also doesn't work, because it can't alter the ctime.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/fe87806bd7f4
Gently fail utime(), to deal with GConf/ORBit. r=gcp

Comment 9

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/fe87806bd7f4

Comment 10

[Ryan VanderMeulen [:RyanVM]]

Is this something that affects ESR52? I forgot what the status of sandboxing is there.

Comment 11

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

Thanks for checking.  It's not affected: this is specific to content sandboxing, and ESR52 has only media plugin sandboxing.  (Also, 53 and 54 were affected only as Nightly.)