This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fallout from dlopen() blocking SIGSYS


On Fri, Dec 6, 2019 at 3:40 AM Gian-Carlo Pascutto
<gpascutto@mozilla.com> wrote:
>
> On 4/12/2019 23:08, Rich Felker wrote:
> > The right solution probably involves using seccomp with a tracer
> > process, or if the dlopen calls are the only thing you need to
> > filter, interposing dlopen to prevent the nasty library from calling
> >  it.
>
> In the case of the EME/DRM modules, the use case is that we don't
> (necessarily) trust the (closed source, proprietary) module. It's
> shipped as a .so (currently, it really is libwidevinecdm.so), so we want
> to be sure that we only call dlopen() on it *when already inside* the
> sandbox. This in order to prevent some craftily written header (or
> STT_IFUNC shenanigans) from owning us.

To add to this: in the EME case, we have exactly one .so file, with
any dependencies pre-loaded; in this case the open/openat trap is
actually handled in-process by returning a pre-opened fd rather than
messaging a broker (for annoying reasons involving socketcall(2) and
SOCK_DGRAM, but also to minimize attack surface).

Which is to say that if we had something like FreeBSD's fdlopen(3), we
could just use it directly instead of doing seccomp tricks.

But even with fdlopen we'd still have the problem of content processes
using various dynamically/lazily loaded libraries (e.g., libavcodec
and its 38 transitive dependencies), and as previously discussed the
space of potential problems here is much larger than dlopen calling
open.  So that definitely wouldn't be a general-purpose fix, but I
thought it was worth mentioning.

--Jed


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]