Date: Tue, 1 Dec 2009 10:59:56 -0600 (CST) From: "Sean C. Farley" <scf@FreeBSD.org> To: Dan Lukes <dan@obluda.cz> Cc: freebsd security <freebsd-security@FreeBSD.org> Subject: Re: Upcoming FreeBSD Security Advisory Message-ID: <alpine.BSF.2.00.0912011047440.68765@thor.farley.org> In-Reply-To: <4B154635.2050209@obluda.cz> References: <200912010120.nB11Kjm9087476@freefall.freebsd.org> <ov3Jq1IJ/c8KAXGQ501G8Os9xr8@Ll2tHa60cb%2BhiG8R4R8/VS21128> <20091201111627.GC4920@borusse.borussiapark> <86skbuet3x.fsf@ds4.des.no> <4B154635.2050209@obluda.cz>
index | next in thread | previous in thread | raw e-mail
On Tue, 1 Dec 2009, Dan Lukes wrote:
> Dag-Erling Smørgrav napsal/wrote, On 12/01/09 14:12:
>> As to the second: yes, 6.1 is most likely affected.
>
> Probably no.
>
> The older algorithm used in 6.1 looks like
> -----------------
> if (trusted) {
> variable = getenv(NAME);
> ....
> -----------------
>
> The affected algorithm looks like:
> -----------------
> if (!trusted) {
> unsetenv(NAME);
> ...
> };
> variable = getenv(NAME);
> -----------------
>
> As far as I know such change has been MFCed into 6.3, 6.4, 7.x but not
> into 6.1. So 6.1 should not be affected by this bug (but remain
> vulnerable to problem that triggered the change of old algorithm to
> new).
That is correct. 6.x should not be affected. The security issue exists
with the combination of the getenv() to unsetenv() change in rtld.c and
the addition of the new env code. The unsetenv() in 6.x would not stop
if environ was corrupted.
Sean
--
scf@FreeBSD.org
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0912011047440.68765>