question regarding two security features

[Tom Henderson]

On 7/12/21 5:12 AM, Adhemerval Zanella wrote:
>
> On 07/07/2021 22:58, Tom Henderson wrote:
>> Hello, I'm writing with a question concerning whether two glibc security features could be optionally disabled for a specific use case.  The ns-3 network simulator has a framework called Direct Code Execution [1, 2] that has been around for about ten years.  DCE allows us to load and simulate multiple instances of C or C++ executables and libraries that have been compiled as position independent code.  We link these with the system glibc.  Starting after glibc-2.25 or so, some vtable verification checks were introduced, and later, some restrictions on opening PIE objects were added, which blocked our usage of the system glibc for subsequent Linux releases (newer than Ubuntu 16.04).  We have been holding back on upgrades since then because of this issue.
>>
>> Going forward, we can work around this by building a custom glibc (see sample patch at [3]) and using that within the DCE framework, but this approach is more heavyweight for users, so we are wondering if glibc would entertain the possibility of defining a link option to disable these features?
> Every configuration adds maintenance burden that we need take in consideration,
> there are some cases where some options has bit-rotten and needed fixing
> (--disable-shared for instance, BZ#20845).  And as fair as I am aware new options
> regarding security are opt-in, opt-out security issue are risky and usually
> used in very fringe cases.  Another options is we might provide a way to disable
> it through tunables, but even then it adds more surface where an attacker might
> find a easier way to just disable it.
>
> I have only skimmed through the paper, but I couldn't identify why exactly these
> two security features are preventing you to use you framework. If you could describe
> in more details what exactly is failing for newer glibcs we might come with ideas
> of how to make it work.

Thanks for replying; that paper doesn't get into the implementation 
details.  The only other online documentation that I know of is the DCE 
documentation here:

https://ns-3-dce.readthedocs.io/en/latest/how-it-works.html

but the better details are in a thesis that I can't find online right 
now.  Briefly, the issues are as follows:

DCE allows multiple instances of the same application to run in the 
simulator (itself a C++ process).  A good example application is the 
quagga routing suite (https://www.quagga.net) that provides routing 
protocol daemons.  DCE ensures that each instance does not share global 
and static variables, and overrides many system calls to redirect them 
to simulation-specific versions (e.g., so that 'gettimeofday' returns 
simulation time, not wall clock time).

The main technique used is to compile the application with -fPIC and 
link with -pie, and then to use either the system dlmopen() variant that 
supports the lmid namespaces argument, or a custom ELF dynamic loader 
[1].  Our ability to use the default dlmopen() seems to have been 
blocked by this patch:

https://patchwork.ozlabs.org/project/glibc/patch/20190312130235.8E82C89CE49C@oldenburg2.str.redhat.com/

The second issue is that DCE performs a vtable override [2] so that 
descriptors such as stdio are isolated and redirected. However, this has 
been blocked recently, and DCE returns the runtime error 'Fatal error: 
glibc detected an invalid stdio handle'.  Of course, there is a good 
reason to do this for avoiding FILE structure exploitation, but I 
thought I would ask whether anyone had an idea on how to bypass it for 
our use case without undoing the security hole it is designed to plug.

- Tom

[1] https://gitlab.com/nsnam/elf-loader

[2] 
https://github.com/direct-code-execution/ns-3-dce/blob/master/model/dce-stdio.cc#L184

[3] https://github.com/direct-code-execution/ns-3-dce/issues/57