[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200127052857.GH2020@voyager>
Date: Mon, 27 Jan 2020 06:28:57 +0100
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Subject: Re: Bug report: Reproduction of seg fault caused by musl
thread creation race condition
On Sun, Jan 26, 2020 at 04:33:57PM -0800, Simon wrote:
> Hello! I recently had some C code which works normally with glibc but seg
> faults sometimes with musl. I managed to reproduce the seg fault via
> musl-gcc and Alpine Linux and document it here [1]. Seems to be some kind
> of race condition, so hopefully you guys also get a seg fault when you
> follow my reproduction steps. Hope this helps and looking forward to any
> feedback or helping further if possible, Simon
Race condition yes, but in your code. Until pthread_create() has
returned, you cannot be certain that it has stored the new thread's ID
into my_pthread, yet you access my_pthread from the new thread without
synchronization. What I presume is happening, is that the new thread
starts executing before the main thread has a chance to perform that
store. Glibc implements pthread_create() differently and somehow gets
around the problem at least most of the time.
Incidentally, that also means you are reading my_pthread from the other
thread while it is being written in the main thread. That is a data
race, and thus undefined behavior.
You could add a mutex or an rwlock around my_pthread, or a barrier after
the pthread_create() and before the first access in the new thread.
>
> P.S. musl newbie question: Why does my binary built on Alpine Linux report
> a .so being loaded by ldd, but on Ubuntu the same binary is reported as
> being static? Also, detail that here [1] too.
>
> [1] https://gist.github.com/simonhf/6d8097f4d6caa572cc42354f494b20ef
Not a clue, but I guess that Ubuntu's ldd tries to get around the
arbitrary code execution problem with ldd by detecting nonstandard
interpreters and refusing to use those. See, ldd has no way of actually
telling the entire set of needed shared libraries except to run the
dynamic interpreter on the file, but if the executable is malicious,
then the interpreter is attacker-controlled and might also be malicious.
That used to be a well-known social engineering trick. Just ring up your
sysadmin and tell them "Hey man, I have a binary XYZ here that says it
needs some shared lib. Can you help me?" Then the sysadmin runs ldd on
the binary and the dynamic interpreter runs with sysadmin privileges.
What could go wrong?
Ciao,
Markus
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
