Making Gnus more worm-safe

Making Gnus more worm-safe

[Florian Weimer]

I'd suggest the following change to mailcap.el:

-      ("emacs-lisp"
-       (viewer . mailcap-maybe-eval)
-       (type   . "application/emacs-lisp"))

This feature is just too dangerous to be enabled by default.

If there aren't any objections, I'll remove it.

Re: Making Gnus more worm-safe

[Pavel Janík ml.]

   From: Florian Weimer <fw@deneb.cygnus.argh.org>
   Date: 05 May 2000 07:45:33 +0200

Hi,

   > -      ("emacs-lisp"
   > -       (viewer . mailcap-maybe-eval)
   > -       (type   . "application/emacs-lisp"))
   > 
   > This feature is just too dangerous to be enabled by default.
   > 
   > If there aren't any objections, I'll remove it.

do you think that this will prevent dumb people to save the buffer and
evaluate it? It is not about worms. It is about *#$! of people who click on
something. I think that these people do not use Gnus :-)
-- 
Pavel Janík ml.
Pavel.Janik@inet.cz

Re: Making Gnus more worm-safe

[Florian Weimer]

Pavel.Janik@inet.cz (Pavel Janík ml.) writes:

> do you think that this will prevent dumb people to save the buffer and
> evaluate it? 

Yes.  They don't know anything about "M-x eval-buffer". ;)

> It is not about worms. It is about *#$! of people who click on
> something. I think that these people do not use Gnus :-)

I agree that this change doesn't substantially increase security.  
It should be clear that it is mostly a PR thing.

Re: Making Gnus more worm-safe

[William M. Perry]

Florian Weimer <fw@deneb.cygnus.argh.org> writes:

> I'd suggest the following change to mailcap.el:
> 
> -      ("emacs-lisp"
> -       (viewer . mailcap-maybe-eval)
> -       (type   . "application/emacs-lisp"))
> 
> This feature is just too dangerous to be enabled by default.
> 
> If there aren't any objections, I'll remove it.

It asks the user before evaluating it at least.  What, you don't want to
someday open 'iloveyou.el'? :)

-Bill P.

Re: Making Gnus more worm-safe

[Florian Weimer]

wmperry@aventail.com (William M. Perry) writes:

> It asks the user before evaluating it at least.  

Just make the text of the message promising enough.  "To be eligible
to this special bonus, you have to evaluate the enclosed secret code
carefully."  This won't seduce experienced Emacs users and most native
speakers, I think, but there are many others.

> What, you don't want to someday open 'iloveyou.el'? :)

It's not about me, but about the people whom I recommend Gnus. ;)

Re: Making Gnus more worm-safe

[Kai Großjohann]

Florian Weimer <fw@deneb.cygnus.argh.org> writes:

> wmperry@aventail.com (William M. Perry) writes:
> 
> > It asks the user before evaluating it at least.  
> 
> Just make the text of the message promising enough.

Does the text of the question really depend on the mail that's received?

kai
-- 
Beware of flying birch trees.

Re: Making Gnus more worm-safe

[Florian Weimer]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Florian Weimer <fw@deneb.cygnus.argh.org> writes:
> 
> > wmperry@aventail.com (William M. Perry) writes:
> > 
> > > It asks the user before evaluating it at least.  
> > 
> > Just make the text of the message promising enough.
> 
> Does the text of the question really depend on the mail that's received?

No, but the answer of the user certainly does. ;)

Re: Making Gnus more worm-safe

[Hrvoje Niksic]

Florian Weimer <fw@deneb.cygnus.argh.org> writes:

> I'd suggest the following change to mailcap.el:
> 
> -      ("emacs-lisp"
> -       (viewer . mailcap-maybe-eval)
> -       (type   . "application/emacs-lisp"))
> 
> This feature is just too dangerous to be enabled by default.

Why is that?  It asks you before evaluating anything.

> If there aren't any objections, I'll remove it.

Don't.

Re: Making Gnus more worm-safe

[Bjørn Mork]

Hrvoje Niksic <hniksic@iskon.hr> writes:
> Florian Weimer <fw@deneb.cygnus.argh.org> writes:
> 
> > I'd suggest the following change to mailcap.el:
> > 
> > -      ("emacs-lisp"
> > -       (viewer . mailcap-maybe-eval)
> > -       (type   . "application/emacs-lisp"))
> > 
> > This feature is just too dangerous to be enabled by default.
> 
> Why is that?  It asks you before evaluating anything.

But before you get a chance to look at the code, so the only sensible
answer is "no".

> > If there aren't any objections, I'll remove it.
> 
> Don't.

Maybe changing mailcap-maybe-eval to disable the feature by default
but allowing it to be turned is better?


Bjørn

Re: Making Gnus more worm-safe

[Kai Großjohann]

"Bjørn Mork" <bmork@dod.no> writes:

> But before you get a chance to look at the code, so the only sensible
> answer is "no".

People could `i' on the part, first.

kai
-- 
Beware of flying birch trees.

Re: Making Gnus more worm-safe

[Hrvoje Niksic]

"Bjørn Mork" <bmork@dod.no> writes:

> Hrvoje Niksic <hniksic@iskon.hr> writes:
> > Florian Weimer <fw@deneb.cygnus.argh.org> writes:
> > 
> > > I'd suggest the following change to mailcap.el:
> > > 
> > > -      ("emacs-lisp"
> > > -       (viewer . mailcap-maybe-eval)
> > > -       (type   . "application/emacs-lisp"))
> > > 
> > > This feature is just too dangerous to be enabled by default.
> > 
> > Why is that?  It asks you before evaluating anything.
> 
> But before you get a chance to look at the code,

That's not true -- the code is displayed in an "*mm*" buffer.

Re: Making Gnus more worm-safe

[Bjørn Mork]

Hrvoje Niksic <hniksic@iskon.hr> writes:
> "Bjørn Mork" <bmork@dod.no> writes:
> > Hrvoje Niksic <hniksic@iskon.hr> writes:
> > > Florian Weimer <fw@deneb.cygnus.argh.org> writes:
> > > 
> > > > I'd suggest the following change to mailcap.el:
> > > > 
> > > > -      ("emacs-lisp"
> > > > -       (viewer . mailcap-maybe-eval)
> > > > -       (type   . "application/emacs-lisp"))
> > > > 
> > > > This feature is just too dangerous to be enabled by default.
> > > 
> > > Why is that?  It asks you before evaluating anything.
> > 
> > But before you get a chance to look at the code,
> 
> That's not true -- the code is displayed in an "*mm*" buffer.

Oops, you are right. Sorry. Did it always do that? Maybe I just
dreamt the whole problem.


Bjørn

Re: Making Gnus more worm-safe

[Hrvoje Niksic]

"Bjørn Mork" <bmork@dod.no> writes:

> > > But before you get a chance to look at the code,
> > 
> > That's not true -- the code is displayed in an "*mm*" buffer.
> 
> Oops, you are right. Sorry. Did it always do that?

As far as I remember, yes.

Re: Making Gnus more worm-safe

[Felix Lee]

Hrvoje Niksic <hniksic@iskon.hr>:
> That's not true -- the code is displayed in an "*mm*" buffer.

the trick then is to write elisp that looks innocuous and
useful but contains a hidden threat.  easier to fool people
unfamiliar with elisp.
--

Re: Making Gnus more worm-safe

[Bruce Stephens]

Felix Lee <flee@teleport.com> writes:

> Hrvoje Niksic <hniksic@iskon.hr>:
> > That's not true -- the code is displayed in an "*mm*" buffer.
> 
> the trick then is to write elisp that looks innocuous and
> useful but contains a hidden threat.  easier to fool people
> unfamiliar with elisp.

Time for an International Obfuscated Emacs Lisp Competition?

Re: Making Gnus more worm-safe

[Kai Großjohann]

Bruce Stephens <bruce+gnus@cenderis.demon.co.uk> writes:

> Time for an International Obfuscated Emacs Lisp Competition?

Yay!  Way to go!

What should it say?  `Just another little lambda'?

kai
-- 
Beware of flying birch trees.

Re: Making Gnus more worm-safe

[Michael Harnois]

On Fri, 5 May 2000 22:54:55 +0200, Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) said:

    > What should it say? `Just another little lambda'?

How about "Mary had a little lambda."

-- 
Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA 
mdharnois@home.com                      aa0bt@aa0bt.ampr.org 
 The deadliest bullshit is odorless and transparent.
   -- William Gibson

Re: Making Gnus more worm-safe

[Kai Großjohann]

Michael Harnois <mdharnois@home.com> writes:

> How about "Mary had a little lambda."

Of course!  Why didn't I see it?  Well, I'm not a native speaker ;-)

kai
-- 
Beware of flying birch trees.

Re: Making Gnus more worm-safe

[Florian Weimer]

Felix Lee <flee@teleport.com> writes:

> Hrvoje Niksic <hniksic@iskon.hr>:
> > That's not true -- the code is displayed in an "*mm*" buffer.
> 
> the trick then is to write elisp that looks innocuous and
> useful but contains a hidden threat.  easier to fool people
> unfamiliar with elisp.

Currently, the end of the buffer is displayed.  This portion of the
buffer doesn't even have to be in Lisp syntax, the harmful part is
executed if it's located the beginning of the file. ;)

Re: Making Gnus more worm-safe

[Florian Weimer]

Hrvoje Niksic <hniksic@iskon.hr> writes:

> > If there aren't any objections, I'll remove it.
> 
> Don't.

Hmm.  Would you accept a warning which is more elaborate?

Re: Making Gnus more worm-safe

[Hrvoje Niksic]

Florian Weimer <fw@deneb.cygnus.argh.org> writes:

> Hrvoje Niksic <hniksic@iskon.hr> writes:
> 
> > > If there aren't any objections, I'll remove it.
> > 
> > Don't.
> 
> Hmm.  Would you accept a warning which is more elaborate?

Sure.

Re: Making Gnus more worm-safe

[Florian Weimer]

Hrvoje Niksic <hniksic@iskon.hr> writes:

> > Hmm.  Would you accept a warning which is more elaborate?
> 
> Sure.

Is this acceptable?  (Obviously, I'm not a native speaker, and I would
be glad if someone could proofread it.)

*** WARNING ***

This MIME part contains untrusted and possibly harmful content.  
If you evaluate the Emacs Lisp code contained in it, a lot of nasty
things can happen.  Please examine the code very carefully before you
instruct Emacs to evaluate it.  You can browse the buffer containing
the code using \[scroll-other-window].

If you are not sure what you shall do, please answer "no".


I'm going to add a similar warning to the unshar functions in
gnus-uu.el.

Re: Making Gnus more worm-safe

[Bud Rogers]

Florian Weimer <fw@deneb.cygnus.argh.org> writes:

> Is this acceptable?  (Obviously, I'm not a native speaker, and I would
> be glad if someone could proofread it.)

Florian, your English is better than most native speakers I know.  Your
warning is clear and concise.

> If you are not sure what you shall do, please answer "no".

I think this might flow a little better if you said

"If you are not sure what to do,"       or
"If you are unsure what to do,"

Just MHO.

-- 
Bud Rogers <budr@sirinet.net>  http://www.sirinet.net/~budr/zamm.html

Re: Making Gnus more worm-safe

[Per Abrahamsen]

[-- Attachment #1: Type: text/plain, Size: 420 bytes --]

Florian Weimer <fw@deneb.cygnus.argh.org> writes:

> If there aren't any objections, I'll remove it.

I object on the following grounds:

1. Gnus already asks.

2. Gnus shows the code before executing it.

3. Compared to MS Outlook, there is a lot fewer Gnus users, and they
   are typically more experienced.  This makes it hard for a
   virus/worm to propagate. 

PS: Activate the attachment to win a billion dollar!


[-- Attachment #2: Type: application/emacs-lisp, Size: 256 bytes --]

Re: Making Gnus more worm-safe

[Laura Conrad]

>>>>> "Per" == Per Abrahamsen <abraham@dina.kvl.dk> writes:

    Per> PS: Activate the attachment to win a billion dollar!

Thanks for the demonstration -- that makes what we're arguing about
much clearer.  

-- 
Laura (mailto:lconrad@world.std.com , http://www.world.std.com/~lconrad/ )
(617) 661-8097	fax: (801) 365-6574 
233 Broadway, Cambridge, MA 02139

Re: Making Gnus more worm-safe

[Laura Conrad]

>>>>> "Per" == Per Abrahamsen <abraham@dina.kvl.dk> writes:

    Per> 1. Gnus already asks.

    Per> 2. Gnus shows the code before executing it.
    Per> 3. Compared to MS Outlook, there is a lot fewer Gnus users, and they
    Per>    are typically more experienced.  This makes it hard for a
    Per>    virus/worm to propagate. 

I agree with all of these points, but I don't think defaults should be 
designed on the assumption that the gnus user population is going to
remain the same as it is now.  I think one of the things we're working 
towards is improving the interface and the documentation to make it
easier for more people (and therefore a different population of
people) to use gnus.

That being said, I don't think Windows would have the email virus
problem it does if the default thing that happened when users clicked
on a program attachment was that the source code to the program was
displayed in another window.  


-- 
Laura (mailto:lconrad@world.std.com , http://www.world.std.com/~lconrad/ )
(617) 661-8097	fax: (801) 365-6574 
233 Broadway, Cambridge, MA 02139

Re: Making Gnus more worm-safe

[Brian May]

>>>>> "Per" == Per Abrahamsen <abraham@dina.kvl.dk> writes:

    Per> I object on the following grounds:

I don't care either way, but I think another point is significant:

    Per> 1. Gnus already asks.

    Per> 2. Gnus shows the code before executing it.

    Per> 3. Compared to MS Outlook, there is a lot fewer Gnus users,
    Per> and they are typically more experienced.  This makes it hard
    Per> for a virus/worm to propagate.

4. You typically expect a LISP file to contain executable code, but
normally wouldn't expect a *.DOC file to. Not only that, but some
people send genuine doc files (some include unwanted features), and it
is awkward for most end users to reconfigure the computer to safely
display the file.

Stupid! gs has had the -dSAFER option for how many years now? I am
under the impression that the software manufacture in question doesn't
care about security issues like this, or it would have been fixed by
now.
-- 
Brian May <bmay@csse.monash.edu.au>

Re: Making Gnus more worm-safe

[Alan Shutko]

Brian May <bmay@csse.monash.edu.au> writes:

> Stupid! gs has had the -dSAFER option for how many years now?

Well, I think that Word actually has a working option to turn off
macros now, but what no (almost no?) windows mailers have is a way to
run programs differently from a mailer than from the desktop.  Every
windows mailer I've seen just passes it off to ShellExecute (or
whatever that windows call is), completely ignoring mime type and
running it just as if it were a trusted file.

Windows users think this is actualy a good idea.

> I am under the impression that the software manufacture in question
> doesn't care about security issues like this, or it would have been
> fixed by now.

Well, duh!

-- 
Alan Shutko <ats@acm.org> - In a variety of flavors!
187 days, 1 hours, 38 minutes, 55 seconds till we run away.
Oppernockity tunes but once.

Re: Making Gnus more worm-safe

[Florian Weimer]

Brian May <bmay@csse.monash.edu.au> writes:

> Stupid! gs has had the -dSAFER option for how many years now?

And unshar(1) has been piping the archive to sh for how many years
now? ;)

Security options have been added to web2c TeX only recently, and most
*roff implementations are still insecure, I think.

Re: Making Gnus more worm-safe

[Soeren Laursen]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> Florian Weimer <fw@deneb.cygnus.argh.org> writes:
> 
> > If there aren't any objections, I'll remove it.
> 
> I object on the following grounds:
> 
> 1. Gnus already asks.
> 
> 2. Gnus shows the code before executing it.
> 
> 3. Compared to MS Outlook, there is a lot fewer Gnus users, and they
>    are typically more experienced.  This makes it hard for a
>    virus/worm to propagate. 
> 
> PS: Activate the attachment to win a billion dollar!

Damn, I nearly clicked it.

-- 
Søren Laursen http://www.tele.auc.dk/~slau/

Re: Making Gnus more worm-safe

[Greg Stark]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> Florian Weimer <fw@deneb.cygnus.argh.org> writes:
> 
> > If there aren't any objections, I'll remove it.
> 
> I object on the following grounds:
> 1. Gnus already asks.
> 2. Gnus shows the code before executing it.

Perhaps Gnus should use w3-elisp-safe-eval if it's available?

> PS: Activate the attachment to win a billion dollar!

-- 
greg

Prefer text/x-emacs-lisp to application/x-emacs-lisp?

[Raja R Harinath]

Hi,

Why doesn't Gnus use "text/x-emacs-lisp" by default when attaching .el
files.

I'm unclear about the distinction between application/foo and
text/foo.  But, to me, code that is meant to be read (e.g., postings
on gnu.emacs.source, or the automatic attachment of user settings by
reportbug) should be "text/x-emacs-lisp".  This way, the annoying
behaviour of Gnus while showing .el files will be avoided.  The
current behaviour of Gnus is painful since it assumes any attached
emacs lisp code is executable, and it presents the file inconveniently
-- in a different buffer that hides the *Article* buffer, rather than
inline.

In other words, is it an useful distinction to have two attachment
types for Emacs Lisp:

  text/x-emacs-lisp             Emacs Lisp code meant to be read, not
                                immediately executed.  Default
                                behaviour is to show inline,
                                preferably using emacs-lisp-mode.
                                This type is used by 'gnus-bug', and
                                as the default type for .el files.

  application/x-emacs-lisp      Code intended to be executed.
                                Default behaviour is the show "Worm"
                                warning, show code in a different
                                buffer, and if necessary, use a
                                sandbox to execute code.

- Hari
-- 
Raja R Harinath ------------------------------ harinath@cs.umn.edu
"When all else fails, read the instructions."      -- Cahn's Axiom
"Our policy is, when in doubt, do the right thing."   -- Roy L Ash

Re: Prefer text/x-emacs-lisp to application/x-emacs-lisp?

[Per Abrahamsen]

It's an interesting question, which is relevant beyond Emacs Lisp.
Could you try asking the question in comp.mail.mime?  The group seems
rather dead, but maybe some MIME gurus still read it.

Re: Making Gnus more worm-safe

[Toby Speight]

[-- Attachment #1: Type: text/plain, Size: 1107 bytes --]

Florian> Florian Weimer <URL:mailto:fw@deneb.cygnus.argh.org>

0> In article <87hfcdwnwi.fsf@deneb.cygnus.argh.org>, Florian wrote:

Florian> I'd suggest the following change to mailcap.el:
Florian>
Florian> -      ("emacs-lisp"
Florian> -       (viewer . mailcap-maybe-eval)
Florian> -       (type   . "application/emacs-lisp"))
Florian>
Florian> This feature is just too dangerous to be enabled by default.
Florian>
Florian> If there aren't any objections, I'll remove it.


Instead of `mailcap-maybe-eval', I use the following function to
display elisp parts highlighted with the usual font-locking:

.gnus> (defun mm-display-elisp-inline (handle)
.gnus>   (let (text)
.gnus>     (with-temp-buffer
.gnus>       (mm-insert-part handle)
.gnus>       (emacs-lisp-mode)
.gnus>       (font-lock-fontify-buffer)
.gnus>       (setq text (buffer-string)))
.gnus>     (mm-insert-inline handle text)))

Perhaps it's possible to do this without invoking (emacs-lisp-mode),
by `let'ing the appropriate font-lock variables instead.

Could we make this the default?

In fact, you might consider all of the following:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Viewers for elisp and diffs --]
[-- Type: text/x-emacs-lisp, Size: 1212 bytes --]


(defun mm-display-patch-inline (handle)
  (let (text)
    (with-temp-buffer
      (mm-insert-part handle)
      (diff-mode)
      (font-lock-fontify-buffer)
      (setq text (buffer-string)))
    (mm-insert-inline handle text)))

(defun mm-display-elisp-inline (handle)
  (let (text)
    (with-temp-buffer
      (mm-insert-part handle)
      (emacs-lisp-mode)
      (font-lock-fontify-buffer)
      (setq text (buffer-string)))
    (mm-insert-inline handle text)))


(defun mm-add-new-type (type displayer test auto-display inlined attachment-override)
  (push (list type displayer test) mm-inline-media-tests)
  (if auto-display
      (push type mm-automatic-display))
  (if inlined
      (push type mm-inlined-types))
  (if attachment-override
      (push type mm-attachment-override-types)))

(eval-after-load "mm-decode"
  '(progn
     (mm-add-new-type "text/x-patch"        'mm-display-patch-inline '(fboundp 'diff-mode) t t t)
     (mm-add-new-type "application/x-patch" 'mm-display-patch-inline '(fboundp 'diff-mode) t t t)
     (mm-add-new-type "text/x-emacs-lisp"      'mm-display-elisp-inline 'identity t t t)
     (mm-add-new-type "application/emacs-lisp" 'mm-display-elisp-inline 'identity t t t)))