[GTALUG] 'file' maintainer? (or fun with PIE and magic)
Sergio Durigan Junior
sergiodj at sergiodj.net
Wed Feb 7 14:54:14 EST 2018
Hey, Stewart,
On Wednesday, February 07 2018, Stewart C. Russell via talk wrote:
> Anyone know how to get in touch with the maintainers of 'file'? Seems
> the links in the man pages and Ian Darwin's site -
> http://www.darwinsys.com/file/ - don't work. The file magic database
> needs an update to correctly recognize PIE (Position Independent
> Executable) x86 ELF binaries as application/x-executable.
Unfortunately it seems that "file" is not "properly maintained" in the
sense that the project doesn't have a trivial way to receive
contributions. In this scenario, what I recommend is to file a bug
downstream (against Debian's "file", for example), and ask the
maintainer to forward the fix upstream.
> This might seem an incredibly trivial thing, but it effectively stops
> graphical file managers from executing binaries, as they use magic (5)
> to identify files. Debian switched to making PIE a default for gcc for
> security reasons, but probably didn't expect it to break graphical UIs.
>
> Here's what I'm seeing:
>
> Expected behaviour:
>
> $ echo "int main() { return 0; }" > foo.c
> $ gcc -o foo foo.c
> $ file foo
> foo: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
> dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for
> GNU/Linux 3.2.0, BuildID[sha1]=6e7749f995a89a53f74ec29d3c16fcf3f56be90f,
> not stripped
> $ file --mime-type foo
> foo: application/x-executable
>
> Actual behaviour:
>
> $ echo "int main() { return 0; }" > foo.c
> $ gcc -o foo foo.c
> $ file foo
> foo: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV),
> dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for
> GNU/Linux 3.2.0, BuildID[sha1]=6e7749f995a89a53f74ec29d3c16fcf3f56be90f,
> not stripped
> $ file --mime-type foo
> foo: application/x-sharedlib
This is expected, as you noted. The problem here is not only the magic
number, but the fact that the binary has its ELF e_type marked as
ET_DYN, and not ET_EXEC. This is proposital; GCC does that because it
is possible to create shared libraries that are also executables when
you use -pie.
It seems to me that perhaps the graphical UI could rely not only on the
MIME type of a file, but also if it is marked as executable or not.
Debian explicitly advises (in the form of a lintian error) against
having the executable bit set for libraries, so only executable files
will have +x.
> Workaround:
>
> $ echo "int main() { return 0; }" > foo.c
> $ gcc -o foo-nopie foo.c -no-pie
> $ file foo-nopie
> foo-nopie: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
> dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for
> GNU/Linux 3.2.0, BuildID[sha1]=3eb8c581f43c19997e3c828f5a9730dbdc794470,
> not stripped
> $ file --mime-type foo-nopie
> foo-nopie: application/x-executable
>
> I'm a bit worried that the workaround allows less safe binaries to be
> double-clicked and run. I'm not sure how much of a security issue PIE vs
> non-PIE is, though.
Yeah, this is not really a workaround per se, because it disables PIE
when compiling the binary. Having PIE enabled is a nice security
feature, so I would recommend against doing that.
--
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/
More information about the talk
mailing list