Loading glibc in a new namespace fails vtable check

[Moshe Rubin]

Hi Florian,

Thank you for your prompt reply!  I have one last question (hopefully!).
You write:

>
> * 2. Why does my original test program *not* throw a fatal error? It is *>
> * also cross-mixing the libc with an inner fwrite() with an initial *>
> * "stderr"? Is this what you said is a bug? * It's currently possible to
> pass a stream from the initial libc to a
> secondary libc because vtable validation is disabled entirely for
> secondary libcs. I think I had plans to disable vtable validation for
> the initial libc once it calls dlmopen, but evidently, I have not
> implemented that.

If a stream (e.g., stderr) can be passed from an initial libc to a
secondary one, then why did my production app throw a fatal error?  I
was passing an initial stderr to a secondary function pointer which,
if I understand you, should have been just fine.  What does glibc
check for to prevent hacking, and how dod my app violate the terms?

Regards,

Moshe


On Sun, Sep 29, 2024 at 2:11 PM Florian Weimer <fweimer@redhat.com> wrote:

> * Moshe Rubin:
>
> > I tried to reuse your code, but do not have access to the "support"
> > folder, but was able to reproduce the crash:
>
> The support/ folder provides test helpers for glibc.  There is a way to
> use them outside of a glibc build:
>
>   Accelerate glibc test development with the glibc-support repository
>   <
> https://developers.redhat.com/articles/2024/08/27/accelerating-glibc-test-development-glibc-support-repository
> >
> > Three questions, if I may:
> >
> > 1. When you refer to inner and initial libc, is the default namespace
> > the "initial libc", while the second namespace (via dlmopen) is the
> > "inner libc"?  Is there a concept of inner and output libcs when
> > dlmopen is called?  Aren't the namespaces independent of each other,
> > acting in parallel to each other?
>
> The initial libc (the one that calls dlopen) is definitely different
> because ld.so uses its malloc, the libc malloc uses the brk system call,
> it can create threads, call exit, fork etc.  Functionality of secondary
> libcs loaded via dlmopen is more limited, many things just don't work
> (and crash), some functionality is disabled explicitly.
>
> > 2. Why does my original test program *not* throw a fatal error?  It is
> > also cross-mixing the libc with an inner fwrite() with an initial
> > "stderr"?  Is this what you said is a bug?
>
> It's currently possible to pass a stream from the initial libc to a
> secondary libc because vtable validation is disabled entirely for
> secondary libcs.  I think I had plans to disable vtable validation for
> the initial libc once it calls dlmopen, but evidently, I have not
> implemented that.
>
> > 3. If LIBC_SO is passed to dlmopen, is the function smart enough to
> > find the absolute path?  In my test code, I read "/proc/self/maps",
> > parsed it, etc.  Is such code unnecessary?
>
> Yes, LIBC_SO typically expands to "libc.so.6", and that's sufficient to
> locate the shared object.  Pretty much all binaries do not use a full
> path either, it's the same search mechanism.
>
> Thanks,
> Florian
>
>