libc.so.6 in project directory causes major problems

[m4b]

rustc --version
rustc 1.19.0-nightly (fe7227f6c 2017-06-16)
cargo --version
cargo 0.20.0-nightly (bbfe9b3a9 2017-06-05)

Steps to repro:

1. cp a libc.so.6 to your project directory
2. run cargo test or cargo build

This might require an older libc.so.6, or something; looks like something is trying dlopen the version in my directory (also, why?), and the ABI is bad for whatever reason (just guessing).

m4b@efrit ::  [ ~/git/panopticon ] cp libc.so.6 ~/projects/scroll
m4b@efrit ::  [ ~/git/panopticon ] cd
m4b@efrit ::  [ ~ ] cd projects/scroll
m4b@efrit ::  [ ~/projects/scroll ] cargo test
   Compiling scroll v0.6.0 (file:///home/m4b/projects/scroll)
rustc: error while loading shared libraries: __vdso_time: invalid mode for dlopen(): Invalid argument
error: Could not compile `scroll`.
Build failed, waiting for other jobs to finish...
rustc: error while loading shared libraries: __vdso_time: invalid mode for dlopen(): Invalid argument
error: Could not compile `scroll`.

To learn more, run the command again with --verbose.

Original issue: das-labor/panopticon#304

[metux]

Why does the compile dlopen() anything from the source tree ?
And why does anything dlopen() libc ?

[m4b]

I had similar questions 😆

I wonder if I could ship a libc in a crates.io crate with a rewritten stub to the function it's trying to open to do random stuff on some users computer.

[sfackler]

Do you have . in your LD_LIBRARY_PATH?

[sfackler]

It's not clear to me why the assumption is that this is coming from a dlopen call. Why couldn't it be ld.so? You can try setting LD_DEBUG=all to have the dynamic linker print out info about what it's doing.

[m4b]

No I do not have "." in my LD_LIBRARY.

To make this even easier, please copy your libc.so.6 to some new cargo project, open this new libc in your favorite hex editor, zero out the elf header, run cargo clean followed by cargo build and it will report that libc.so.6 has an invalid header...

[m4b]

I believe in this case it was assumed that dlopen was called because in the original report dlopen is explicitly mentioned as having a bad argument by rustc.

Of course it may be some side effect, etc. But on two separate machines I can repro this fairly worrisome issue (e.g. Local libc used without messing with LD env variables), which suggests that dlopen is used

[sfackler]

What does the output of cargo clean && env LD_DEBUG=libs cargo build say?

[m4b]

Ah I'm pretty sure this is caused by rustc using RPATH in dynamic array.

Also I think this might be a security vulnerability

EDIT:

Actually not sure. Except that it's a problem

[sfackler]

I do not see this behavior with a stock x86_64-unknown-linux-gnu 1.18 release, for reference.

        55:	find library=libc.so.6 [0]; searching
        55:	 search path=/usr/local/bin/../lib		(RPATH from file rustc)
        55:	  trying file=/usr/local/bin/../lib/libc.so.6
        55:	 search path=/tmp/foo/target/debug/deps/tls/x86_64:/tmp/foo/target/debug/deps/tls:/tmp/foo/target/debug/deps/x86_64:/tmp/foo/target/debug/deps		(LD_LIBRARY_PATH)
        55:	  trying file=/tmp/foo/target/debug/deps/tls/x86_64/libc.so.6
        55:	  trying file=/tmp/foo/target/debug/deps/tls/libc.so.6
        55:	  trying file=/tmp/foo/target/debug/deps/x86_64/libc.so.6
        55:	  trying file=/tmp/foo/target/debug/deps/libc.so.6
        55:	 search cache=/etc/ld.so.cache
        55:	  trying file=/lib64/libc.so.6

[m4b]

Something is setting LD path and it is not me. I believe it is cargo. Running strings on cargo shows that LD_LIB env variable is in the binary, and briefly grepping through source shows that it does collect a set of env variables, and LD_LIB is amongst them, which is even more worrisome.

Unfortunately not in front of a computer at the moment, so can't paste output but someone sets LD variable to the rustup nightly toolchain (amongst other things)

@sfackler are you not able to repro this ?

[m4b]

What about nightly cargo ?

[codyps]

% rustc -V
rustc 1.20.0-nightly (9475ae477 2017-07-11)
% cargo -V
cargo 0.21.0-nightly (eb6cf012a 2017-07-02)
% rustup -V
rustup 1.5.0
% env | grep LD_
[no output]
% cp /usr/lib/libSegFault.so libc.so.6
% cargo clean && env LD_DEBUG=libs cargo build
[...]
rustc: relocation error: libc.so.6: symbol getenv, version GLIBC_2.2.5 not defined in file libc.so.6 with link time reference
error: Could not compile `byteorder`.
[...]

And some output filtered to libc.so mentions:

      8694:	find library=libc.so.6 [0]; searching
      8694:	  trying file=/home/cody/g/vblock/target/debug/deps/libc.so.6
      8694:	  trying file=tls/x86_64/libc.so.6
      8694:	  trying file=tls/libc.so.6
      8694:	  trying file=x86_64/libc.so.6
      8694:	  trying file=libc.so.6

So it looks reproducible at least with rustup on nightly.

[m4b]

@sfackler could you paste entire output of LD_DEBUG=libs with and without libc.so.6 in project root directory ?