Re: Wheezy update of chicken?

[Brian May <bam@debian.org>]

Brian May <bam@debian.org> writes:

> I just had a look at CVE-2016-6830.
>
> https://security-tracker.debian.org/tracker/CVE-2016-6830
>
> refers to:
>
> http://lists.nongnu.org/archive/html/chicken-announce/2016-08/msg00001.html

I checked this again.

Now refers to
https://lists.nongnu.org/archive/html/chicken-hackers/2016-07/txtSWHYeFeG0R.txt

Other references:

https://bugs.debian.org/834845
https://bugs.call-cc.org/ticket/1308

"This fixes bug #1308 found by wasamasa.  It turns out that we don't
check the number of arguments or the number of env entries before trying
to write them to the target string. [...], this patch replaces the static
buffer with a dynamically allocated string [...].

[...]

"This new version also fixes a memory leak which would be
triggered when the arg or env list contained non-string objects
or embedded NULs, or when the exec itself would fail."

Ok, this makes more sense. My guess is that the wheezy version is
vulnerable here, as it has the static buffers which the patch removes.

static C_TLS char *C_exec_args[ ARG_MAX ];
static C_TLS char *C_exec_env[ ENV_MAX ];

The upstream solution however appears to be "Most C code in these
procedures was rewritten to Scheme." which is perhaps more involved then
we would like for a simple security fix. This patch does not apply
cleanly to wheezy.

I think a better solution for the immediate security issue might be to
check the lengths ourselves and ???? if is too long.

Fixing this might require somebody with a bit more knowledge of scheme,
in particular C bindings. I imagine the following macros might be a good
starting point however.

#define C_set_exec_arg(i, a, len)       C_set_arg_string(C_exec_args, i, a, len)
#define C_set_exec_env(i, a, len)       C_set_arg_string(C_exec_env, i, a, len)
-- 
Brian May <bam@debian.org>