Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!goblin2!goblin.stu.neva.ru!newsfeed1.swip.net!uio.no!news.tele.dk!news.tele.dk!small.news.tele.dk!newsgate.cistron.nl!newsgate.news.xs4all.nl!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.001 X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; 'syntax': 0.04; 'subject:Python': 0.06; 'expressions': 0.07; 'see:': 0.07; 'identifier': 0.09; 'received:209.85.219': 0.09; 'skip:2 30': 0.09; 'subject:using': 0.09; 'way:': 0.09; 'win64': 0.09; 'url:blog': 0.10; 'python': 0.11; '"a"': 0.16; 'after,': 0.16; 'empty.': 0.16; 'identifiers,': 0.16; 'literals.': 0.16; 'merely': 0.16; 'of)': 0.16; 'variable.': 0.16; 'prevent': 0.16; 'wrote:': 0.18; 'wed,': 0.18; 'trying': 0.19; 'example': 0.22; 'to:name :python-list@python.org': 0.22; "aren't": 0.24; 'exists': 0.24; "shouldn't": 0.24; 'subject: .': 0.24; 'looks': 0.24; '(or': 0.24; 'environment': 0.24; 'compiled': 0.26; 'least': 0.26; 'values': 0.27; 'header:In-Reply-To:1': 0.27; 'chris': 0.29; 'thus': 0.29; 'errors': 0.30; 'message-id:@mail.gmail.com': 0.30; "i'm": 0.30; 'code': 0.31; 'serve': 0.31; 'accidentally': 0.31; 'crash': 0.31; 'ok.': 0.31; 'piece': 0.31; 'probably': 0.32; 'text': 0.33; 'are:': 0.33; 'received:209.85': 0.35; 'test': 0.35; 'received:google.com': 0.35; 'add': 0.35; 'there': 0.35; 'really': 0.36; 'done': 0.36; 'possible': 0.36; 'example,': 0.37; 'received:209': 0.37; 'skip:& 10': 0.38; 'nov': 0.38; 'to:addr :python-list': 0.38; 'files': 0.38; 'pm,': 0.38; 'anything': 0.39; 'ability': 0.39; 'subject:[': 0.39; 'embedded': 0.39; 'sure': 0.39; 'to:addr:python.org': 0.39; 'even': 0.60; 'catch': 0.60; 'hope': 0.61; 'simple': 0.61; "you're": 0.61; 'making': 0.63; 'therefore,': 0.64; 'safe': 0.72; 'batchelder': 0.84; 'whitelist': 0.84; 'examine': 0.93; '2013': 0.98 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:content-type; bh=KHhu+sNyxdfj6n62SB3cnPTSNQRAJ2djYhTlKbY637E=; b=RrWE3Odd/ueSfeIcMdsOzvUHEFbhUU8C5RdFydI4KNP1a4wtW0feYNMBjzvCKb6/oU 60eM+eamvd+bKD0qv1IV6Tpw5QgQPenB+IC2T/zW2keZ0ZhflmoQR3Xv1nvP30rwYBsR sIBDXMiVagP+tEmaI2qANoa4plaNHNzIUVUrKvPoxNx6TcjI3Esckycz/4WiVih+Z+j2 dLhtfoqPUGp9Y4DDagqrqGOODlmW5YEMF9j5SxgjYREwTX/p4zy6UwITOuDHk7MJbTgX UUyczURW3Mcph2MN7izkGFAs8wUr9L4t+KjzWsiXHAPuImbV2VsSQ8NGDLVrSXGBWlr6 bSDA== X-Gm-Message-State: ALoCoQlOJZfZzXgkaFoS8tuppR0d5+ZytVmtHWU8gH5SuME/8zOmmmmWQlHzeqCs1b8yTGTAKa8l X-Received: by 10.182.84.132 with SMTP id z4mr12571680oby.49.1385585066978; Wed, 27 Nov 2013 12:44:26 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <6cdefe87-5703-4caf-91c0-b4a02674a1e5@googlegroups.com> From: Chris Kaynor Date: Wed, 27 Nov 2013 12:44:06 -0800 Subject: Re: '_[1]' in .co_names using builtin compile() in Python 2.6 To: "python-list@python.org" Content-Type: multipart/alternative; boundary=089e0111c09ab9455004ec2ea9cb 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: 86 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1385585077 news.xs4all.nl 15968 [2001:888:2000:d::a6]:42464 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:60637 --089e0111c09ab9455004ec2ea9cb Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 27, 2013 at 12:09 PM, Ned Batchelder wrote: > * Is there perhaps a better way to achieve what I'm trying to do? >> >> What I'm really after, is to check that python expressions embedded in >> text files are: >> - well behaved (no syntax errors etc) >> - don't accidentally access anything it shouldn't >> - I serve them with the values they need on execution >> > > I hope you aren't trying to prevent malice this way: you cannot examine a > piece of Python code to prove that it's safe to execute. For an extreme > example, see: Eval Really Is Dangerous: http://nedbatchelder.com/blog/ > 201206/eval_really_is_dangerous.html > > In your environment it looks like you have a whitelist of identifiers, so > you're probably ok. I just tested the crash example from that link in Python 2.7.5 win64 and the co_names from the compiled code is empty. Therefore, a simple whitelist would not catch that problematic code (and likely any other global access done correctly). Even a simple test of making sure that at least one (or any number of) valid identifier exists would be insufficent, as you can merely tack on a ",a" to add "a" to the co_names, and thus for any other variable. Basically, even with a pure whitelist, there is likely no possible way to make eval/exec safe, unless you also eliminate the ability to make literals. Chris --089e0111c09ab9455004ec2ea9cb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On W= ed, Nov 27, 2013 at 12:09 PM, Ned Batchelder <ned@nedbatchelder.com> wrote:
* Is there perhaps a better way to achieve what I'm trying to do?

What I'm really after, is to check that python expressions embedded in = text files are:
- well behaved (no syntax errors etc)
- don't accidentally access anything it shouldn't
- I serve them with the values they need on execution

I hope you aren't trying to prevent malice this way: you cannot examine= a piece of Python code to prove that it's safe to execute. =A0For an e= xtreme example, see: Eval Really Is Dangerous: http:/= /nedbatchelder.com/blog/201206/eval_really_is_dangerous.html<= /a>

In your environment it looks like you have a whitelist of identifiers, so y= ou're probably ok.

I just tested the crash exampl= e from that link in Python 2.7.5 win64 and the co_names from the compiled c= ode is empty. Therefore, a simple whitelist would not catch that problemati= c code (and likely any other global access done correctly). Even a simple t= est of making sure that at least one (or any number of) valid identifier ex= ists would be insufficent, as you can merely tack on a ",a" to ad= d "a" to the co_names, and thus for any other variable.

Basically, = even with a pure whitelist, there is likely no possible way to make eval/ex= ec safe, unless you also eliminate the ability to make literals.

Chris
--089e0111c09ab9455004ec2ea9cb--