[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