From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14929 invoked by alias); 31 Jul 2014 18:09:10 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 14894 invoked by uid 89); 31 Jul 2014 18:09:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-wg0-f46.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=52Dtm58vWkEDZXYn5Ef3Om6+sSjhr9gfFUHbb9bh3yA=; b=m7lFhDzQjqDppsP15U7VU4MZj5SfhIDkO8ONbj/lotzsYF6mfdJIR+WXYlLHpvKoP9 SMTyK3ZhqGfZ0tAlCL+VOvQ3ZUaQXg/bqOQiR349EZh4lTOBMFTTy4V+PeR0IoQcNavF ZHGNZU1KEJUzYsszxEoDrabEcONrhGo7JfaMmNO7wt00aCGS6Ls5eWCeaJoif3NxK/RK rQ/u1Ccxl2z3klDwPgdflilH3+nzlPoKTJS/IT2VLLWt5gP/bEPQqkJj8+xO/XuZkQT9 BoK7ogmMoAlvoG3uLYkfPIAjFFy8orvsjEYVTPTYeB1EE+z0j6Nhvz5D6dr67huHGovC 12rw== X-Gm-Message-State: ALoCoQnQ960xX1MuEMC5WebwAVYouFFTFHXWf4TifthdOqqET2wzP3XMxJMjE5J0C5dyBZH2mPw3 X-Received: by 10.180.92.104 with SMTP id cl8mr65597wib.43.1406830141763; Thu, 31 Jul 2014 11:09:01 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <53D7F076.9010505@redhat.com> References: <53CD0F15.3030806@redhat.com> <20140728230221.66D7A2C3994@topped-with-meat.com> <53D73636.7060207@redhat.com> <53D7F076.9010505@redhat.com> From: Tavis Ormandy Date: Thu, 31 Jul 2014 18:09:00 -0000 Message-ID: Subject: Re: [PATCH] __gconv_translit_find: Actually append ".so" to module name [BZ #17187] To: Florian Weimer Cc: Roland McGrath , GNU C Library Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2014-07/txt/msg00590.txt.bz2 On Tue, Jul 29, 2014 at 12:05 PM, Florian Weimer wrote: > > > Ah, but only on 32-bit architectures, and not with 64-bit architectures > (without writing a couple of NULs), right? > > I totally I agree that this can be exploitable on 32-bit architectures. I > don't know why I disregarded them. *sigh* > > I'll ask for a CVE assignment on the oss-security list, and we should tre= at > this as a security vulnerability. Thanks for reporting this, Tavis. No problem. > I need to figure out all this, but I think these gconv modules are availa= ble > by other means, so fixing this shouldn't open up totally new exploit > vectors. Do you have an example? I looked into it and couldn't find a way of doing it. But I did spot a few additional bugs while I was looking. The code doesn't work to prevent traversal if slash_count goes too high, for example CHARSET=3D////../../../../../foo However, the path is passed through upstr() in gconv_charset.h. upstr() hardcodes the locale, so it doesn't seem possible to get lowercase alpha characters through to dlopen(). Nonetheless, this is still a *very* serious bug, if there is a directory that doesn't contain lowercase characters but is writable by an attacker, then this is a trivial root shell. To verify this, follow these steps: 1. Temporarily create a symlink to /tmp to simulate a directory without lowercase characters (numeric, uppercase, whitespace or special characters are fine). # ln -s /tmp /TMP 2. As an unprivileged user create a DSO with no lowercase characters in this directory. $ cat > test.c void __attribute__((constructor)) init(void) { printf("hello euid=3D%d\n", geteuid()); } $ gcc -w -fPIC -shared -o TEST test.c 3. Execute root as euid=3D0: $ CHARSET=3D///../../../../../tmp/test pkexec --version hello euid=3D0 Additionally, this path is parsed through expand_dst_tokens _after_ the upstr() call, so you can still insert DSTs (i.e. $PLATFORM, and so on). This gives the attacker some additional leeway, you can try CHARSET=3D////../../../${LIB}/${LIB}GL for example, which should expand to something like "/lib/libGL". $ORIGIN behaviour varies system-to-system. On Debian, it's just left as-is, but redhat modify the behaviour (see http://pkgs.fedoraproject.org/cgit/glibc.git/tree/glibc-fedora-elf-ORIGIN.p= atch). This results in some oddness that may make it exploitable without any path requirements, but I haven't thought through all the consequences yet (personally, I would drop that patch). I suspect this patch makes this exploitable by making it possible to open a DSO in a relative directory, but I need to think through the consequences a bit more. Additionally, the DST expansion looks like it's vulnerable to an integer overflow on 32-bit, perhaps not exploitable on Fedora where $PLATFORM and $LIB don't expand to very big strings, but on Debian $LIB is "x86_64-linux-gnu" which is a 4x increase. Obviously that wouldn't matter very much if you can't get a DST expanded by a setuid boundary, but there are at least a few where you can via gconv (sudo, pkexec, etc). > And the missing file extension doesn't matter for the dlopen call, > either=E2=80=94you still lose with the current code if the directory is > attacker-controlled for some reason. True, but isn't this why GCONV_PATH is in unsecvars? I.e. it's never supposed to be attacker controlled. Tavis.