Some tweaks for MPR#7557

[damiendoligez]

For the first commit, @setharnold pointed out in 38e2cd6#commitcomment-22736369 that secure_getenv is a "relatively new" addition to glibc (introduced in 2012 with glibc 2.17). This PR adds a fall-back to __secure_getenv, which dates back (at least) to 2002 with glibc 2.2.5.

references:

• https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=708061 -- shows that __secure_getenv was in glibc 2.2.5
• https://sourceware.org/glibc/wiki/Glibc%20Timeline -- glibc release timeline

The second commit secures one more call to getenv in the Spacetime code. Although you'd be crazy to set the setuid bit on a program compiled with instrumentation, I think it's better to fix this potential vulnerability (reported privately by Eric Milliken).

The third commit is a change in the manual to warn users against setting the setuid bit on a custom-mode bytecode executable because this configuration is always vulnerable to privilege escalation attacks.

[damiendoligez]

@lefessan @dra27 @mshinwell @lpw25 @avsm @stedolan @alainfrisch @gasche
quick review?

[lefessan]

What's the possible escalation with custom runtimes ? Why can't it be fixed ?

…

On Tue, Jun 27, 2017 at 2:45 PM Damien Doligez ***@***.***> wrote: @lefessan <https://github.com/lefessan> @dra27 <https://github.com/dra27> @mshinwell <https://github.com/mshinwell> @lpw25 <https://github.com/lpw25> @avsm <https://github.com/avsm> @stedolan <https://github.com/stedolan> @alainfrisch <https://github.com/alainfrisch> @gasche <https://github.com/gasche> quick review? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1213 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAfbjULB_7D7etnccaM4bk5bhuBHRZTcks5sIPlLgaJpZM4OFbdX> .

[damiendoligez]

@lefessan
I'm not sure it should be discussed publicly yet, and I don't think it can be fixed in a reliable way.

[mshinwell]

OK

[xavierleroy]

The double quotes around "setuid" causes this word to be typeset in \tt font. This is probably not what you want. Consider ``setuid'' instead. Likewise for setgid.

[damiendoligez]

Actually that's what I wanted but you're right, it's probably not a good idea.

[xavierleroy]

Looks good to me.

[avsm]

I've tested this on a CentOS 6 container and confirmed that __secure_getenv is found and used.

# docker run -it ocaml/opam:centos-6_ocaml-4.04.2
$ ldd --version
ldd (GNU libc) 2.12
$ git clone git://github.com/damiendoligez/ocaml -b more-secure-getenv
$ cd ocaml
$ ./configure
Configuring OCaml version 4.05.0+dev10-2017-06-23
Configuring for host x86_64-unknown-linux-gnu ...
Configuring for target x86_64-unknown-linux-gnu ...
Using compiler gcc.
Compiler family and version: gcc-4-4.
The C compiler is ISO C99 compliant.
Checking the sizes of integers and pointers...
Wow! A 64 bit architecture!
This is a little-endian architecture.
Doubles can be word-aligned.
64-bit integers can be word-aligned.
ranlib found
#! appears to work in shell scripts.
POSIX signal handling found.
expm1(), log1p(), hypot(), copysign() found.
getrusage() found.
times() found.
__secure_getenv() found.
termcap functions found (with libraries '-lcurses')
You have BSD sockets.

[dra27]

FWIW, I'd define HAS_SECURE_GETENV a la HAS_NANOSECOND_STAT (so either #define HAS_SECURE_GETENV secure_getenv or #define HAS_SECURE_GETENV __secure_getenv as appropriate) just to avoid a triple underscore. I appreciate that having tried to add a PR with some vast number of backslashes in a row, I may be guilty of being a pot here...

However, it all looks good to me, even with a triple underscore!

[stedolan]

The second commit secures one more call to getenv in the Spacetime code. Although you'd be crazy to set the setuid bit on a program compiled with instrumentation, I think it's better to fix this potential vulnerability (reported privately by Eric Milliken).

It's probably worth doing the same in byterun/afl.c (Same logic applies as Spacetime: you'd be crazy to setuid an instrumented binary, and it's hard to get useful data out of afl-fuzz traces, but it's still worth fixing)

[stedolan]

It is considered unsafe because the programmer of a setuid or setgid program must be careful to prevent execution of arbitrary commands through manipulation of the environment variables.

I think this message is not scary enough! Preventing direct execution of arbitrary commands is not enough: the usual attacks are more subtle things like attacker-controlled filenames or temporary directories. I'd suggest:

It is considered unsafe because the programmer of a setuid or setgid program must be careful to avoid using maliciously crafted environment variables in the search path for executables, the locations for temporary files or logs, and the like.

[damiendoligez]

@dra27 I don't really like the idea of a HAS_ macro being anything else than a boolean...

[dra27]

@damiendoligez - otherlibs/unix/nanosecond_stat.h? While talking about types in the C pre-processor is, um, interesting, surely the boolean bit is that it is defined and the value it is defined as (if it has one) in an optional extra?

[damiendoligez]

@dra27 Just because it exists in the system doesn't mean I have to like it. In any case, it's too small of a difference to justify the (small) amount of work to change it. (And I still think it's better as it is now.)

[damiendoligez]

@stedolan Done for AFL and also for GC instrumentation, just in case.

[hannesm]

this patch looks fine to me. Will the default runtime in 4.05 still have this cplugin "feature" enabled? I read through MPR 7557 and found some discussion about enabling/disabling it, but couldn't find any decision.

[damiendoligez]

@hannesm It will because I'm trying to release today. Let's have a relaxed discussion (in a new PR!) about disabling it for 4.06, but I don't want to delay 4.05.0 yet again.

[damiendoligez]

merged to 4.05 and cherry-picked to trunk (fee0110)