Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.006 X-Spam-Evidence: '*H*': 0.99; '*S*': 0.00; 'subject:Python': 0.06; '64-bit': 0.07; 'bits': 0.09; 'pointers': 0.09; 'cc:addr:python- list': 0.11; '(char': 0.16; '(there': 0.16; '(unsigned': 0.16; '*),': 0.16; '4gb': 0.16; '6:00': 0.16; 'arithmetic)': 0.16; 'discarded': 0.16; 'from:addr:rosuav': 0.16; 'from:name:chris angelico': 0.16; 'happily': 0.16; 'int)': 0.16; 'sizeof': 0.16; 'subject:bit': 0.16; 'throw': 0.16; 'unlikely': 0.16; 'worst': 0.16; 'wrote:': 0.18; 'result.': 0.19; 'cc:addr:python.org': 0.22; 'integer': 0.24; 'platform,': 0.24; 'pointer': 0.24; 'cc:2**0': 0.24; '15,': 0.26; 'header:In-Reply-To:1': 0.27; 'correct': 0.29; 'converting': 0.30; 'message-id:@mail.gmail.com': 0.30; 'writes:': 0.31; 'quite': 0.32; 'subject:the': 0.34; "i'd": 0.34; 'problem.': 0.35; 'requirement': 0.35; 'but': 0.35; 'received:google.com': 0.35; 'doing': 0.36; 'wrong': 0.37; 'too': 0.37; 'two': 0.37; 'represent': 0.38; 'richard': 0.38; 'pm,': 0.38; 'even': 0.60; 'simply': 0.61; "you're": 0.61; 'happen': 0.63; 'more': 0.64; 'limit': 0.70; 'ethan': 0.84; 'furman': 0.84; 'cast': 0.91; 'write:': 0.91; 'to:none': 0.92; 'outcome': 0.93 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=4udUN/CeUdvaUALTokCixr0t3NhF5w9E5ua73qujGfQ=; b=DG1buCdvvNoCGFiozle7r0UJ6UD0RvyjNt8ANCZxO3+w/R6nJp63FFjBcYyMvu0yPd hsLkB+PDzJjOgyQOGAkuK4S3ipriK4afsBDeaQADeYzH163yEw/QV6/jB3weY43LwLiC Je0Wvu4Wsrojm15iBBKwPFjvZWE8mqgeCtujbuGq+IRQx0WNWPy1XP2jhU2f4yc/vUOy R58yiqfCoCoW62yE8WN+vG+vSGLZ9DPyYypglSmbvBZ7VCmEe7igou6jDn5tJdYoQWgE Kn02a9krvGGaH+r2dbDhcC1hR0yxcvBBKvoQ2yzUx5OJdyPFkkuRUDOpz0ngplmA/Ptz 29qg== MIME-Version: 1.0 X-Received: by 10.58.187.78 with SMTP id fq14mr163700vec.9.1397549711342; Tue, 15 Apr 2014 01:15:11 -0700 (PDT) In-Reply-To: References: Date: Tue, 15 Apr 2014 18:15:11 +1000 Subject: Re: Python, Linux, and the setuid bit From: Chris Angelico Cc: "python-list@python.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 31 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1397549720 news.xs4all.nl 2852 [2001:888:2000:d::a6]:51887 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:70255 On Tue, Apr 15, 2014 at 6:00 PM, Richard Kettlewell wrote: > Ethan Furman writes: >> memset(envp_write, 0, ((unsigned int) envp_read - >> (unsigned int) envp_write)); > > That is a remarkable blunder for a security-critical program. > > On a 64-bit platform, the best case outcome is that it will throw away > the top 32 bits of each pointer before doing the subtraction, yielding > the wrong answer if the discarded bits happen to differ. If the pointers are more than 4GB apart, then yes, it'll give the wrong answer - just as if you'd subtracted and then cast down to an integer too small for the result. But if they're two pointers inside the same object (already a requirement for pointer arithmetic) and not 4GB apart, then two's complement arithmetic will give the right result even if the discarded bits differ. So while you're correct in theory, in practice it's unlikely to actually be a problem. > (There is no limit to the worst case behavior; the effect of converting > a pointer value to an integer type which cannot represent the result is > undefined.) > > I would write: > > (envp_read - envp_write) * sizeof *envp_read I'd simply cast them to (char *), which will permit the arithmetic quite happily and look cleaner. ChrisA