806830 - WebRTC possible data race with strlib_copy vs strlib_empty

Status: RESOLVED FIXED

(Core :: WebRTC: Signaling, defect)

Description

[Christoph Diehl [:posidron]]

Attachment: callstack

media/webrtc/signaling/src/sipcc/core/src-common/string_lib.c:104
if ((temp->refcount < 0xffff) && (str != empty_str)) {
        temp->refcount++;
}

media/webrtc/signaling/src/sipcc/core/src-common/string_lib.c:374
        empty_str = strlib_malloc("", LEN_UNKNOWN, __FILE__, __LINE__);
        temp = STR_TO_STRUCT(empty_str);
        temp->refcount = 0xffff;

Marked as s-s because memory functions are involved, please downgrade if necessary.

Tested with m-c changeset: 111684:e19e170d2f6d

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

This looks like it's real unless we mandate that strlib_empty() is called during init, which is probably the best way to solve it.

Comment 2

[Daniel Veditz [:dveditz]]

sec-moderate on the (possibly erroneous) assumption arranging such a race reliably enough to exploit would be hard.

Comment 3

[Randell Jesup [:jesup] (needinfo me)]

Analysis is that strlib_empty() is called in the init of the signaling GSMTask:
GSMTask()->fsm_init->fsmdef_init_dcb->strlib_empty
GSMTask is started from thread_init(), which is called from ccInit() (initializing all of SipCC)

Since this will occur before any other uses of it, the mandate I mention above is already occurring, though not on purpose.

I'll add a patch that explicitly inits it, however there's no security risk with the current code, imo.

As there's no risk, removing sec-moderate (dan, if this is wrong please let me know).

Comment 4

[Randell Jesup [:jesup] (needinfo me)]

Attachment: Enforce initializing strlib before using

Comment 5

[Ethan Hugg [:ehugg]]

Comment on attachment 680412 [details] [diff] [review]
Enforce initializing strlib before using

Review of attachment 680412 [details] [diff] [review]:
-----------------------------------------------------------------

This should work.

Comment 6

[Randell Jesup [:jesup] (needinfo me)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/b123de2b4109

All as unaffected as there's no actual security risk here

Comment 7

[Ryan VanderMeulen [:RyanVM]]

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

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Christoph, have you had any testcase for it?

Comment 9

[Christoph Diehl [:posidron]]

Nope sorry, I was using the examples of the landing page and run https://developer.mozilla.org/en-US/docs/Thread_Sanitizer