From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: charles@aurox.ch (Charles A. Roelli) Newsgroups: gmane.emacs.bugs Subject: bug#28350: enriched.el code execution Date: Sat, 09 Sep 2017 17:57:10 +0200 Message-ID: References: <837exb1bk5.fsf@gnu.org> <838thovvcr.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1504972711 4096 195.159.176.226 (9 Sep 2017 15:58:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 9 Sep 2017 15:58:31 +0000 (UTC) Cc: 28350@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Sep 09 17:58:23 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dqi92-0008MD-Ac for geb-bug-gnu-emacs@m.gmane.org; Sat, 09 Sep 2017 17:58:08 +0200 Original-Received: from localhost ([::1]:50003 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dqi99-0005jV-EN for geb-bug-gnu-emacs@m.gmane.org; Sat, 09 Sep 2017 11:58:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34904) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dqi91-0005i0-IA for bug-gnu-emacs@gnu.org; Sat, 09 Sep 2017 11:58:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dqi8w-00023x-MJ for bug-gnu-emacs@gnu.org; Sat, 09 Sep 2017 11:58:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:49005) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dqi8w-00023E-IW for bug-gnu-emacs@gnu.org; Sat, 09 Sep 2017 11:58:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dqi8w-0000XP-2x for bug-gnu-emacs@gnu.org; Sat, 09 Sep 2017 11:58:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: charles@aurox.ch (Charles A. Roelli) Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 09 Sep 2017 15:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28350 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: security Original-Received: via spool by 28350-submit@debbugs.gnu.org id=B28350.15049726602032 (code B ref 28350); Sat, 09 Sep 2017 15:58:02 +0000 Original-Received: (at 28350) by debbugs.gnu.org; 9 Sep 2017 15:57:40 +0000 Original-Received: from localhost ([127.0.0.1]:57685 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dqi8Z-0000Wi-PC for submit@debbugs.gnu.org; Sat, 09 Sep 2017 11:57:39 -0400 Original-Received: from sinyavsky.aurox.ch ([37.35.109.145]:54793) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dqi8X-0000WS-M5 for 28350@debbugs.gnu.org; Sat, 09 Sep 2017 11:57:38 -0400 Original-Received: from sinyavsky.aurox.ch (sinyavsky.aurox.ch [127.0.0.1]) by sinyavsky.aurox.ch (Postfix) with ESMTP id 7FA4022532 for <28350@debbugs.gnu.org>; Sat, 9 Sep 2017 15:51:21 +0000 (UTC) Authentication-Results: sinyavsky.aurox.ch (amavisd-new); dkim=pass (1024-bit key) reason="pass (just generated, assumed good)" header.d=aurox.ch DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aurox.ch; h= content-transfer-encoding:content-type:content-type:mime-version :references:subject:subject:in-reply-to:to:from:from:message-id :date:date; s=dkim; t=1504972278; x=1505836279; bh=tO63skOvaS5r+ Fk+o5HTIUGnloUEmOR4Z+kjWip5H0k=; b=islAnYELzfI2No/m3XJ7T/YqeA0IC F27kZ5j6/FE00BKUrx8NSyAAbJCfCifX0NKvOl/kvVjrQAy7Xqqt6aVGGAZcgzg4 gzO1q414dzZyL4UQaLYa+RPTZF9WvGENMBlPOaVHCrXuxkryeQ2Fy3WZp1/NFxcP sLxtBDvQVy46Mo= X-Virus-Scanned: Debian amavisd-new at test.virtualizor.com Original-Received: from sinyavsky.aurox.ch ([127.0.0.1]) by sinyavsky.aurox.ch (sinyavsky.aurox.ch [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 6JVHd8AxQJyQ for <28350@debbugs.gnu.org>; Sat, 9 Sep 2017 15:51:18 +0000 (UTC) Original-Received: from gray (125.85.192.178.dynamic.wline.res.cust.swisscom.ch [178.192.85.125]) by sinyavsky.aurox.ch (Postfix) with ESMTPSA id 9A5FA2252B; Sat, 9 Sep 2017 15:51:16 +0000 (UTC) In-reply-to: <838thovvcr.fsf@gnu.org> (message from Eli Zaretskii on Sat, 09 Sep 2017 16:45:40 +0300) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:136708 Archived-At: Thanks for the feedback. > Date: Sat, 09 Sep 2017 16:45:40 +0300 > From: Eli Zaretskii > CC: 28350@debbugs.gnu.org > Reply-to: Eli Zaretskii > > > --- a/lisp/textmodes/enriched.el > > +++ b/lisp/textmodes/enriched.el > > @@ -503,6 +503,47 @@ enriched-decode-display-prop > > (error nil))))) > > (unless prop > > (message "Warning: invalid parameter %s" param)) > > - (list start end 'display prop))) > > + (if (enriched-display-prop-safe-p prop) > > + (list start end 'display prop) > > + (message "Warning: unsafe parameter %s not applied" param) > > + (list start end)))) > > I think we will want to allow unsafe display properties, given a > user's explicit permission. So I think we need a defcustom that > allows this, and then enriched-display-prop-safe-p should always > return non-nil. Agreed, I've added this. > > +See Info node `(elisp)Display Property' for the use of these > > +display specifications." > > + (ignore-errors > > + (or (stringp prop) > ^^^^^^^^^^^^ > What about an image spec (including a slice spec)? Okay, I see that image specs can be safe. But are they all safe? And I don't understand how a slice spec is used together with an image spec. Is the slice spec used inside of IMAGE-PROPS, i.e. as you might gather from the manual: ‘(image . IMAGE-PROPS)’ This kind of display specification is an image descriptor (*note Images). When used as a display specification, it means to display the image instead of the text that has the display specification. ‘(slice X Y WIDTH HEIGHT)’ This specification together with ‘image’ specifies a “slice” (a partial area) of the image to display. ? > > > + (and (eq (car prop) 'space-width) > > + (or (integerp (cadr prop)) (floatp (cadr prop)))) > > + (and (consp (car prop)) > > + (eq (caar prop) 'margin) > > + (or (eq (cadar prop) 'right-margin) > > + (eq (cadar prop) 'left-margin)) > > + (stringp (cadr prop))) > > The margin display can also specify an image, not just a string, and I > think that would be safe as well. Okay, I'll apply the same procedure as we decide for the above image spec. > > > + (and (eq (car prop) 'height) > > + (or (integerp (cadr prop)) > > + (and (listp (cadr prop)) > > + (or (eq (elt (cadr prop) 0) '+) (elt (cadr prop) 0) '-) > > + (integerp (elt (cadr prop) 1))))) > ^^^^^^^^ > I think this should be numberp, as the value could also safely be a > float. > > > + (and (eq (car prop) 'raise) > > + (integerp (cadr prop)))))) > ^^^^^^^^ > The FACTOR in (raise FACTOR) can also be a float, so I think numberp > is the correct predicate here. > > And then what about (space . PROPS) type of display spec? I think all > of its variants are safe. Okay, I've made these changes and added the `space' spec. At this point it seems that unsafe display specs are more the exception than the rule, so it might make sense to define the `enriched-display-prop-safe-p' function by excluding the unsafe specifications instead of including the safe ones. What do you think?