C file recoginzed as image file

C file recoginzed as image file

[Charles Rendleman]

$ cat not_image_file.c
#define

$ emacs -Q not_image_file.c
$

In GNU Emacs 22.0.92.17 (x86_64-unknown-linux-gnu, GTK+ Version 2.4.13)
 of 2007-01-03 #######
X server distributor `The X.Org Foundation', version 11.0.60801000
configured using `configure  '--prefix=/u/local' '--with-gtk''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.iso885915
  locale-coding-system: iso-8859-15
  default-enable-multibyte-characters: t

Major mode: Image

Minor modes in effect:
  tooltip-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  line-number-mode: t

Recent input:
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <menu-bar> 
<help-menu> <report-emacs-bug>

Recent messages:
(emacs -Q not_image_file.c)
For information about the GNU Project and its goals, type C-h C-p.
Loading image-mode...done
Type C-c C-c to view the image as text.
Error loading XBM image `(image :type xbm :file /u/not_image_file.c)' [2 times]
Loading emacsbug...
Loading regexp-opt...done
Loading emacsbug...done
Error loading XBM image `(image :type xbm :file /u/not_image_file.c)'

Re: C file recoginzed as image file

[Chris Moore]

Charles Rendleman <c.a.rendle@gmail.com> writes:

> $ cat not_image_file.c
> #define
>
> $ emacs -Q not_image_file.c
> $

image.el has:

(defconst image-type-header-regexps
...
    ("\\`[\t\n\r ]*#define" . xbm)
...

so any file beginning with optional white space and then #define is
treated as an xbm image.

Similarly, any text file which starts with the 4 characters "GIF8" is
treated as if it was an image.

Re: C file recoginzed as image file

[Lennart Borgman (gmail)]

Chris Moore wrote:
> Charles Rendleman <c.a.rendle@gmail.com> writes:
> 
>> $ cat not_image_file.c
>> #define
>>
>> $ emacs -Q not_image_file.c
>> $
> 
> image.el has:
> 
> (defconst image-type-header-regexps
> ...
>     ("\\`[\t\n\r ]*#define" . xbm)
> ...
> 
> so any file beginning with optional white space and then #define is
> treated as an xbm image.
> 
> Similarly, any text file which starts with the 4 characters "GIF8" is
> treated as if it was an image.


It would be rather surprising at least on w32 if a file with extension 
.c was an image file.

Re: C file recoginzed as image file

[Chris Moore]

Chris Moore <dooglus@gmail.com> writes:

> so any file beginning with optional white space and then #define is
> treated as an xbm image.

I'm thinking it would be safer to use auto-mode-alist before
magic-mode-alist.  Treating files according to their content rather
than according to their extension is something which has caused a lot
of problems with virus spread on w32 platforms.

I don't want this situation to be possible in Emacs:

I receive a file foo.c in an email, save it to disk and open it in
Emacs, knowing that the .c type is opened in cc-mode which is safe.
To my horror, the file actually contains an evil .jpg file which
causes a buffer overflow in the jpg library; when it's displayed it
infects my machine with a virus.

Emacs shouldn't open me up to that risk when I am simply trying to
view a .c file.

Re: C file recoginzed as image file

[Juanma Barranquero]

On 1/5/07, Chris Moore <dooglus@gmail.com> wrote:

> I'm thinking it would be safer to use auto-mode-alist before
> magic-mode-alist.

`magic-mode-alist' is more specific. The problem is that some of these
regexps are too permissive. Supposing that anything that starts with
"#define " is a XBM file makes no sense.

I think it'd be good to apply the following patch, so auto-detection
of images by content is disabled, but available to these wanting to
set it up. (And we should mention `image-type-auto-detectable' in
NEWS.)

                    /L/e/k/t/u



Index: lisp/image.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/image.el,v
retrieving revision 1.66
diff -u -2 -r1.66 image.el
--- lisp/image.el	30 Dec 2006 01:51:24 -0000	1.66
+++ lisp/image.el	5 Jan 2007 18:53:41 -0000
@@ -65,12 +65,12 @@

  (defvar image-type-auto-detectable
-  '((pbm . t)
-    (xbm . t)
-    (bmp . maybe)
-    (gif . maybe)
-    (png . maybe)
-    (xpm . maybe)
-    (jpeg . maybe)
-    (tiff . maybe)
+  '((pbm . nil)
+    (xbm . nil)
+    (bmp . nil)
+    (gif . nil)
+    (png . nil)
+    (xpm . nil)
+    (jpeg . nil)
+    (tiff . nil)
     (postscript . nil))
   "Alist of (IMAGE-TYPE . AUTODETECT) pairs used to auto-detect image files.

Re: C file recoginzed as image file

[Chris Moore]

On 1/5/07, Juanma Barranquero <lekktu@gmail.com> wrote:

> `magic-mode-alist' is more specific. The problem is that some of these
> regexps are too permissive.

Even if magic-mode-alist was just right, and it only opened files as
images when they contain images, I don't want this mysterious .c file
I just received in the mail being opened as an image, because who
knows what it might do...  I trust Emacs's cc-mode not to execute any
malicious code when displaying C source code, what with all the
file-local variable checking and so on, but I don't trust the various
image libraries which are linked into Emacs not to have remaining
buffer overflow bugs in them.

It's possible that they're all fine now, but in the last few years the
following vulnerabilities have been found in various image libraries,
all of which possibly lead to the execution of arbitrary code:

libpng:
http://www.debian.org/security/2004/dsa-536
http://www.debian.org/security/2004/dsa-570

libpng3:
http://www.debian.org/security/2004/dsa-571

tiff:
http://www.debian.org/security/2004/dsa-567
http://www.debian.org/security/2004/dsa-617
http://www.debian.org/security/2005/dsa-626
http://www.debian.org/security/2005/dsa-755
http://www.debian.org/security/2006/dsa-1054
http://www.debian.org/security/2006/dsa-1078
http://www.debian.org/security/2006/dsa-1137

wmf:
http://www.debian.org/security/2006/dsa-1194

So I wouldn't be too willing to bet that they're safe now.

When opening a file with file-local variables in it, Emacs is quite
paranoid about checking with the user whether it's OK to use the
variable definitions.  But when the file contains an image file, Emacs
is happy to just display it without any kind of prompt or warning,
even when the file has a .c extension?

In short, .c files should be opened in cc-mode, no matter what they
contain, at least not without checking with the user first.  "The
file's extension indicates that this is C source code, but the file
contains an image in PNG format.  Display the image?  (y/n)"

Re: C file recoginzed as image file

[Juanma Barranquero]

On 1/5/07, Chris Moore <dooglus@gmail.com> wrote:

> Even if magic-mode-alist was just right, and it only opened files as
> images when they contain images, I don't want this mysterious .c file
> I just received in the mail being opened as an image, because who
> knows what it might do...

That's a reason no to auto-detect images, not a reason to use
`magic-mode-alist' after `auto-mode-alist'.

> But when the file contains an image file, Emacs
> is happy to just display it without any kind of prompt or warning,
> even when the file has a .c extension?

You're right. In my previous message in this tread, I already
suggested to deactivate auto-detection of images.

> In short, .c files should be opened in cc-mode, no matter what they
> contain, at least not without checking with the user first.  "The
> file's extension indicates that this is C source code, but the file
> contains an image in PNG format.  Display the image?  (y/n)"

That's more-or-less easy even now:

(defun image-auto-detect-y-or-n-p ()
  (let ((type (image-type-auto-detected-p)))
    (and type
         (y-or-n-p (format "File \"%s\" contains a `%s' image; display it "
                           (file-name-nondirectory buffer-file-name)
                           (image-type-from-buffer))))))

(setcar (rassq 'image-mode magic-mode-alist)
        'image-auto-detect-y-or-n-p)


                    /L/e/k/t/u

Re: C file recoginzed as image file

[Juanma Barranquero]

On 1/5/07, Juanma Barranquero <lekktu@gmail.com> wrote:
> That's more-or-less easy even now:

I mean this:

(defun image-auto-detect-y-or-n-p ()
  (let ((type (image-type-from-buffer)))
    (and type
         (y-or-n-p (format "File \"%s\" contains a `%s' image; display it "
                           (file-name-nondirectory buffer-file-name)
                           type)))))

(setcar (rassq 'image-mode magic-mode-alist)
        'image-auto-detect-y-or-n-p)

                    /L/e/k/t/u

Re: C file recoginzed as image file

[Chris Moore]

On 1/5/07, Juanma Barranquero <lekktu@gmail.com> wrote:

> That's a reason no to auto-detect images, not a reason to use
> `magic-mode-alist' after `auto-mode-alist'.

OK.

> That's more-or-less easy even now:

Perhaps the question should only be asked if the file content doesn't
match its extension.  If I'm opening a .png file and it contains a PNG
image, then I've already decided that I'm willing to trust the content
enough to display it.  But if I'm opening a .c file I haven't, and
want Emacs to warn me.

Re: C file recoginzed as image file

[Juanma Barranquero]

On 1/6/07, Chris Moore <dooglus@gmail.com> wrote:

> Perhaps the question should only be asked if the file content doesn't
> match its extension.

As it is currently implemented, once you auto-detect you don't have a
way to check `auto-mode-alist'. It could be fixed, and perhaps it is
really the best way (I can certainly see the benefit of warning the
user about a mismatch between the file extension and the contents),
but IMHO we shouldn't do it now. It's best just to deactivate image
auto-detection and let the users, if they trust their libraries and
files, to just set the required element of
`image-mode-auto-detectable' to 'maybe or t in their .emacs.

                    /L/e/k/t/u

Re: C file recoginzed as image file

[Jason Rumney]

Chris Moore wrote:
> On 1/5/07, Juanma Barranquero <lekktu@gmail.com> wrote:
>
>> `magic-mode-alist' is more specific. The problem is that some of these
>> regexps are too permissive.
>
> Even if magic-mode-alist was just right, and it only opened files as
> images when they contain images, I don't want this mysterious .c file
> I just received in the mail being opened as an image, because who
> knows what it might do...

I think this can be fixed by using image-mode-maybe in magic-mode-alist, 
instead of image-mode.
image-mode-maybe also needs to bind magic-mode-alist to nil to avoid 
infinite recursion.


Index: files.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/files.el,v
retrieving revision 1.876
diff -c -r1.876 files.el
*** files.el    4 Jan 2007 22:14:32 -0000       1.876
--- files.el    6 Jan 2007 00:09:43 -0000
***************
*** 2126,2132 ****
  associated with that interpreter in `interpreter-mode-alist'.")

  (defvar magic-mode-alist
!   `((image-type-auto-detected-p . image-mode)
      ;; The < comes before the groups (but the first) to reduce 
backtracking.
      ;; TODO: UTF-16 <?xml may be preceded by a BOM 0xff 0xfe or 0xfe 0xff.
      ;; We use [ \t\n] instead of `\\s ' to make regex overflow less 
likely.
--- 2126,2132 ----
  associated with that interpreter in `interpreter-mode-alist'.")

  (defvar magic-mode-alist
!   `((image-type-auto-detected-p . image-mode-maybe)
      ;; The < comes before the groups (but the first) to reduce 
backtracking.
      ;; TODO: UTF-16 <?xml may be preceded by a BOM 0xff 0xfe or 0xfe 0xff.
      ;; We use [ \t\n] instead of `\\s ' to make regex overflow less 
likely.
Index: image-mode.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/image-mode.el,v
retrieving revision 1.15
diff -c -r1.15 image-mode.el
*** image-mode.el       29 Aug 2006 13:02:53 -0000      1.15
--- image-mode.el       6 Jan 2007 00:09:10 -0000
***************
*** 111,117 ****
                         elt))
                     auto-mode-alist))))
      (if (assoc-default buffer-file-name mode-alist 'string-match)
!       (let ((auto-mode-alist mode-alist))
          (set-auto-mode)
          (image-minor-mode t))
        (image-mode))))
--- 111,118 ----
                         elt))
                     auto-mode-alist))))
      (if (assoc-default buffer-file-name mode-alist 'string-match)
!       (let ((auto-mode-alist mode-alist)
!             (magic-mode-alist nil))
          (set-auto-mode)
          (image-minor-mode t))
        (image-mode))))

Re: C file recoginzed as image file

[Richard Stallman]

I fixed this.  Thanks.

Re: C file recoginzed as image file

[Richard Stallman]

    Similarly, any text file which starts with the 4 characters "GIF8" is
    treated as if it was an image.

Is there anything else we could check for
to distinguish real GIF files from other files?
Would someone please check the spec?

Re: C file recoginzed as image file

[Richard Stallman]

    I don't want this situation to be possible in Emacs:

    I receive a file foo.c in an email, save it to disk and open it in
    Emacs, knowing that the .c type is opened in cc-mode which is safe.
    To my horror, the file actually contains an evil .jpg file which
    causes a buffer overflow in the jpg library; when it's displayed it
    infects my machine with a virus.

Compare that with this scenario:

    You receive a file foo.jpg in an email, you save it to disk
    and open it in Emacs, figuring that a jpg file ought to be safe.
    To your horror, the file actually contains an evil .jpg file which
    causes a buffer overflow in the jpg library; when it's displayed it
    infects your machine with a virus.

Assuming there is such a bug in the jpg library, the latter scenario
seems much more likely than the former.

Besides which, a jpg file starts with characters that don't make any
sense at the start of a C file.  So if it looks like a plausible C
file, it won't be treated as a jpeg.

Re: C file recoginzed as image file

[Richard Stallman]

    I think it'd be good to apply the following patch, so auto-detection
    of images by content is disabled, but available to these wanting to
    set it up.

No way!  We won't delete a feature because of a minor fixable bug.  (I
fixed the bug already.)

Re: C file recoginzed as image file

[Stefan Monnier]

>     I receive a file foo.c in an email, save it to disk and open it in
>     Emacs, knowing that the .c type is opened in cc-mode which is safe.
>     To my horror, the file actually contains an evil .jpg file which
>     causes a buffer overflow in the jpg library; when it's displayed it
>     infects my machine with a virus.

> Compare that with this scenario:

>     You receive a file foo.jpg in an email, you save it to disk
>     and open it in Emacs, figuring that a jpg file ought to be safe.
>     To your horror, the file actually contains an evil .jpg file which
>     causes a buffer overflow in the jpg library; when it's displayed it
>     infects your machine with a virus.

> Assuming there is such a bug in the jpg library, the latter scenario
> seems much more likely than the former.

No: there are known security holes in jpg libs, not in cc-mode.
So when I receive mail from an unknown source and it has a jpg file in it,
I'll think twice before opening the image.  OTOH if it's a ".c" file, I'll
feel confident that it's perfectly safe to open it.

Such misleading file names have been used over and over again in
w32 viruses.

> Besides which, a jpg file starts with characters that don't make any
> sense at the start of a C file.  So if it looks like a plausible C
> file, it won't be treated as a jpeg.

But that assumes you've already been able to see the content of the file.
Typically, this is not the case: you get an attachment called "foo.c" and
you ask Emacs to display it to see this (supposedly) C code.


        Stefan

Re: C file recoginzed as image file

[Stefan Monnier]

>> I'm thinking it would be safer to use auto-mode-alist before
>> magic-mode-alist.

> `magic-mode-alist' is more specific. The problem is that some of these
> regexps are too permissive. Supposing that anything that starts with
> "#define " is a XBM file makes no sense.

Just in case someone forgot: this whole problem is only due to the fact that
Richard doesn't want to default auto-mode-case-fold to t (which would make
it unnecessary to use magic-mode-alist).

Can't we revert this whole idea of using magic-mode-alist, and then just set
auto-mode-case-fold to t (and then remove this useless new configuration
variable)?

Again, Richard, please give us some concrete reason why you think it's more
incorrect to choose sh-mode than fundamental-mode for .BASH_PROFILE.


        Stefan

Re: C file recoginzed as image file

[Juanma Barranquero]

On 1/6/07, Richard Stallman <rms@gnu.org> wrote:

> No way!  We won't delete a feature

I wasn't talking about deleting it, just not making it default.

Not to mention that the "feature" is all of... a week old?

> (I fixed the bug already.)

Yeah, I know.

                    /L/e/k/t/u

Re: C file recoginzed as image file

[Juanma Barranquero]

On 1/6/07, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> Richard doesn't want to default auto-mode-case-fold to t (which would make
> it unnecessary to use magic-mode-alist).

I disagree. Yes, the discussion originally talked about setting image
mode for .jpg vs .JPG (or somesuch), but detecting images in
magic-mode-alist was done because someone requested having .JPG images
without the extension (thumbnails for .MPG videos, I think)
auto-detected by Emacs. This is worthwhile. Whether it should be
default or not is another issue (and I certainly don't object to it
*not* being default, though it seems like Richard does).

                    /L/e/k/t/u

Re: C file recoginzed as image file

[Chris Moore]

Richard Stallman <rms@gnu.org> writes:

>     Similarly, any text file which starts with the 4 characters "GIF8" is
>     treated as if it was an image.
>
> Is there anything else we could check for
> to distinguish real GIF files from other files?
> Would someone please check the spec?

http://www.w3.org/Graphics/GIF/spec-gif89a.txt tells me that the first
3 bytes contain the fixed value 'GIF', and the next 3 bytes contain
the version number:

            Version Numbers as of 10 July 1990 :       "87a" - May 1987
                                                       "89a" - July 1989

            Version numbers are ordered numerically increasing on the first two
            digits starting with 87 (87,88,...,99,00,...,85,86) and
            alphabetically increasing on the third character (a,...,z).

Immediately after this 6 byte header comes the logical screen
descriptor, which doesn't contain anything we can use to recognise a
valid image.

So a better image-type-header-regexps entry would be:

    ("\\`GIF[0-9][0-9][a-z]" . gif)

Re: C file recoginzed as image file

[Chris Moore]

Richard Stallman <rms@gnu.org> writes:

>     I don't want this situation to be possible in Emacs:
>
>     I receive a file foo.c in an email, save it to disk and open it in
>     Emacs, knowing that the .c type is opened in cc-mode which is safe.
>     To my horror, the file actually contains an evil .jpg file which
>     causes a buffer overflow in the jpg library; when it's displayed it
>     infects my machine with a virus.
>
> Compare that with this scenario:
>
>     You receive a file foo.jpg in an email, you save it to disk
>     and open it in Emacs, figuring that a jpg file ought to be safe.
>     To your horror, the file actually contains an evil .jpg file which
>     causes a buffer overflow in the jpg library; when it's displayed it
>     infects your machine with a virus.
>
> Assuming there is such a bug in the jpg library, the latter scenario
> seems much more likely than the former.

That's a big assumption to make.  There have been many exploitable
bugs in image libraries in recent years.  Because of this, I wouldn't
figure that a jpg file is safe to open, whereas I would figure that a
C source file is safe to open.

> Besides which, a jpg file starts with characters that don't make any
> sense at the start of a C file.  So if it looks like a plausible C
> file, it won't be treated as a jpeg.

If it looks like a plausible C file to who?  In the case I described
all I've seen so far is the file's name so as far as I know it is a C
source file.  I try to examine the contents using Emacs, and it is
displayed as an image.

Re: C file recoginzed as image file

[Richard Stallman]

    Perhaps the question should only be asked if the file content doesn't
    match its extension.  If I'm opening a .png file and it contains a PNG
    image, then I've already decided that I'm willing to trust the content
    enough to display it.

How cautious are you about files with .png extensions?
Do you carefully avoid displaying them if you are not sure
where they came from?

Re: C file recoginzed as image file

[Richard Stallman]

    I think this can be fixed by using image-mode-maybe in magic-mode-alist, 
    instead of image-mode.

That would ensure never visiting a .c file as an image, and the change
is ok with me.  However, if we consider buffer overflows in these
libraries a problem in Emacs, that is not enough to prevent such
problems.

What needs to be done, I think, is for these libraries to explicitly
validate the data before starting to display it.

Re: C file recoginzed as image file

[Chris Moore]

Richard Stallman <rms@gnu.org> writes:

> How cautious are you about files with .png extensions?
> Do you carefully avoid displaying them if you are not sure
> where they came from?

It depends which box I'm on.  If it's a box I don't care about then
I'll be less cautious than if it's a box that needs to stay secure.

The point is that I'd like the displaying of .png files to happen when
I want it to.  Currently Emacs takes that choice out of my hands by
displaying .el files as PNG images without warning when they happen to
contain PNG formatted data.

Suppose I post a URL to this list asking people to take a look at my
Emacs Lisp code:  http://.../dir/mymode.el
People click on the link hoping to see my code and instead they end up
with Emacs crashing and their machine being infected by a virus, since
mymode.el is actually a renamed copy of myvirus.tiff.  That shouldn't
be possible when all they've done is clicked on a .el URL.

Re: C file recoginzed as image file

[Richard Stallman]

The reason I decided to detect images by their contents
rather than by their file names is that it seems more correct
as a way of recognizing them.

Re: C file recoginzed as image file

[Richard Stallman]

    http://www.w3.org/Graphics/GIF/spec-gif89a.txt tells me that the first
    3 bytes contain the fixed value 'GIF', and the next 3 bytes contain
    the version number:

Can you find the list of actual valid version numbers?  I'd rather
recognize those specific numberd, rather than any two-digit number
whatsoever.

Re: C file recoginzed as image file

[Richard Stallman]

    That's a big assumption to make.  There have been many exploitable
    bugs in image libraries in recent years.  Because of this, I wouldn't
    figure that a jpg file is safe to open, whereas I would figure that a
    C source file is safe to open.

It would never have occurred to me to have doubts about opening a JPG
file.  I am sure the same is true of many Emacs users.  If we believe
that having Emacs display JPG files as images is dangerous, we had
better make sure Emacs NEVER does so by default.

For the long term, we could also make Emacs thoroughly validate the
data of any JPG before calling the library to display it.  That is too
much change for right now, but we could do it after the release.

    > Besides which, a jpg file starts with characters that don't make any
    > sense at the start of a C file.  So if it looks like a plausible C
    > file, it won't be treated as a jpeg.

    If it looks like a plausible C file to who?

To anyone who knows C.  The first two characters of a JPG file are
character codes above 128, that would obviously be invalid in C.

      In the case I described
    all I've seen so far is the file's name so as far as I know it is a C
    source file.

How did the data get into a file in the first place?  Did it go
through Emacs?  Did you see the data before you saved it in a file?

I never save data from a message in a file without seeing it, but
perhaps you use a method.

Re: C file recoginzed as image file

[Stefan Monnier]

> The reason I decided to detect images by their contents
> rather than by their file names is that it seems more correct
> as a way of recognizing them.

Why does it seem that way to you?


        Stefan

Re: C file recoginzed as image file

[Chris Moore]

Richard Stallman <rms@gnu.org> replies:

> The reason I decided to detect images by their contents rather than
> by their file names is that it seems more correct as a way of
> recognizing them.

So if someone sends me a virus in image format disguised as Emacs Lisp
code, the correct thing to do is to install the virus, rather than
display it safely in Emacs Lisp mode?  Because that's what Emacs will
currently do.

I just checked what GNOME's file manager does if I rename an image to
"foo.txt" and then try to view it by double-clicking it.

A dialog box pops up saying:


  Cannot open foo.txt

  The filename "foo.txt" indicates that this file is of type "plain
  text document". The contents of the file indicate that the file is
  of type "JPEG image". If you open this file, the file might present
  a security risk to your system.

  Do not open the file unless you created the file yourself, or
  received the file from a trusted source. To open the file, rename
  the file to the correct extension for "JPEG image", then open the
  file normally. Alternatively, use the Open With menu to choose a
  specific application for the file.

                             [Cancel]


Notice that there isn't even an option for "open it anyway" - just
"cancel".  So the GNOME designers obviously think this is enough of a
problem to fix it.

I don't see the point of leaving this security hole in Emacs just
before a release.

Re: C file recoginzed as image file

[Chris Moore]

Richard Stallman <rms@gnu.org> writes:

> It would never have occurred to me to have doubts about opening a
> JPG file.  I am sure the same is true of many Emacs users.  If we
> believe that having Emacs display JPG files as images is dangerous,
> we had better make sure Emacs NEVER does so by default.

Maybe the JPG libraries are safe and always have been, I don't know.
But all it takes is for ONE of the image libraries which Emacs uses to
be exploitable and you're finished.  Suppose that's an unpatched
vulnerability in the tiff library.  All the attacker needs to do is
rename his virus.tiff file to virus.jpg and send it to you.  You'll
open it, because you have no doubts about opening JPG files, and then
you'll be surprised to find you're infected because it wasn't actually
a JPG file at all - it was a disguised TIFF file.

>       In the case I described
>     all I've seen so far is the file's name so as far as I know it is a C
>     source file.
>
> How did the data get into a file in the first place?  Did it go
> through Emacs?  Did you see the data before you saved it in a file?

Maybe I used 'wget' to download it from a website.

Maybe I'm browsing a remote site using TRAMP in Emacs and somebody
else put the data into the file.

Maybe I saved an email attachment using GNUS.

None of these would have displayed the data before saving it.

> I never save data from a message in a file without seeing it, but
> perhaps you use a method.

How do you see it safely?  However you do it, wouldn't it be more
convenient to arrange for Emacs to do it for you, and to warn you if
the content doesn't match the extension?

Re: C file recoginzed as image file

[Michaël Cadilhac]

[-- Attachment #1.1: Type: text/plain, Size: 1218 bytes --]

Richard Stallman <rms@gnu.org> writes:

>     http://www.w3.org/Graphics/GIF/spec-gif89a.txt tells me that the first
>     3 bytes contain the fixed value 'GIF', and the next 3 bytes contain
>     the version number:
>
> Can you find the list of actual valid version numbers?  I'd rather
> recognize those specific numberd, rather than any two-digit number
> whatsoever.

According to /usr/share/misc/file/magic, a GIF file is described as 

0       string          GIF8            GIF image data
>4      string          7a              \b, version 8%s,
>4      string          9a              \b, version 8%s,

So the regexp should be GIF8[79]a .

Actually, the two only versions of GIF are indeed 87a and 89a (named
after the year each format was created).

We probably should stick to the definitions of
/usr/share/misc/file/magic to create our magic variable.

-- 
 |      Michaël `Micha' Cadilhac     |  La culture c'est comme la confiture,  |
 |         Epita/LRDE Promo 2007     |      c'est meilleur avec du pain.      |
 |  http://michael.cadilhac.name     |           -- MOI59                     |
 `--JID: michael.cadilhac@gmail.com--'                                   -  --'

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: C file recoginzed as image file

[Lennart Borgman (gmail)]

> Maybe the JPG libraries are safe and always have been, I don't know.


http://www.microsoft.com/technet/security/bulletin/MS04-028.mspx

Re: C file recoginzed as image file

[Lennart Borgman (gmail)]

Richard Stallman wrote:
> The reason I decided to detect images by their contents
> rather than by their file names is that it seems more correct
> as a way of recognizing them.


But the discussion is more about not doing something potentially harmful 
(displaying an image file) in a case when the user would expect it to be 
completely harmless (opening a .c file).

Re: C file recoginzed as image file

[Jason Rumney]

Richard Stallman wrote:
>     > Besides which, a jpg file starts with characters that don't make any
>     > sense at the start of a C file.  So if it looks like a plausible C
>     > file, it won't be treated as a jpeg.
>
>     If it looks like a plausible C file to who?
>
> To anyone who knows C.  The first two characters of a JPG file are
> character codes above 128, that would obviously be invalid in C.
>   

The user cannot see those first two characters until they load the file. 
If it is in fact a dangerous jpg file, they will not find out until too 
late. If my patch to use image-mode-maybe for magic-mode-alist is 
installed, this will not happen for file extensions that the user might 
reasonably expect to be something other than an image. But it will still 
happen for unknown file extensions, which in some cases (.thm files, or 
thumbnails without an extension) will be considered a good thing, but 
there may also be cases where a user receives a file with an unknown 
extension and opens it in Emacs to see the file contents to decide what 
type of file it is, expecting Emacs to be a safe way of checking such 
files. So maybe it would be better to define a new function 
`image-mode-confirm' which always asks the user before using image-mode 
on a file, and using that for magic-mode-alist and other uses which 
could be considered risky.

Re: C file recoginzed as image file

[Stefan Monnier]

> expect to be something other than an image. But it will still happen for
> unknown file extensions, which in some cases (.thm files, or thumbnails
> without an extension)

BTW, can't we use some other part of the file name (typically the parent
directory's name) to choose the mode to use for thumbnails
without extension?


        Stefan "who uses .thm for files containing theorems"

Re: C file recoginzed as image file

[Mathias Dahl]

> ... but detecting images in
> magic-mode-alist was done because someone requested having .JPG images
> without the extension (thumbnails for .MPG videos, I think)
> auto-detected by Emacs. This is worthwhile. Whether it should be
> default or not is another issue

It was me that mentioned that I liked that Emacs recognized that a
.thm file (in my case) was actually a JPEG file, and that I found that
conventient. I did not think about the security implications.

I would still find it convenient if there was a confirmation (as per
the different suggestions where the file extension does not seem to
match the file format).

Re: C file recoginzed as image file

[Juanma Barranquero]

On 1/6/07, Jason Rumney <jasonr@gnu.org> wrote:

> I think this can be fixed by using image-mode-maybe in magic-mode-alist,
> instead of image-mode.

I like this fix.

It is still possible to disguise an image type as another image type
(a JPEG with a .png file extension, for example), but I don't think
that's much of an issue, unless someone happens to trust jpeg62.dll
and not libpng13.dll, for example, which would be weird.

All in all, we should reach a decision regarding this issue and act
upon it. IIRC, there are a few alternatives:

 1) Do nothing, i.e., let Emacs auto-detect images.
 2) Disable auto-detection, but leave it available to users who want
to set it up (with `image-type-auto-detectable').
  3) Revert to previous state: Remove `image-type-auto-detected-p' and
`image-type-auto-detectable' and leave `magic-mode-alist' as before.
 4) Use `image-type-maybe' (as per Jason's patch) so valid extensions
take precedence over contents-based detection (of image files, not in
the general case).
 5) Ask the user when the file extension and the auto-detected image
type disagree.
 6) Ask the user whenever an image file is auto-detected based on contents.
  7) Use a "disabled" wrapper for image-mode (or image-mode-maybe) in
`magic-mode-alist', so the user is forced to decide whether he trusts
auto-detection or not (I just dreamed this one, and I'm adding it out
of completeness, but I don't like it).
 8) Any other?

My preferences are: 4, 2, 5, 6, 7, 1, 3.

                    /L/e/k/t/u

Re: C file recoginzed as image file

[Richard Stallman]

    > The reason I decided to detect images by their contents
    > rather than by their file names is that it seems more correct
    > as a way of recognizing them.

    Why does it seem that way to you?

The whole point of a magic number is to recognize the file type
from its contents, regardless of file name.

Re: C file recoginzed as image file

[Richard Stallman]

    So the regexp should be GIF8[79]a .

Thanks.

Re: C file recoginzed as image file

[Richard Stallman]

    > It would never have occurred to me to have doubts about opening a
    > JPG file.  I am sure the same is true of many Emacs users.  If we
    > believe that having Emacs display JPG files as images is dangerous,
    > we had better make sure Emacs NEVER does so by default.

    Maybe the JPG libraries are safe and always have been, I don't know.

That isn't the point.  I mentioned JPG specifically in my message
because I responded to someone else that specifically mentioned JPG.
It would be the same for any other image type.  It would never have
occurred to me to have doubts about opening an image file in Emacs.
ANY type of image file.  I am sure the same is true of many Emacs
users.

    But all it takes is for ONE of the image libraries which Emacs uses to
    be exploitable and you're finished.

If we believe that having Emacs display some kind of image files as
images is dangerous, we had better make sure Emacs doesn't display
them as images until the user asks for that and has seen the file
text.

How significant this danger is in the Emacs context depends on a
number of things.  I am not sure whether the danger is enough to
matter.  But if it is, the only adequate protection is NEVER to
display such images as images by default.

The solution you and others are proposing, to display the image as an
image only when the file name extension matches the image type, is
inadequate to avoid the problem.  You might feel suspicion when you
see an extension such as .jpg, .gif, or .png, but lots of users, such
as me, would not.  Checking the file type would not protect us.
If someone wanted to send us a JPG with a virus, he could call
the file something.jpg, and bypass this test.

      Suppose that's an unpatched
    vulnerability in the tiff library.  All the attacker needs to do is
    rename his virus.tiff file to virus.jpg and send it to you.

If there is some sort of vulnerability in the tiff library, I will not
know about it.  I do not hear about such things.

The way I look at an attachment is to get it in an Emacs buffer.  Then
I save it with M-x write-region.  If it is a JPG, I expect to see PFIF
or EXIF in a certain place.  If I see it there, I save the file as
foo.jpg.

If the attachment was labeled ".jpg" and the contents look like a tiff
file instead of a jpg, I might get suspicious.  However, if it looks
like tiff and the file name is ".tiff", I would not get suspicious.

Thus, the only way to protect me from a vulnerability in the tiff
library is if Emacs does not open tiff files as images by default.

Substitute any other type of image file for "tiff" and the same
conclusion follows.

Re: C file recoginzed as image file

[Richard Stallman]

    The user cannot see those first two characters until they load the file. 
    If it is in fact a dangerous jpg file, they will not find out until too 
    late.

I now understand why this is true for other users.

With my way of using Emacs, I always see the file contents
in a buffer before I save it in a file.

Re: C file recoginzed as image file

[Richard Stallman]

      7) Use a "disabled" wrapper for image-mode (or image-mode-maybe) in
    `magic-mode-alist', so the user is forced to decide whether he trusts
    auto-detection or not (I just dreamed this one, and I'm adding it out
    of completeness, but I don't like it).

That might be a good alternative.  The usual disabled command feature
lets you enable the command either once or permanently.

If not that, then we should simply disable it.

Re: C file recoginzed as image file

[Richard Stallman]

    So if someone sends me a virus in image format disguised as Emacs Lisp
    code, the correct thing to do is to install the virus, rather than
    display it safely in Emacs Lisp mode?

Although I appreciate the help you have given on other occasions,
that doesn't make sarcastic attacks like this one ok.

Please do not talk to me this way again.

Re: C file recoginzed as image file

[Richard Stallman]

      The filename "foo.txt" indicates that this file is of type "plain
      text document". The contents of the file indicate that the file is
      of type "JPEG image". If you open this file, the file might present
      a security risk to your system.

A "safety feature" that can be bypassed by simply giving the file a
different name such as "foo.jpg" is not reliable.  It provides only
an appearance of safety.

If there is a real danger from some type of image file,
the only way to be safe is not to display those images.

Re: C file recoginzed as image file

[Chris Moore]

Richard Stallman <rms@gnu.org> writes:

>     So if someone sends me a virus in image format disguised as Emacs Lisp
>     code, the correct thing to do is to install the virus, rather than
>     display it safely in Emacs Lisp mode?
>
> Although I appreciate the help you have given on other occasions,
> that doesn't make sarcastic attacks like this one ok.
>
> Please do not talk to me this way again.

That wasn't sarcasm, it was indicating the result of using the magic
number in preference to the filename without warning the user.

I have tried various ways of trying to explain this risk to you but
you don't seem to understand any of them.  I thought perhaps a
reductio ad absurdum[1] argument might help.  Apparently not.

I'm sorry you don't like the form of argument I used.  Do you have a
list of other types of logical argument you find offensive, so I can
avoid making a similar mistake again?

[1] http://en.wikipedia.org/wiki/Reduction_ad_absurdum

Re: C file recoginzed as image file

[Reiner Steib]

On Mon, Jan 08 2007, Richard Stallman wrote:

> How significant this danger is in the Emacs context depends on a
> number of things.  I am not sure whether the danger is enough to
> matter.  But if it is, the only adequate protection is NEVER to
> display such images as images by default.

IIUC, Emacs relies on the image libraries in the same way as Emacs
relies on zlib (or is gzip?) to (un)compress *.gz files.  I recall
vulnerabilities on both (e.g. zlib and libpng[1]) during the past
years.  If you consider image libs as dangerous in general, you may
also think about all other libs linked to Emacs.

> The solution you and others are proposing, to display the image as an
> image only when the file name extension matches the image type, is
> inadequate to avoid the problem.  You might feel suspicion when you
> see an extension such as .jpg, .gif, or .png, but lots of users, such
> as me, would not.  Checking the file type would not protect us.
> If someone wanted to send us a JPG with a virus, he could call
> the file something.jpg, and bypass this test.

A user who has compiled Emacs _without_ JPEG support would not expect
to see something.jpg displayed as an image even if the content is PNG,
I think.  And in case there's a vulnerability in libpng, he would not
expect to be in danger when opening something.jpg.

> If there is some sort of vulnerability in the tiff library, I will not
> know about it.  I do not hear about such things.

For most GNU/Linux systems, the vulnerable image libraries will be
replaced by fixed versions via (automatic) online updates soon.  If
there's a vulnerability in one of the image libraries it usually
affects dozens or hundreds of programs (or packages).  E.g. on my
system, the image libraries used by Emacs (libpng, libjpeg, giflib,
libXpm) are use by more than 200 other packages.  As the image libs
(at least libpng and libjpeg) are also used by most web browsers (such
as Mozilla Firefox), such vulnerabilities need to be fixed very fast
by the distributors (displaying images from untrusted sources in web
browsers is much more common[2] that opening them in Emacs).

Bye, Reiner.

[1]
,----[ rpm -q --changelog zlib | less +/secur ]
| * Wed Jul 20 2005 - meissner@...
| - Upgraded to 1.2.3. Security fix is now in mainline.
`----

,----[ rpm -q --changelog libpng | less +/secur ]
| * Mon Aug 16 2004 - nadvornik@...
| - updated to 1.2.6: included security fixes
`----

[2] "more common" in the sense of how many people use web browsers
    vs. people who open images in Emacs.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: C file recoginzed as image file

[Andreas Schwab]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

> IIUC, Emacs relies on the image libraries in the same way as Emacs
> relies on zlib (or is gzip?) to (un)compress *.gz files.

Emacs does not use zlib for (un)compressing, it calls gzip as an external
program.  A bug in gzip cannot affect Emacs beyond getting a stream of
garbage bytes from it.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: C file recoginzed as image file

[Stefan Monnier]

>> The reason I decided to detect images by their contents
>> rather than by their file names is that it seems more correct
>> as a way of recognizing them.

>     Why does it seem that way to you?

> The whole point of a magic number is to recognize the file type
> from its contents, regardless of file name.

But they're heuristics as well.  A text file may start with the title
"GIF89a file format".

Basically, I think that determining the major mode for a given file should
neither give precedence to auto-mode-alist nor magic-mode-alist.  Instead it
should consider both.  Each one can associate a file with a set of possible
major modes (typically the set will be singleton) or say "don't know"
(which would be basically the set of all major modes).

E.g. auto-mode-alist would give "don't know" for a file named "/b/c/foo" but
would give the set { perl-mode, prolog-mode } for a file named
"/b/c/foo.pl".  Then magic-mode-alist would give other sets of modes (based
on things like the #! interpreter name, the -*- ... -*- cookie, etc...).
If the intersection of the two sets is a singleton, then use that
major-mode, otherwise query the user to decide whether to believe the file
name or the contents.  After all, an inconsistently named file is generally
a sign that there's something wrong, so it's good to prompt the user
about it.


        Stefan

Re: C file recoginzed as image file

[Kim F. Storm]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> The reason I decided to detect images by their contents
>>> rather than by their file names is that it seems more correct
>>> as a way of recognizing them.
>
>>     Why does it seem that way to you?
>
>> The whole point of a magic number is to recognize the file type
>> from its contents, regardless of file name.
>
> But they're heuristics as well.  A text file may start with the title
> "GIF89a file format".
>
> Basically, I think that determining the major mode for a given file should
> neither give precedence to auto-mode-alist nor magic-mode-alist.  Instead it
> should consider both.  Each one can associate a file with a set of possible
> major modes (typically the set will be singleton) or say "don't know"
> (which would be basically the set of all major modes).
>
> E.g. auto-mode-alist would give "don't know" for a file named "/b/c/foo" but
> would give the set { perl-mode, prolog-mode } for a file named
> "/b/c/foo.pl".  Then magic-mode-alist would give other sets of modes (based
> on things like the #! interpreter name, the -*- ... -*- cookie, etc...).
> If the intersection of the two sets is a singleton, then use that
> major-mode, otherwise query the user to decide whether to believe the file
> name or the contents.  After all, an inconsistently named file is generally
> a sign that there's something wrong, so it's good to prompt the user
> about it.

This is definitely the best proposal I've seen so far for solving this.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: C file recoginzed as image file

[Stephen J. Turnbull]

Stefan Monnier writes:

 > If the intersection of the two sets is a singleton, then use that
 > major-mode,

Hear, hear!  Suggestion: s/two/N/.

There may be metadata available (eg, from url.el).

 > otherwise query the user to decide whether to believe the file name
 > or the contents.

If the contents look like OGG to Emacs's heuristic, I doubt libpng or
ImageMagick will take the user's word that it's PNG.

In general, I think that users would prefer information from metadata,
then file names, then contents.  So I suggest that (1) if there's
metadata giving a MIME type, for example, then display using that type
if all available heuristics agree (in the sense of a singleton
intersection), otherwise warn the user and suggest one or more
commands that can be used to force a codec compatible with the
content; (2) else if the file extension heuristic is available, then
display using that type if all available heuristics agree, otherwise
warn and suggest; (3) else use the contents.

YMMV, so if you think a different order of precedence is appropriate,
you can amend the algorithm in the obvious way.

Re: C file recoginzed as image file

[Lennart Borgman (gmail)]

Kim F. Storm wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
...
>> Basically, I think that determining the major mode for a given file should
>> neither give precedence to auto-mode-alist nor magic-mode-alist.  Instead it
>> should consider both.  Each one can associate a file with a set of possible
>> major modes (typically the set will be singleton) or say "don't know"
>> (which would be basically the set of all major modes).
...

> This is definitely the best proposal I've seen so far for solving this.


Agree + including mime header info as someone said.

Re: C file recoginzed as image file

[Stuart D. Herring]

>> IIUC, Emacs relies on the image libraries in the same way as Emacs
>> relies on zlib (or is gzip?) to (un)compress *.gz files.
>
> Emacs does not use zlib for (un)compressing, it calls gzip as an external
> program.  A bug in gzip cannot affect Emacs beyond getting a stream of
> garbage bytes from it.

A bug in gzip, invoked automatically on untrusted data by Emacs, could
very easily affect Emacs by becoming the pawn of a remote program and then
A) sending Emacs SIGKILL or B) deleting the user's .emacs file or C) (in
an appropriate privilege environment) destroying the filesystem on which
emacs is stored.  A is obviously an overly literal effect, and precisely B
happening is unlikely, but the threat of scenarios like B and C is present
whether it is Emacs' memory space (via a library linked into it statically
or dynamically) in which the attack occurs or it is merely due to Emacs
that the attack can occur so automatically.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: C file recoginzed as image file

[David Kastrup]

Chris Moore <dooglus@gmail.com> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>>     So if someone sends me a virus in image format disguised as
>>     Emacs Lisp code, the correct thing to do is to install the
>>     virus, rather than display it safely in Emacs Lisp mode?
>>
>> Although I appreciate the help you have given on other occasions,
>> that doesn't make sarcastic attacks like this one ok.
>>
>> Please do not talk to me this way again.
>
> That wasn't sarcasm, it was indicating the result of using the magic
> number in preference to the filename without warning the user.
>
> I have tried various ways of trying to explain this risk to you but
> you don't seem to understand any of them.  I thought perhaps a
> reductio ad absurdum[1] argument might help.  Apparently not.
>
> I'm sorry you don't like the form of argument I used.  Do you have a
> list of other types of logical argument you find offensive, so I can
> avoid making a similar mistake again?

That is assuming that the other person is not paying attention, and so
you try to repeat the same content with rhetoric decoration.

Even if you want to use this kind of "logical argument", it can be
done in a way that does not insinuate stupidity on the audience's
side.  Compare your version:

>>     So if someone sends me a virus in image format disguised as
>>     Emacs Lisp code, the correct thing to do is to install the
>>     virus, rather than display it safely in Emacs Lisp mode?

with, for example:

    If we did it that way and someone sent me a virus in image format
    disguised as Emacs Lisp code, the virus would be installed, when I
    would expect it to merely be displayed safely in Emacs Lisp mode.

That way you don't insinuate that the other person, when thinking
about the _same_ _complete_ _case_ as you do, would come to a bad
decision concerning _that_ case.

In short: try to make it your job to show how a particular technical
choice leads to bad results in certain cases, not to show that you
think someone else has worse judgment than you do.

Not everybody thinks of all the same things immediately.  We are not
Borg.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: C file recoginzed as image file

[Eli Zaretskii]

> From: storm@cua.dk (Kim F. Storm)
> Date: Mon, 08 Jan 2007 16:25:47 +0100
> Cc: lekktu@gmail.com, c.a.rendle@gmail.com, rms@gnu.org, dooglus@gmail.com,
> 	emacs-devel@gnu.org
> >
> > Basically, I think that determining the major mode for a given file should
> > neither give precedence to auto-mode-alist nor magic-mode-alist.  Instead it
> > should consider both.  Each one can associate a file with a set of possible
> > major modes (typically the set will be singleton) or say "don't know"
> > (which would be basically the set of all major modes).
> >
> > E.g. auto-mode-alist would give "don't know" for a file named "/b/c/foo" but
> > would give the set { perl-mode, prolog-mode } for a file named
> > "/b/c/foo.pl".  Then magic-mode-alist would give other sets of modes (based
> > on things like the #! interpreter name, the -*- ... -*- cookie, etc...).
> > If the intersection of the two sets is a singleton, then use that
> > major-mode, otherwise query the user to decide whether to believe the file
> > name or the contents.  After all, an inconsistently named file is generally
> > a sign that there's something wrong, so it's good to prompt the user
> > about it.
> 
> This is definitely the best proposal I've seen so far for solving this.

But not something we should do before the release, IMO, however
tempting it may be.

Re: C file recoginzed as image file

[Eli Zaretskii]

> Date: Mon, 08 Jan 2007 18:32:33 +0100
> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
> Cc: dooglus@gmail.com, rms@gnu.org, lekktu@gmail.com, c.a.rendle@gmail.com,
> 	emacs-devel@gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>
> 
> > This is definitely the best proposal I've seen so far for solving this.
> 
> 
> Agree + including mime header info as someone said.

Aha, and how many more years would you be willing to wait for the
release of Emacs 22.1?

Re: C file recoginzed as image file

[Juanma Barranquero]

On 1/8/07, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> After all, an inconsistently named file is generally
> a sign that there's something wrong, so it's good to prompt the user
> about it.

That's a bit of second-guessing. We are not in the business of knowing
why someone uses non-default file names. And let's not forget that a
file with a .c extension containing a GIF image is absolutely,
non-ambiguously a GIF, whatever the .c may seem to imply.

I'm just saying that extension and contents are two ways to determine
what a file is intended to be; but both aren't equally significant.
                    /L/e/k/t/u

Re: C file recoginzed as image file

[David Kastrup]

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

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 1/8/07, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
>> After all, an inconsistently named file is generally
>> a sign that there's something wrong, so it's good to prompt the user
>> about it.
>
> That's a bit of second-guessing. We are not in the business of knowing
> why someone uses non-default file names. And let's not forget that a
> file with a .c extension containing a GIF image is absolutely,
> non-ambiguously a GIF, whatever the .c may seem to imply.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: woozle.c --]
[-- Type: text/x-csrc, Size: 169 bytes --]

GIF89a(char c)
{
  return c>'0';
}

#include <stdio.h>

main(int ac, char **av)
{
  while (++av,--ac > 0)
    putchar("yn" [GIF89a(**av)]);
  putchar('\n');
  return;
}

[-- Attachment #3: Type: text/plain, Size: 52 bytes --]



-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: C file recoginzed as image file

[Juanma Barranquero]

Yeah, a *really* contrived example (and I'd like you doing the same
with a TIFF). Wonderful argument. And your point is?

                    /L/e/k/t/u

Re: C file recoginzed as image file

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> Yeah, a *really* contrived example (and I'd like you doing the same
> with a TIFF). Wonderful argument. And your point is?

Your point was:

> And let's not forget that a file with a .c extension containing a
> GIF image is absolutely, non-ambiguously a GIF, whatever the .c may
> seem to imply.

I don't agree with the "absolutely, non-ambigously" angle.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: C file recoginzed as image file

[Chris Moore]

David Kastrup <dak@gnu.org> writes:

> Even if you want to use this kind of "logical argument", it can be
> done in a way that does not insinuate stupidity on the audience's
> side.  Compare your version:

I didn't insinuate stupidity on anyone's side.

> In short: try to make it your job to show how a particular technical
> choice leads to bad results in certain cases, not to show that you
> think someone else has worse judgment than you do.

That is what I was trying to do.  I'm sorry that I'm not very good at
making myself clear, but I don't see how what I said could be seen as
insinuating stupidity.  Do you really think that's what Richard's
problem with my sentence was?  Because he said that he read it as
"a sarcastic attack".

Re: C file recoginzed as image file

[Juanma Barranquero]

On 1/8/07, David Kastrup <dak@gnu.org> wrote:

> I don't agree with the "absolutely, non-ambigously" angle.

And your counterargument is a contrived example.

Even if you were right, that's a matter of the regexp used to match
the contents. Perhaps for GIFs it's not very good, but as I've said,
I'd like to see a real-world .c file with a PNG or TIFF header (or
even a real-world .c file with a GIF header, instead of your
proof-of-concept).

                    /L/e/k/t/u

Re: C file recoginzed as image file

[Chris Moore]

David Kastrup <dak@gnu.org> writes:

Compare your version:

>     If we did it that way and someone sent me a virus in image format
>     disguised as Emacs Lisp code, the virus would be installed, when I
>     would expect it to merely be displayed safely in Emacs Lisp mode.

with, for example, the following which I had previously written in
this thread:

| I don't want this situation to be possible in Emacs:
| 
| I receive a file foo.c in an email, save it to disk and open it in
| Emacs, knowing that the .c type is opened in cc-mode which is safe.
| To my horror, the file actually contains an evil .jpg file which
| causes a buffer overflow in the jpg library; when it's displayed it
| infects my machine with a virus.

That is pointing out how the choice to display disguised images as
images can lead to bad results.

Re: C file recoginzed as image file

[Stefan Monnier]

>> > Basically, I think that determining the major mode for a given file should
>> > neither give precedence to auto-mode-alist nor magic-mode-alist.  Instead it
>> > should consider both.  Each one can associate a file with a set of possible
>> > major modes (typically the set will be singleton) or say "don't know"
>> > (which would be basically the set of all major modes).
>> >
>> > E.g. auto-mode-alist would give "don't know" for a file named "/b/c/foo" but
>> > would give the set { perl-mode, prolog-mode } for a file named
>> > "/b/c/foo.pl".  Then magic-mode-alist would give other sets of modes (based
>> > on things like the #! interpreter name, the -*- ... -*- cookie, etc...).
>> > If the intersection of the two sets is a singleton, then use that
>> > major-mode, otherwise query the user to decide whether to believe the file
>> > name or the contents.  After all, an inconsistently named file is generally
>> > a sign that there's something wrong, so it's good to prompt the user
>> > about it.
>> 
>> This is definitely the best proposal I've seen so far for solving this.

> But not something we should do before the release, IMO, however
> tempting it may be.

Obviously not.  OTOH if we agree that it's the direction in which we want to
go, than maybe it can give us some guidance as to which way to quickly solve
the immediate problem.


        Stefan

Re: C file recoginzed as image file

[Juanma Barranquero]

On 1/8/07, David Kastrup <dak@gnu.org> wrote:

> Your point was:
>
> > And let's not forget that a file with a .c extension containing a
> > GIF image is absolutely, non-ambiguously a GIF, whatever the .c may
> > seem to imply.
>
> I don't agree with the "absolutely, non-ambigously" angle.

I must be sleepy, because I didn't realize at first that you had
reversed what I said and then attacked the strawman.

I didn't say: "a C file can not be confused with a GIF file based in a
regexp match". I specifically talked about "a file with a .c extension
containing a GIF image". Your example is a file with a .c extension
containing a C program, not a GIF image. I was talking about false
negatives, and you've shown a false positive.

Moreover, I'd like to remember that in this thread I've been
advocating to *deactivate* auto-detection.

                    /L/e/k/t/u

Re: C file recoginzed as image file

[Lennart Borgman (gmail)]

Stefan Monnier wrote:

> Obviously not.  OTOH if we agree that it's the direction in which we want to
> go, than maybe it can give us some guidance as to which way to quickly solve
> the immediate problem.


For the future: I did not read all the messages but I believe I saw 
something about updating of image libraries. That is an extremely 
important point to protect against security threats. Shouldn't we use 
libraries that are already there on the platform (if that is possible) 
to make this easier?

Re: C file recoginzed as image file

[Stefan Monnier]

>> After all, an inconsistently named file is generally a sign that there's
>> something wrong, so it's good to prompt the user about it.

> That's a bit of second-guessing.  We are not in the business of knowing
> why someone uses non-default file names.

If she uses non-default file names, she can easily change auto-mode-alist to
reflect it.  I see no problem here.


        Stefan

Re: C file recoginzed as image file

[Stefan Monnier]

> And let's not forget that a file with a .c extension containing a GIF
> image is absolutely, non-ambiguously a GIF, whatever the .c may seem
> to imply.

Actually that's not true.  The nature of a file in Unix is neither
determined by its name nor by its content but by what you do with it.
If you pass it to `display', it's a GIF image; if you pass it to `cc' it's
a C program; if you pass it to `hexl' it's a byte-stream; if you pass it to
`more' it's a text file.


        Stefan

Re: C file recoginzed as image file

[Juanma Barranquero]

On 1/9/07, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> If she uses non-default file names, she can easily change auto-mode-alist to
> reflect it.

That's like saying: if she worries about her libraries' security, she
can modify magic-mode-alist or image-type-auto-detectable.

But really, I don't care much about what fix we choose, just that we
do choose one soonish.

OTOH, I think Richard had a point: if image libraries are a security
problem, we should deactivate auto-opening of *all* images, not just
the ones where the file extension doesn't match. I'm gonna get a virus
much easier from a real .tiff or .png file than from a TIFF or PNG
file disguised as a C file.

That would mean removing image extensions from `auto-mode-alist' and
letting the trusting user add them herself. Funny.

                    /L/e/k/t/u

Re: C file recoginzed as image file

[Juanma Barranquero]

On 1/9/07, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> Actually that's not true.  The nature of a file in Unix is neither
> determined by its name nor by its content but by what you do with it.

That's more of a philosophical question, but a JPEG image is a JPEG
image. Whether you treat it like text, bytes, an image or a
pseudo-random source is another matter entirely. Your camera didn't
take a text file or a bit of random binary data, it took a picture in
JPEG format. It's a practical question: how many times that image will
be used as that, an image, as opposed to as any other thing?

                    /L/e/k/t/u

Re: C file recoginzed as image file

[Richard Stallman]

    That wasn't sarcasm, it was indicating the result of using the magic
    number in preference to the filename without warning the user.

In nearly all cases, the result of displaying an image file is an
image on your screen.

Your conclusion is based on two assumptions: that (1) there is a bug
in a library and (2) the image file has a virus specifically designed
to take advantage of this bug and cause trouble in Emacs.

Assumption 1 may be true occasionally, but it will be false nearly
all the time.

Assumption 2 is not impossible, but we don't know that anyone will
actually do it.

Please don't assume that the unlikely case is the only case.

Re: C file recoginzed as image file

[Richard Stallman]

      And in case there's a vulnerability in libpng, he would not
    expect to be in danger when opening something.jpg.

He probably won't expect to be in danger when opening something.png,
because he probably won't know about the vulnerability.

    For most GNU/Linux systems, the vulnerable image libraries will be
    replaced by fixed versions via (automatic) online updates soon.

That is true for many users, but there is a substantial fraction that,
like me, hardly ever updates software.

Re: C file recoginzed as image file

[Stuart D. Herring]

> That's more of a philosophical question, but a JPEG image is a JPEG
> image. Whether you treat it like text, bytes, an image or a
> pseudo-random source is another matter entirely. Your camera didn't
> take a text file or a bit of random binary data, it took a picture in
> JPEG format. It's a practical question: how many times that image will
> be used as that, an image, as opposed to as any other thing?

It's true that a JPEG image is a JPEG image, but "foo.jpg" (or even
"foo.c") is not a JPEG image, it's a file (well, a filename, but consider
the associated file).  And a (seekable) file is a sequence of bytes, not
an image.  An image can be constructed from it, but just as you said it's
a matter of how you treat it.

The question here (for Emacs) is not "What is the source and importance of
this data?" whose answer might be "A camera; it's a picture of the
Thames." but rather "In what manner should these bytes with this name be
presented to the user?" whose answer might be "As a C file, since its
extension is `.c'." or "As a JPEG image, because JPEG images begin the
same way as these bytes do.".  Poorer reasons to be sure than "It's a
picture of the Thames because that's where I was when I took it.", but
they're the best we can hope to do; the problem is which heuristics are
most useful and how to resolve conflicts in the partial information we
have.

Finally, remember that we don't have a concept of "that image" for
counting usage: this decision has to be made the first time we see a file,
regardless of its history of usage.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: C file recoginzed as image file

[Juanma Barranquero]

On 1/9/07, Stuart D. Herring <herring@lanl.gov> wrote:

> It's true that a JPEG image is a JPEG image, but "foo.jpg" (or even
> "foo.c") is not a JPEG image, it's a file (well, a filename, but consider
> the associated file).  And a (seekable) file is a sequence of bytes, not
> an image.  An image can be constructed from it, but just as you said it's
> a matter of how you treat it.

I don't know about you, but I don't have "seekable sequences of bytes"
in my Pictures folder. I have images (of my dogs, mostly). I use them
as images: I display them, print them, send them to Flickr and pass
them to other people so they can admire my dogs. That these pictures
are also "seekable sequences of bytes" is an implementation detail. If
I ever want to access one of these pictures from Emacs, 99,999999% of
time I'll want them as images, not as any other thing.

> Finally, remember that we don't have a concept of "that image" for
> counting usage: this decision has to be made the first time we see a file,
> regardless of its history of usage.

Then the decision and heuristics should be geared towards the most
common use, shouldn't it?

                    /L/e/k/t/u

Re: C file recoginzed as image file

[Chris Moore]

Richard Stallman <rms@gnu.org> writes:

> Your conclusion is based on two assumptions: that (1) there is a bug
> in a library and (2) the image file has a virus specifically designed
> to take advantage of this bug and cause trouble in Emacs.
>
> Assumption 1 may be true occasionally, but it will be false nearly
> all the time.

While it may be true that there are no publicly disclosed bugs in
image libraries most of the time, I would question how likely it is
that there are no undisclosed bugs in image libraries at any given
point in time.  It's quite possible that there's an exploitable bug in
one of the image libraries which Emacs uses which has been there since
the library was first created.

> Assumption 2 is not impossible, but we don't know that anyone will
> actually do it.

It's not necessary for the virus to be specific to Emacs.  The bug can
potentially be exploitable not matter which application the library is
linked to.

> Please don't assume that the unlikely case is the only case.

I don't think it is particularly unlikely that it is possible to
construct an image file which will caused Emacs to execute malicious
code when the image is displayed.  Most, and probably all images on
any given user's system are safe to display in Emacs, but shouldn't we
guard against the time that they open that one specially crafted image
which infects their system?

Re: C file recoginzed as image file

[Stefan Monnier]

>> If she uses non-default file names, she can easily change auto-mode-alist
>> to reflect it.

> That's like saying: if she worries about her libraries' security, she
> can modify magic-mode-alist or image-type-auto-detectable.

No, just that if you often use non-standard file names, you may want to
explain your own standard to Emacs so that it can figure out what's
going on.
And if your standard is constantly changing, then you'll have to live with
the consequences of your own insane choices.

This is and has been true of all files in Emacs.  It's not specific
to images.


        Stefan

Re: C file recoginzed as image file

[Richard Stallman]

    Shouldn't we use 
    libraries that are already there on the platform (if that is possible) 
    to make this easier?

I do not understand what this suggestion means.  I would
like to understand.

Could you please explain more clearly what you are advocating, and
also, what the alternative is which you are arguing against?

Re: C file recoginzed as image file

[Stephen J. Turnbull]

Richard Stallman writes:

 > In nearly all cases, the result of displaying an image file is an
 > image on your screen.  [...]  Please don't assume that the unlikely
 > case is the only case.

Please consider that the probability that you describe above is likely
the wrong probability for this purpose.  The right one is the
cumulative probability that one of many images displayed over the
period of use of Emacs will realize the threat.  This probability is
evidently distressingly large in the proprietary[1] Windows world.

It is probably much smaller for Emacs users (but you'd need to study
their usage patterns in the light of the threat vectors to be sure).


Footnotes: 
[1]  Ie, people who use proprietary software almost exclusively, as
opposed to those who use free software except where employer demands
force them to use proprietary software.

Re: C file recoginzed as image file

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 1/8/07, David Kastrup <dak@gnu.org> wrote:
>
>> I don't agree with the "absolutely, non-ambigously" angle.
>
> And your counterargument is a contrived example.

A contrived example is enough in my book for countering "absolutely,
non-ambiguously".

-- 
David Kastrup

Re: C file recoginzed as image file

[Juanma Barranquero]

On 1/9/07, David Kastrup <dak@gnu.org> wrote:

> A contrived example is enough in my book for countering "absolutely,
> non-ambiguously".

For countering what I was *not* saying, undoubtedly.

                    /L/e/k/t/u

Re: C file recoginzed as image file

[Lennart Borgman (gmail)]

Richard Stallman wrote:
>     Shouldn't we use 
>     libraries that are already there on the platform (if that is possible) 
>     to make this easier?
> 
> I do not understand what this suggestion means.  I would
> like to understand.
> 
> Could you please explain more clearly what you are advocating, and
> also, what the alternative is which you are arguing against?


Then I am beginning to think that this might be a problem only on w32. 
On w32 we are not using image libraries that are available from MS 
Windows. Instead we are using libraries from 
http://gnuwin32.sourceforge.net/.

Installation of these libraries can be done by the user or they may come 
with a package together with Emacs. For example I currently distribute 
these with my prebuilt binaries.

Whichever way it is done it puts a new burdon on the user who have to 
look for security updates to these image libraries and somehow update 
them in case of a security problem with them. And in addition to this 
there might be a long delay before the libraries are updated in gnuwin32.

As I said above I guess (but do not know) that Emacs on GNU/Linux uses 
the image libraries that comes with the OS. That avoids the problems I 
have sketched above. I think we should strive to do the same on other 
OS:es (for example w32) too.

How to technically achieve this is another question.

Re: C file recoginzed as image file

[Jason Rumney]

Lennart Borgman (gmail) wrote:
> Then I am beginning to think that this might be a problem only on w32. 
> On w32 we are not using image libraries that are available from MS 
> Windows.

There are no Free libraries available from MS Windows to handle the 
image types that Emacs supports. And even if there were, it does not 
make sense to use a completely different set of image libraries on MS 
Windows than on other platforms.

Re: C file recoginzed as image file

[Jan Nieuwenhuizen]

Eli Zaretskii <eliz@gnu.org> writes:

> Aha, and how many more years would you be willing to wait for the
> release of Emacs 22.1?

Does anyone care?  How many seasoned emacs users out there have not
been running emacs-cvs or emacs-snapshot for some years now?

Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org

Re: C file recoginzed as image file

[Chong Yidong]

Jan Nieuwenhuizen <janneke-list@xs4all.nl> writes:

>> Aha, and how many more years would you be willing to wait for the
>> release of Emacs 22.1?
>
> Does anyone care?  How many seasoned emacs users out there have not
> been running emacs-cvs or emacs-snapshot for some years now?

The majority.  Most people use the default software packaged into
their distribution rather than switching the defaults or compiling for
themselves.

Re: C file recoginzed as image file

[Jan Nieuwenhuizen]

Chong Yidong <cyd@stupidchicken.com> writes:

> The majority.  Most people

Ah, we have statistics then?

Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org

Re: C file recoginzed as image file

[Lennart Borgman (gmail)]

Jason Rumney wrote:
> Lennart Borgman (gmail) wrote:
>> Then I am beginning to think that this might be a problem only on w32. 
>> On w32 we are not using image libraries that are available from MS 
>> Windows.
> 
> There are no Free libraries available from MS Windows to handle the 
> image types that Emacs supports. And even if there were, it does not 
> make sense to use a completely different set of image libraries on MS 
> Windows than on other platforms.


In my opinion it definitively does. It enhances the security for the users.

Even if there are no free image libraries there are image libraries that 
comes with MS Windows. (Maybe there are some free libraries that comes 
with Firefox? I do not know.)

Re: C file recoginzed as image file

[Jason Rumney]

Lennart Borgman (gmail) wrote:
> Even if there are no free image libraries there are image libraries 
> that comes with MS Windows.

If they are not Free, we would not consider using them.

Re: C file recoginzed as image file

[Lennart Borgman (gmail)]

Jason Rumney wrote:
> Lennart Borgman (gmail) wrote:
>> Even if there are no free image libraries there are image libraries 
>> that comes with MS Windows.
> 
> If they are not Free, we would not consider using them.



This is about the security of Emacs users on MS Windows. You are 
suggesting that the principle to not use the libraries that comes with 
MS Windows as a very important principle. So important that we should 
not consider using them even if that could make it more safe for the users.

Or am I misunderstanding you? If I am not misunderstanding you should we 
then perhaps rethink this principle? I do not argue against the 
principle as such - it is fine. However what do we do in circumstances 
like these we are actually talking about here?

Re: C file recoginzed as image file

[David Kastrup]

Chong Yidong <cyd@stupidchicken.com> writes:

> Jan Nieuwenhuizen <janneke-list@xs4all.nl> writes:
>
>>> Aha, and how many more years would you be willing to wait for the
>>> release of Emacs 22.1?
>>
>> Does anyone care?  How many seasoned emacs users out there have not
>> been running emacs-cvs or emacs-snapshot for some years now?
>
> The majority.  Most people use the default software packaged into
> their distribution rather than switching the defaults or compiling for
> themselves.

Debian popularity contest:

Package: emacs21                         3237   983   537     1
Package: emacs21-bin-common              3493  1136   588     0
Package: emacs21-common                  3391  1237   604    74
Package: emacs21-el                         0     0     0  1063
Package: emacs21-nox                      267   149    41     0
Package: emacsen-common                  1802  1265   452  3508

Package: emacs-snapshot                   107    19    91     0
Package: emacs-snapshot-bin-common        296    73   156     0
Package: emacs-snapshot-common            290    74   161     7
Package: emacs-snapshot-el                  0     0     0   199
Package: emacs-snapshot-gtk               187    29   106     0
Package: emacs-snapshot-nox                25    33    24     0

The caption says:

inst     : number of people who installed this package;
vote     : number of people who use this package regularly;
old      : number of people who installed, but don't use this package regularly;
recent   : number of people who upgraded this package recently;
no-files : number of people whose entry didn't contain enough information (atime
and ctime were 0).

Which is sort of annoying since we have 4 numbers and 5 explanations.

But you get the gist.

-- 
David Kastrup

Re: C file recoginzed as image file

[Chong Yidong]

Jan Nieuwenhuizen <janneke-list@xs4all.nl> writes:

>> The majority.  Most people
>
> Ah, we have statistics then?
>
> Jan.

That's right.  See David Kastrup's email, for example.

Re: C file recoginzed as image file

[martin rudalics]

> Which is sort of annoying since we have 4 numbers and 5 explanations.

What about

#Format
#
#<name> is the package name;
#<inst> is the number of people who installed this package;
#<vote> is the number of people who use this package regularly;
#<old> is the number of people who installed, but don't use this package
#      regularly;
#<recent> is the number of people who upgraded this package recently;
#<no-files> is the number of people whose entry didn't contain enough
#           information (atime and ctime were 0).
#rank name                            inst  vote   old recent no-files (maintainer)
18    emacsen-common                  7027  1802  1265   452  3508 (Rob Browning)
20    emacs21-common                  5306  3391  1237   604    74 (Rob Browning)
21    emacs21-bin-common              5217  3493  1136   588     0 (Rob Browning)
23    emacs21                         4758  3237   983   537     1 (Rob Browning)
45    emacs21-el                      1063     0     0     0  1063 (Rob Browning)
57    emacs                            704    11    22    15   656 (Rob Browning)
64    emacs-snapshot-common            532   290    74   161     7 (Romain Francoise)
65    emacs-snapshot-bin-common        525   296    73   156     0 (Romain Francoise)
72    emacs21-nox                      457   267   149    41     0 (Rob Browning)
85    emacs-snapshot-gtk               322   187    29   106     0 (Romain Francoise)
101   emacs20                          243    98   144     1     0 (Not in sid)
107   emacs-snapshot                   217   107    19    91     0 (Romain Francoise)
153   emacs-snapshot-nox                82    25    33    24     0 (Romain Francoise)
255   emacs20-el                        13     0     0     0    13 (Not in sid)
265   emacs19                           11     4     7     0     0 (Not in sid)
316   emacs19-el                         2     0     0     0     2 (Not in sid)

Re: C file recoginzed as image file

[Stephen Leake]

Richard Stallman <rms@gnu.org> writes:

> In nearly all cases, the result of displaying an image file is an
> image on your screen.

True.

> Your conclusion is based on two assumptions: that (1) there is a bug
> in a library and (2) the image file has a virus specifically designed
> to take advantage of this bug and cause trouble in Emacs.

True.

> Assumption 1 may be true occasionally, but it will be false nearly
> all the time.

"occasionally" here does not refer to the number of images viewed, but
the number of libraries used. There are only a few of those (maybe
10?). So if one of them has a bug, that's 10%.

> Assumption 2 is not impossible, but we don't know that anyone will
> actually do it.

Yes, we do; there are examples of real viruses that do exactly that.

Hmm. Not including the "cause trouble in Emacs" part; just causing
trouble on the computer is the intent of the virus. Emacs is just the
user interface to the image library in this case.

The point people have been making is that these real viruses use a
file extension that is _not_ an image file extension, in an attempt to
fool the reader into getting infected.

You are correct that using the file extension alone to determine
whether the file is an image is not fool-proof.

But a heuristic that says:

"if the file extension does not match the contents, it is more likely
that this is a virus attack"

is useful. That is what is being proposed here.

-- 
-- Stephe

Re: C file recoginzed as image file

[Stephen Leake]

Jan Nieuwenhuizen <janneke-list@xs4all.nl> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> Aha, and how many more years would you be willing to wait for the
>> release of Emacs 22.1?

Clearly that would be for after this release.

> Does anyone care?  How many seasoned emacs users out there have not
> been running emacs-cvs or emacs-snapshot for some years now?

Everyone on my team at work, except me.

Emacs 22 is a mild productivity boost over Emacs 21. I hope my team
can benefit from it soon.

-- 
-- Stephe

Re: C file recoginzed as image file

[Stephen Leake]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 1/8/07, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
>> After all, an inconsistently named file is generally
>> a sign that there's something wrong, so it's good to prompt the user
>> about it.
>
> That's a bit of second-guessing. We are not in the business of knowing
> why someone uses non-default file names. And let's not forget that a
> file with a .c extension containing a GIF image is absolutely,
> non-ambiguously a GIF, whatever the .c may seem to imply.

It may be a GIF with an embedded virus. That is an important concern.

Obviously, it would be good to allow the user to easily customize any
such scheme to allow alternate file naming conventions, or to ignore
file extensions.

-- 
-- Stephe

Re: C file recoginzed as image file

[Juanma Barranquero]

On 1/9/07, Stephen Leake <stephen_leake@member.fsf.org> wrote:

> "if the file extension does not match the contents, it is more likely
> that this is a virus attack"

"More likely" than what? More likely than the alternative: that it is
not a virus attack?

I have mislabeled images in my hard disk: it's not unusual in my
experience to find an image in format A, with an extension suggesting
that it is in format B. So far, none of them have been virus attacks.

Are you proposing also that we reject (or warn about) a .PNG file
disguised as a .JPG, for example? We don't have a png-mode and a
jpeg-mode; the auto-detection and image opening machinery just return
image-mode. Should we redesign it to take that into account?
                    /L/e/k/t/u

Re: C file recoginzed as image file

[Vinicius Jose Latorre]

Juanma Barranquero wrote:
> On 1/9/07, Stephen Leake <stephen_leake@member.fsf.org> wrote:
>
>> "if the file extension does not match the contents, it is more likely
>> that this is a virus attack"
>
> "More likely" than what? More likely than the alternative: that it is
> not a virus attack?
>
> I have mislabeled images in my hard disk: it's not unusual in my
> experience to find an image in format A, with an extension suggesting
> that it is in format B. So far, none of them have been virus attacks.
>
> Are you proposing also that we reject (or warn about) a .PNG file
> disguised as a .JPG, for example? We don't have a png-mode and a
> jpeg-mode; the auto-detection and image opening machinery just return
> image-mode. Should we redesign it to take that into account?
>                    /L/e/k/t/u

What about the heuristic:

"if the file extension is not an image file extension and the contents 
is not an image, it is more likely that this is a virus attack"

??

Could a valid image file (GIF, JPG, PNG, etc.) with a valid file 
extension contain a virus?

Re: C file recoginzed as image file

[Stuart D. Herring]

>>> Aha, and how many more years would you be willing to wait for the
>>> release of Emacs 22.1?
>>
>> Does anyone care?  How many seasoned emacs users out there have not
>> been running emacs-cvs or emacs-snapshot for some years now?
>
> The majority.  Most people use the default software packaged into
> their distribution rather than switching the defaults or compiling for
> themselves.

Often because they don't own some computers that they use and thus are
disalllowed from using other than the "standard" software, or because they
simply haven't noticed how to acquire newer versions which (for all they
know) may or may not exist.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: C file recoginzed as image file

[Richard Stallman]

    > Assumption 2 is not impossible, but we don't know that anyone will
    > actually do it.

    It's not necessary for the virus to be specific to Emacs.  The bug can
    potentially be exploitable not matter which application the library is
    linked to.

There are two different possible ways to exploit such a bug:

1. Ways that operate directly on the file system, for which it
makes no difference from which program the library is run.

2. Ways that would directly try to corrupt Emacs.

If the virus works in the former way, it could do the same harm if you
display the image with qiv.  Protecting Emacs would be like stuffing
insulation in the crack under the door while the window is wide open.
Such exploits have to be blocked, and avoided, in the libraries
concerned.

For the second category, I see a couple of possibilities:

1. Validate the image data before calling the library (or better, in
the library).

2. Have Emacs run the library in a separate program rather than in
its own address space.  This reduces the Emacs case to the qiv case.

      Most, and probably all images on
    any given user's system are safe to display in Emacs, but shouldn't we
    guard against the time that they open that one specially crafted image
    which infects their system?

It is not clear to me what the answer to that question is.  It is
about the magnitude of X/Y where X and Y are both getting large.

Re: C file recoginzed as image file

[Richard Stallman]

    But they're heuristics as well.  A text file may start with the title
    "GIF89a file format".

That particular one is pretty unreliable, I agree.

    E.g. auto-mode-alist would give "don't know" for a file named "/b/c/foo" but
    would give the set { perl-mode, prolog-mode } for a file named
    "/b/c/foo.pl".  Then magic-mode-alist would give other sets of modes (based
    on things like the #! interpreter name, the -*- ... -*- cookie, etc...).
    If the intersection of the two sets is a singleton, then use that
    major-mode, otherwise query the user to decide whether to believe the file
    name or the contents.  After all, an inconsistently named file is generally
    a sign that there's something wrong, so it's good to prompt the user
    about it.

This is not sufficient for protection against bugs in libraries.  It
might be an improvement on general principles, but it is too complex
to do before the release.

For protection against bugs in libraries, we could consider writing
code in Emacs to thoroughly validate an image before displaying it.
That too is too much for before the release, but it would be the best
solution for after the release.

Re: C file recoginzed as image file

[Chris Moore]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 1/9/07, David Kastrup <dak@gnu.org> wrote:
>
>> A contrived example is enough in my book for countering "absolutely,
>> non-ambiguously".
>
> For countering what I was *not* saying, undoubtedly.

So what exactly were you saying?  You actually wrote:

> a file with a .c extension containing a GIF image is absolutely,
> non-ambiguously a GIF

If you meant:
  "a file [...] containing a GIF image absolutely, non-ambiguously
   contains a GIF image",
then that's tautological.  I can't believe that's what you meant to
say.

What I think you meant was:
  "a file [...] which we detect as containing a GIF image is
  absolutely, non-ambiguously a GIF image",
since that makes sense following your previous sentence about people
using non-default file names, and that's the statement which David's
contrived counterexample disproves.

Re: C file recoginzed as image file

[Juanma Barranquero]

On 1/9/07, Chris Moore <dooglus@gmail.com> wrote:

> then that's tautological.  I can't believe that's what you meant to
> say.

Yes, I was stating a tautology. That was the idea. The interesting
part was the bit about the ".c" extension, of course. Somehow people
seems to think (or at least, seem to be expressing in this thread the
thought) that files with .c extension (or whatever) can be *anything*
and we can do *nothing* to reliably detect them, just because some
contrived, absolutely non-realworld examples can be found. I was
saying: of course you can reliably detect many things.

The point is that contents detection is not infallible, but it is much
more reliable (if done correctly) than extension matching. I don't see
why we should treat the latter as more significant (or even equally
significant) that the former.

But all this is irrelevant to whether we should auto-detect images or
not, I think. The issue there is not that we cannot auto-detect them
reliably (we can, for any significant value of "reliably"), but that
we cannot detect whether they contain viruses.

                    /L/e/k/t/u

Re: C file recoginzed as image file

[Lennart Borgman (gmail)]

Richard Stallman wrote:

> For protection against bugs in libraries, we could consider writing
> code in Emacs to thoroughly validate an image before displaying it.
> That too is too much for before the release, but it would be the best
> solution for after the release.


Should not that code be in the image libraries instead?

Re: C file recoginzed as image file

[Richard Stallman]

      The right one is the
    cumulative probability that one of many images displayed over the
    period of use of Emacs will realize the threat.

There is no way to estimate this probability.

Re: C file recoginzed as image file

[Richard Stallman]

    Whichever way it is done it puts a new burdon on the user who have to 
    look for security updates to these image libraries and somehow update 
    them in case of a security problem with them. And in addition to this 
    there might be a long delay before the libraries are updated in gnuwin32.

Maybe so.

Using Microsoft libraries would be more convenient for users, but more
work for us, since they use incompatible calling conventions.
Furthermore, Microsoft software is famous for having more
vulnerabilities than GNU/Linux.  So I don't think that is a solution
to the security concerns.  It would enable us to say "It's Microsoft's
fault", but would not prevent the problem.

Re: C file recoginzed as image file

[Lennart Borgman (gmail)]

Richard Stallman wrote:
>     Whichever way it is done it puts a new burdon on the user who have to 
>     look for security updates to these image libraries and somehow update 
>     them in case of a security problem with them. And in addition to this 
>     there might be a long delay before the libraries are updated in gnuwin32.
> 
> Maybe so.
> 
> Using Microsoft libraries would be more convenient for users, but more
> work for us, since they use incompatible calling conventions.
> Furthermore, Microsoft software is famous for having more
> vulnerabilities than GNU/Linux.  So I don't think that is a solution
> to the security concerns.  It would enable us to say "It's Microsoft's
> fault", but would not prevent the problem.


Yes, of course a compatibility layer have to be created and I have no 
idea about what problems lies in that.

Microsoft is quite a bit famous for all the bugs, yes. However my main 
point is that the user will know what problems he faces. He/she does not 
have to consult several IT security sources to get the knowledge and 
that is an advantage.

There may be better solutions than my suggestion of course. I wonder how 
Firefox handles this? I can't remember for sure right now.

Re: C file recoginzed as image file

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Jan Nieuwenhuizen <janneke-list@xs4all.nl>
> Copies-To: None
> Date: Tue, 09 Jan 2007 12:12:06 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Aha, and how many more years would you be willing to wait for the
> > release of Emacs 22.1?
> 
> Does anyone care?

Obviously, I do.  And a few others do as well, including Richard, I
believe.

> How many seasoned emacs users out there have not
> been running emacs-cvs or emacs-snapshot for some years now?

Releasing an official version has benefits that cannot be had by
grabbing the CVS code.  And I have no doubts that many users would
hesitate to install a development version, or even build their own
from sources.  Not everyone is a hacker.

Re: C file recoginzed as image file

[Eli Zaretskii]

> Date: Tue, 09 Jan 2007 13:01:13 +0100
> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
> CC:  rms@gnu.org,  dooglus@gmail.com,  lekktu@gmail.com, 
>  c.a.rendle@gmail.com,  emacs-devel@gnu.org,  monnier@iro.umontreal.ca, 
>  storm@cua.dk,  eliz@gnu.org
> > 
> > it does not 
> > make sense to use a completely different set of image libraries on MS 
> > Windows than on other platforms.
> 
> In my opinion it definitively does. It enhances the security for the users.

Who says that Microsoft libraries are more secure than the ones we
use?  There's no evidence that this is even remotely true.

Re: C file recoginzed as image file

[Lennart Borgman (gmail)]

Eli Zaretskii wrote:
>> Date: Tue, 09 Jan 2007 13:01:13 +0100
>> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
>> CC:  rms@gnu.org,  dooglus@gmail.com,  lekktu@gmail.com, 
>>  c.a.rendle@gmail.com,  emacs-devel@gnu.org,  monnier@iro.umontreal.ca, 
>>  storm@cua.dk,  eliz@gnu.org
>>> it does not 
>>> make sense to use a completely different set of image libraries on MS 
>>> Windows than on other platforms.
>> In my opinion it definitively does. It enhances the security for the users.
> 
> Who says that Microsoft libraries are more secure than the ones we
> use?  There's no evidence that this is even remotely true.


Yes, who said that?

Re: C file recoginzed as image file

[Alan Mackenzie]

Hi, Jan!

On Tue, Jan 09, 2007 at 12:12:06PM +0100, Jan Nieuwenhuizen wrote:
> Eli Zaretskii <eliz@gnu.org> writes:

> > Aha, and how many more years would you be willing to wait for the
> > release of Emacs 22.1?

> Does anyone care?

Yes.  I do.  By now, I'm rather hoping the release is at most a few
weeks away.  I imagine a lot of people on this group are feeling the
stress of getting this release out. 

> How many seasoned emacs users out there have not been running
> emacs-cvs or emacs-snapshot for some years now?
 
Lots.  All my work colleaugues who use Emacs are using Emacs 21.  I use
Emacs 21 as my prime version; it's stable, and what I develop has to
work on old Emacsen too.

> Jan.

-- 
Alan Mackenzie.

Re: C file recoginzed as image file

[Stefan Monnier]

> The point is that contents detection is not infallible, but it is much
> more reliable (if done correctly) than extension matching. I don't see
> why we should treat the latter as more significant (or even equally
> significant) that the former.

Content detection sometimes works well, but sometimes not.  OTOH name-based
detection overall works more reliably because that's what Unix has used for
many years.
I think that giving precedence to one over the other is an error.


        Stefan

Re: C file recoginzed as image file

[Chris Moore]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> Are you proposing also that we reject (or warn about) a .PNG file
> disguised as a .JPG, for example?

About a year ago, it became apparent that MS Windows would execute
arbitrary code when displaying a specially constructed .wmf file.

Microsoft were quite slow issuing a fix for this vulnerability.  A lot
of companies blocked .wmf attachments on their firewalls in an attempt
to protect themselves.

As a result, the attackers simply renamed their dangerous .wmf files
to .jpg.  This continued to work because Windows looks at the file's
contents, sees that it's not really a JPG image but a WMF image, and
displays it using the vulnerable code.

The vulnerability was relatively well known at the time, and people
who knew about it knew not to attempt to view WMF images using
Windows.  What was more of a surprise was that .jpg and .gif files,
where double clicked could turn out to be WMF images in disguise.

I don't think we should make the same mistake that Windows makes of
silently ignoring the file extension.  The default should be to warn
the user if the contents disagree with the extension, and people who
don't want this warning should be able to turn it off using the
customize interface.

Re: C file recoginzed as image file

[Juanma Barranquero]

On 1/9/07, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> Content detection sometimes works well, but sometimes not.

Content detection usually works. After all, that's what an image
library does when it opens an image file and checks that the contents
seem OK, or Microsoft Word when it opens a .doc or .rtf file, etc.
Content detection based on regexp matching of a few bytes of the file
header is flaky, though ;)

> OTOH name-based
> detection overall works more reliably because that's what Unix has used for
> many years.

Well, nobody is suggesting throwing off `auto-mode-alist' and putting
`magic-mode-alist' in its place...

> I think that giving precedence to one over the other is an error.

I happen to disagree, but it is largely irrelevant to this discussion.
I prefer to concentrate my efforts in resolving the issue of the image
libraries, with the hope that we release Emacs 22 someday this year (I
almost wrote "month", but I don't want to be overly optimistic).

I stand for what I said earlier: let's disable image auto-detection,
add a note to NEWS (with big warnings about viruses, or whatever
people feels its necessary) detailing how to enable it, and get over
it.

                    /L/e/k/t/u

Re: C file recoginzed as image file

[Chris Moore]

Richard Stallman <rms@gnu.org> writes:

> There are two different possible ways to exploit such a bug:
>
> 1. Ways that operate directly on the file system, for which it
> makes no difference from which program the library is run.

This is the way that would almost certainly be used.

> If the virus works in the former way, it could do the same harm if you
> display the image with qiv.

Imagine that 'image' is called mymode.txt.  I would never think of
displaying it with qiv.  As far as I know, it's a text file, so I open
it in Emacs.  I might open it in vi (but that wouldn't display it as
an image) or maybe gedit (and that wouldn't, either).  I might use
'less' or 'cat' (if it was little).  They would both be safe, too.
Emacs is the only program I know which both:
  * I would consider using to open a .txt file and
  * would display it as an image without warning if it was a disguised
    image file.

Incidentally, I hadn't heard of qiv before, but I just installed it to
see what how it works.  It refuses to display images which are
disguised as .txt files:

  chris@trpaslik:/tmp$ qiv foo.jpg                [image displays]
  chris@trpaslik:/tmp$ cp foo.jpg foo.txt
  chris@trpaslik:/tmp$ qiv foo.txt
  qiv: cannot load any images.
  qiv (Quick Image Viewer) v2.0
  Usage: qiv [options] files ...
  See 'man qiv' or type 'qiv --help' for options.
  chris@trpaslik:/tmp$ 

This is sensible behaviour.  Displaying foo.txt as an image without
warning the user first isn't sensible, IMHO.

> Protecting Emacs would be like stuffing insulation in the crack
> under the door while the window is wide open.  Such exploits have to
> be blocked, and avoided, in the libraries concerned.

They are being.  Maybe the image libraries are all perfectly secure
now.  But just as we are still finding new bugs in Emacs after 30
years, I really don't think we've seen the last image library
vulnerability yet.

> 1. Validate the image data before calling the library (or better, in
> the library).

The libraries do take steps to validate the image data, but since they
are written and maintained by human beings, they are prone to contain
errors.

> 2. Have Emacs run the library in a separate program rather than in
> its own address space.  This reduces the Emacs case to the qiv case.

I don't think we need to worry about specific attacks against Emacs.

> It is not clear to me what the answer to that question is.  It is
> about the magnitude of X/Y where X and Y are both getting large.

When I used to run Windows, I ran a virus scanner.  It would scan
every executable file before writing it to disk and before running it,
and every few days it would scan around 200,000 files on my hard disk.
I ran it for over a year.  In all that time it only found and blocked
one virus.

In this case X/Y is 1/30,000,000 or so.  Was it worth wasting all that
time scanning 29,999,999 clean files to prevent just one virus being
installed?  What price is the average user willing to pay to prevent
having their keypresses logged and transferred to a stranger, or to
prevent their Internet banking details being stolen?

Re: C file recoginzed as image file

[Juanma Barranquero]

On 1/9/07, Chris Moore <dooglus@gmail.com> wrote:

> I don't think we should make the same mistake that Windows makes of
> silently ignoring the file extension.

OK. You're proposing a new feature, unrelated to image auto-detection
via contents. Currently, `set-auto-mode' sets the mode to `image-mode'
(via `auto-mode-alist'), and then the image handling code (image.el,
image-file.el, etc.) decides the correct image type.
                    /L/e/k/t/u

Re: C file recoginzed as image file

[Juanma Barranquero]

On 1/9/07, Vinicius Jose Latorre <viniciusjl@ig.com.br> wrote:

> Could a valid image file (GIF, JPG, PNG, etc.) with a valid file
> extension contain a virus?

If image type A can contain viruses, and a contaminated image of type
A is opened in Emacs from a file with extension for image type B,
Emacs would fall for the virus, because it would detect the correct
type (A) and use the A libraries to handle it. The extension is only
used to decide whether the file is an image or not, not what kind of
image.

                    /L/e/k/t/u

Re: C file recoginzed as image file

[Lennart Borgman (gmail)]

Chris Moore wrote:

> In this case X/Y is 1/30,000,000 or so.  Was it worth wasting all that
> time scanning 29,999,999 clean files to prevent just one virus being
> installed?  What price is the average user willing to pay to prevent
> having their keypresses logged and transferred to a stranger, or to
> prevent their Internet banking details being stolen?


Absolutely. The important figure here is 1. 1 virus found (or more).

Re: C file recoginzed as image file

[Chris Moore]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> Eli Zaretskii wrote:

>> Who says that Microsoft libraries are more secure than the ones we
>> use?  There's no evidence that this is even remotely true.

> Yes, who said that?

You said that using the MS libraries would "enhance the security for
the users", which sounds kind of similar.

But maybe your point is that:

 the risk of using both MS image libraries and free software image
 libraries together is greater than the risk of using only MS image
 libraries

Re: C file recoginzed as image file

[Lennart Borgman (gmail)]

Chris Moore wrote:
> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
> 
>> Eli Zaretskii wrote:
> 
>>> Who says that Microsoft libraries are more secure than the ones we
>>> use?  There's no evidence that this is even remotely true.
> 
>> Yes, who said that?
> 
> You said that using the MS libraries would "enhance the security for
> the users", which sounds kind of similar.
> 
> But maybe your point is that:
> 
>  the risk of using both MS image libraries and free software image
>  libraries together is greater than the risk of using only MS image
>  libraries


Yes, sort of. That is of course true. But the point I was trying to make 
is that it is more easy for the users to update the libraries and know 
what vulnerabilities there are if only MS image libraries are used.

This will be better if there is an automatic way of updating gnuwin32 
image libraries of course. (If they are updated at the download site.)

One of the main troubles with MS libraries has been that it has taken a 
long time for them to fix the bug sometimes. But lately my impression is 
that this has improved much. On the other hand has the security threats 
grown maybe even more. Quick reaction to threats is necessary.

Re: C file recoginzed as image file

[Chris Moore]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> Chris Moore wrote:
>
>> In this case X/Y is 1/30,000,000 or so.  Was it worth wasting all that
>> time scanning 29,999,999 clean files to prevent just one virus being
>> installed?  What price is the average user willing to pay to prevent
>> having their keypresses logged and transferred to a stranger, or to
>> prevent their Internet banking details being stolen?
>
> Absolutely. The important figure here is 1. 1 virus found (or more).

I just noticed - I think I may be been doing the same thing that
annoyed Richard a couple of days ago; what he called "sarcastic".  I
don't mean to ask "was it worth wasting all that time ..." - of course
it was.  Seems I speak wih forked-tongue.

Re: C file recoginzed as image file

[Richard Stallman]

    > Even if there are no free image libraries there are image libraries 
    > that comes with MS Windows.

    If they are not Free, we would not consider using them.

All our software uses non-free Windows libraries when running on MS
Windows.  To use the Windows library for displaying GIF is not out
of the question.

But this is not a feasible change to make now, so there is no use
discussing the question any further for now.

Re: C file recoginzed as image file

[Richard Stallman]

    > For protection against bugs in libraries, we could consider writing
    > code in Emacs to thoroughly validate an image before displaying it.
    > That too is too much for before the release, but it would be the best
    > solution for after the release.


    Should not that code be in the image libraries instead?

It would be good for the image libraries to do that.
And we might independently want to make Emacs do that,
so as not to trust the image libraries.

Re: C file recoginzed as image file

[Lennart Borgman (gmail)]

Chris Moore wrote:
> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
> 
>> Chris Moore wrote:
>>
>>> In this case X/Y is 1/30,000,000 or so.  Was it worth wasting all that
>>> time scanning 29,999,999 clean files to prevent just one virus being
>>> installed?  What price is the average user willing to pay to prevent
>>> having their keypresses logged and transferred to a stranger, or to
>>> prevent their Internet banking details being stolen?
>> Absolutely. The important figure here is 1. 1 virus found (or more).
> 
> I just noticed - I think I may be been doing the same thing that
> annoyed Richard a couple of days ago; what he called "sarcastic".  I
> don't mean to ask "was it worth wasting all that time ..." - of course
> it was.  Seems I speak wih forked-tongue.


Mistakes makes things very much clearer sometimes ;-)

Re: C file recoginzed as image file

[Stefan Monnier]

> I stand for what I said earlier: let's disable image auto-detection,
> add a note to NEWS (with big warnings about viruses, or whatever
> people feels its necessary) detailing how to enable it, and get over
> it.

Agreed,


        Stefan

Re: C file recoginzed as image file

[Stephen Leake]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 1/9/07, Stephen Leake <stephen_leake@member.fsf.org> wrote:
>
>> "if the file extension does not match the contents, it is more likely
>> that this is a virus attack"
>
> "More likely" than what? More likely than the alternative: that it is
> not a virus attack?

Yes.

Obviously, this only makes sense in a weighting scheme, where "more
likely" is a useful concept.

In the current code, the choices are all binary, so this kind of
heuristic isn't much help

> I have mislabeled images in my hard disk: it's not unusual in my
> experience to find an image in format A, with an extension suggesting
> that it is in format B. So far, none of them have been virus attacks.

Ok.

> Are you proposing also that we reject 

no

> (or warn about) 

yes, but allow users to easily disable the warning.

> a .PNG file disguised as a .JPG, for example? We don't have a
> png-mode and a jpeg-mode; the auto-detection and image opening
> machinery just return image-mode. Should we redesign it to take that
> into account? 

Perhaps. Certainly not now. It depends on how much effort we want to
devote to preventing virus attacks, versus all the other things we
need to do.

-- 
-- Stephe

Re: C file recoginzed as image file

[Stephen Leake]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> I stand for what I said earlier: let's disable image auto-detection,
> add a note to NEWS (with big warnings about viruses, or whatever
> people feels its necessary) detailing how to enable it, and get over
> it.

That sounds like the best thing to do now, to me.

-- 
-- Stephe

Re: C file recoginzed as image file

[Stephen J. Turnbull]

Richard Stallman writes:

 >     stephen wrote:  The right one is the
 >     cumulative probability that one of many images displayed over the
 >     period of use of Emacs will realize the threat.
 > 
 > There is no way to estimate this probability.

I apologize for contradicting you, but there are many ways of
estimating any probability, some more accurate than others, some
quantitative, some qualitative.

Getting qualitative estimates need not require any expertise at all.
In fact, several people have made implicit estimates in this thread
already.  Eg, Chris Moore's and Lennart Borgman's are evidently "too
high to ignore".  Granted, those are not very precise estimates.  But
such qualitative estimates are the ones that are relevant to
decision-making.

Here the salient estimate is "much higher than the probability that
any single image will realize the threat", which implies that your
implicit estimate of the risk of single images is a large
underestimate of the relevant risk.

That still may not be enough to make it worth committing substantial
Emacs resources to address the issue before the release, but it would
be sad if the decision were made on the basis of a severe
underestimate of the risk.

Re: C file recoginzed as image file

[Jason Rumney]

Richard Stallman wrote:
>     > Even if there are no free image libraries there are image libraries 
>     > that comes with MS Windows.
>
>     If they are not Free, we would not consider using them.
>
> All our software uses non-free Windows libraries when running on MS
> Windows.  To use the Windows library for displaying GIF is not out
> of the question.
>   
I was under the impression that to use non-free libraries, they had to 
be part of the OS. Any image libraries that are on Windows machines by 
default are likely to be part of the web browser, as people who have 
tried to uninstall the web browser from Windows have found that they 
lose a lot of functionality such as displaying images.

Re: C file recoginzed as image file

[Lennart Borgman (gmail)]

Jason Rumney wrote:

> I was under the impression that to use non-free libraries, they had to 
> be part of the OS. Any image libraries that are on Windows machines by 
> default are likely to be part of the web browser, as people who have 
> tried to uninstall the web browser from Windows have found that they 
> lose a lot of functionality such as displaying images.

Does not MS claim that IE is a part of MS Windows?

Re: C file recoginzed as image file

[Chris Moore]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> One of the main troubles with MS libraries has been that it has
> taken a long time for them to fix the bug sometimes. But lately my
> impression is that this has improved much.

Nice timing. :)

Just yesterday Microsoft's monthly 'patch Tuesday' included only 4 of
the planned 8 updates, leaving unpatched a 0-day Word vulnerability
that is actively being exploited in the wild:

  http://www.eweek.com/article2/0,1895,2081067,00.asp

Re: C file recoginzed as image file

[Lennart Borgman (gmail)]

Chris Moore wrote:
> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
> 
>> One of the main troubles with MS libraries has been that it has
>> taken a long time for them to fix the bug sometimes. But lately my
>> impression is that this has improved much.
> 
> Nice timing. :)
> 
> Just yesterday Microsoft's monthly 'patch Tuesday' included only 4 of
> the planned 8 updates, leaving unpatched a 0-day Word vulnerability
> that is actively being exploited in the wild:
> 
>   http://www.eweek.com/article2/0,1895,2081067,00.asp


Oh yeah! ;-) -- all that power and still that difficult.

But this is better than before when it could take half a year or more 
before any patch was at the horizon.

Re: C file recoginzed as image file

[Richard Stallman]

     > There is no way to estimate this probability.

    I apologize for contradicting you, but there are many ways of
    estimating any probability, some more accurate than others, some
    quantitative, some qualitative.

Make all the estimates you want.  Just be aware I will not put too
much stock in any estimate.

Re: C file recoginzed as image file

[Richard Stallman]

    > All our software uses non-free Windows libraries when running on MS
    > Windows.  To use the Windows library for displaying GIF is not out
    > of the question.
    >   
    I was under the impression that to use non-free libraries, they had to 
    be part of the OS.

The GPL allows use of non-free libraries distributed with major
components of the system.  If these libraries normally come with
Windows, that is good enough.  It doesn't matter what part of Windows
they are considered to be part of.

Re: C file recoginzed as image file

[Giorgos Keramidas]

On 2007-01-08 19:01, Richard Stallman <rms@gnu.org> wrote:
>       And in case there's a vulnerability in libpng, he would not
>     expect to be in danger when opening something.jpg.
> 
> He probably won't expect to be in danger when opening something.png,
> because he probably won't know about the vulnerability.
> 
>     For most GNU/Linux systems, the vulnerable image libraries will be
>     replaced by fixed versions via (automatic) online updates soon.
> 
> That is true for many users, but there is a substantial fraction that,
> like me, hardly ever updates software.

That's very true.

There isn't much Emacs can do to protect against problems with
potentially buggy versions of the image libraries, though.  We
can make Emacs *prompt* the user when something looks ``odd'',
but how do we define ``odd''?

Re: C file recoginzed as image file

[Sascha Wilde]

Giorgos Keramidas <keramida@ceid.upatras.gr> wrote:
> On 2007-01-08 19:01, Richard Stallman <rms@gnu.org> wrote:

> There isn't much Emacs can do to protect against problems with
> potentially buggy versions of the image libraries, though.  We
> can make Emacs *prompt* the user when something looks ``odd'',
> but how do we define ``odd''?

To determine a file is `odd' would probably (most likely) need a full
fledged parser for each file format in question, and even more: our
parsers would have to be proofed bug free in spite of the system
libraries -- so this is no option...

On the other hand: this problem is not Emacs specific by any means:
It's indeed a serious problem that parsing data files from unknown
sources is nearly as much an security risk as running programs from
unknown sources.[0]

The kind of "solution" I would like to see is that Emacs should never
display images (or play sounds for that matter...) without being
explicitly asked to: it is obvious that using M-x image-mode or M-x
thumbs will result in showing the images, but when opening a FOO.xpm
file or viewing a mail it isn't.  For the later cases there should be
config variables which determine if auto-viewing is wanted (possible
values nil t 'ask) which should default to ask.

just my 2¢
sascha

[0] at least on to days mainstream systems whether free or
    proprietary.  I will leave out the rant on the OS designs
    and programming languages I would blame for this kind of
    problems...  ;-)
-- 
Sascha Wilde

"There is no reason why anyone would want a computer in their home"
Ken Olson, DEC, 1977

Re: C file recoginzed as image file

[Richard Stallman]

    There isn't much Emacs can do to protect against problems with
    potentially buggy versions of the image libraries, though.  We
    can make Emacs *prompt* the user when something looks ``odd'',
    but how do we define ``odd''?

Each image format has a standard.  If the format does not allow
arbitrary programs, then it is straightforward (though perhaps
substantial work) to validate an image completely.

Re: C file recoginzed as image file

[Stefan Monnier]

>     There isn't much Emacs can do to protect against problems with
>     potentially buggy versions of the image libraries, though.  We
>     can make Emacs *prompt* the user when something looks ``odd'',
>     but how do we define ``odd''?

> Each image format has a standard.  If the format does not allow
> arbitrary programs, then it is straightforward (though perhaps
> substantial work) to validate an image completely.

The bug in the lib may be triggered by a valid file (typically: valid but
with some parameters much larger than expected).  There's no evidence that
our validation code wouldn't be itself vulnerable to various attacks
(although writing it in a strongly typed language like Lisp would eliminate
a whole bunch of potential security holes, compared to C, but note that
Elisp is not bug-free either).


        Stefan

Re: C file recoginzed as image file

[Giorgos Keramidas]

On 2007-01-14 18:23, Richard Stallman <rms@gnu.org> wrote:
>     There isn't much Emacs can do to protect against problems with
>     potentially buggy versions of the image libraries, though.  We
>     can make Emacs *prompt* the user when something looks ``odd'',
>     but how do we define ``odd''?
> 
> Each image format has a standard.  If the format does not allow
> arbitrary programs, then it is straightforward (though perhaps
> substantial work) to validate an image completely.

Right.  We may eventually have to do this substantial amount of work,
but I think our safest bet is to make Emacs do what Stefan proposed,
i.e. have image-mode turned off by default and let the user enable it
explicitly when they feel it's safe to do so.

Re: C file recoginzed as image file

[Giorgos Keramidas]

On 2007-01-09 08:11, Stephen Leake <stephen_leake@member.fsf.org> wrote:
>Jan Nieuwenhuizen <janneke-list@xs4all.nl> writes:
>> Eli Zaretskii <eliz@gnu.org> writes:
>>> Aha, and how many more years would you be willing to wait for the
>>> release of Emacs 22.1?
>
> Clearly that would be for after this release.
>
>> Does anyone care?  How many seasoned emacs users out there have not
>> been running emacs-cvs or emacs-snapshot for some years now?
>
> Everyone on my team at work, except me.
>
> Emacs 22 is a mild productivity boost over Emacs 21. I hope my team
> can benefit from it soon.

Same here.

A lot of people at work still use Emacs 21.X, even though I put some
time into updating Emacs 22 snapshots configured with --prefix=/opt/emacs
and make them available to everyone interested.

Eli has a point.  Some users are not willing to use a package, until it
has been officially marked as 'release quality'.

Re: C file recoginzed as image file

[Giorgos Keramidas]

On 2007-01-09 11:57, Vinicius Jose Latorre <viniciusjl@ig.com.br> wrote:
> Could a valid image file (GIF, JPG, PNG, etc.) with a valid file
> extension contain a virus?

Depending on what you mean by `a valid image', yes.

It is conceivable that someone with knowledge about the exact
format *and* a bug in one of the image libraries can construct a
valid image file which takes advantage of a bug in the image
processing libraries; typically a lack of range or size checks,
which can cause buffer overflows or other similar problems in
languages that allow this to happen.

Re: C file recoginzed as image file

[Richard Stallman]

I agree.  I think Emacs should detect images and enable Image mode, or
perhaps Image minor mode; but it should not initially display them as
images.

Would someone like to implement this, then ack?

Re: C file recoginzed as image file

[Jason Rumney]

Richard Stallman wrote:
> I agree.  I think Emacs should detect images and enable Image mode, or
> perhaps Image minor mode; but it should not initially display them as
> images.
>   
When I looked at image-minor-mode, it wasn't clear to me that you could 
avoid any problems by simply delaying display of the image. It looked 
like the image was parsed and cached immediately regardless of whether 
it was displayed or not. So the change may not be as simple as it looks.

Re: C file recoginzed as image file

[Richard Stallman]

    The bug in the lib may be triggered by a valid file (typically: valid but
    with some parameters much larger than expected).  There's no evidence that
    our validation code wouldn't be itself vulnerable to various attacks

If the checking code is thorough, checking every datum for validity
before using its value, then it will not be vulnerable.  The reason
the libraries have vulnerabilities is that their authors are thinking
about displaying a valid image, rather than detecting an invalid one.

The point about failures on valid images is a valid point, but I don't
see what we can do about it at this level.  Perfection is not
attainable.  Anyway, those bugs are likely to be found and fixed
because they would fail on real images.

Re: C file recoginzed as image file

[Juanma Barranquero]

On 1/15/07, Jason Rumney <jasonr@gnu.org> wrote:

> When I looked at image-minor-mode, it wasn't clear to me that you could
> avoid any problems by simply delaying display of the image. It looked
> like the image was parsed and cached immediately regardless of whether
> it was displayed or not.

At least on Windows, it would work. I put OutputDebugString calls in
init_*_functions() from src/image.c, and then, after

  M-: (setq image-type-auto-detectable nil) RET
  C-x C-f image-file-without-extension RET
  M-x image-minor-mode RET

no function from the corresponding image library has been called
(because in fact the image library has not been loaded yet). Only
after C-c C-c does the debug message appear in the output.

                    /L/e/k/t/u

Re: C file recoginzed as image file

[Jason Rumney]

Juanma Barranquero wrote:
> Only after C-c C-c does the debug message appear in the output.
OK. I didn't look closely enough to determine for sure, just thought I'd 
raise the alarm for whoever implemented this to check that their fix 
really prevented the bugs it was intended to. It looks like it is 
probably a straightforward case of avoiding displaying the image then.

Re: C file recoginzed as image file

[Juanma Barranquero]

On 1/19/07, Jason Rumney <jasonr@gnu.org> wrote:

> OK. I didn't look closely enough to determine for sure, just thought I'd
> raise the alarm for whoever implemented this to check that their fix
> really prevented the bugs it was intended to. It looks like it is
> probably a straightforward case of avoiding displaying the image then.

This is an example patch that implements the idea discussed. It's as
simple as it gets. I'm not entirely happy because I don't like the
idea of perverting `magic-mode-alist' to set a minor mode instead of a
major mode, but perhaps it can be accepted as a special deal for the
potentially-dangerous image libraries.

Of course, if this is accepted some other function's docstrings would
need a little bit of polishing.

                    /L/e/k/t/u



Index: lisp/files.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/files.el,v
retrieving revision 1.877
diff -u -2 -r1.877 files.el
--- lisp/files.el	6 Jan 2007 21:50:14 -0000	1.877
+++ lisp/files.el	19 Jan 2007 16:32:03 -0000
@@ -2128,5 +2128,5 @@

 (defvar magic-mode-alist
-  `((image-type-auto-detected-p . image-mode)
+  `((image-type-auto-detected-p . image-minor-mode)
     ;; The < comes before the groups (but the first) to reduce backtracking.
     ;; TODO: UTF-16 <?xml may be preceded by a BOM 0xff 0xfe or 0xfe 0xff.
Index: lisp/image-mode.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/image-mode.el,v
retrieving revision 1.15
diff -u -2 -r1.15 image-mode.el
--- lisp/image-mode.el	29 Aug 2006 13:02:53 -0000	1.15
+++ lisp/image-mode.el	19 Jan 2007 16:52:14 -0000
@@ -127,6 +127,6 @@
 (defun image-toggle-display ()
   "Start or stop displaying an image file as the actual image.
-This command toggles between showing the text of the image file
-and showing the image as an image."
+This command toggles between showing the text of the image file and
+showing the image as an image.  NOTE: This can be a SECURITY RISK."
   (interactive)
   (if (get-text-property (point-min) 'display)
@@ -180,4 +180,6 @@
 	  (message "Repeat this command to go back to displaying the file as
text")))))

+(put 'image-toggle-display 'disabled t)
+
 (provide 'image-mode)

Re: C file recoginzed as image file

[Richard Stallman]

Do we really want to go so far as to disable the command
image-toggle-display?  That will be a big pain for any users that
actually want to use the feature.

Re: C file recoginzed as image file

[Juanma Barranquero]

On 1/20/07, Richard Stallman <rms@gnu.org> wrote:

> Do we really want to go so far as to disable the command
> image-toggle-display?

The whole point of using image-minor-mode for images is that the user
doesn't display an image without being conscious that it could be a
security risk.

> That will be a big pain for any users that
> actually want to use the feature.

Only the first time, or am I missing something?

                    /L/e/k/t/u

Re: C file recoginzed as image file

[Richard Stallman]

    > That will be a big pain for any users that
    > actually want to use the feature.

    Only the first time, or am I missing something?

You can enable it permanently, or just once, it is true.
But if the idea is that the user will enable it permanently
the first time, then what good does it do?

Re: C file recoginzed as image file

[Jason Rumney]

Richard Stallman wrote:
> You can enable it permanently, or just once, it is true.
> But if the idea is that the user will enable it permanently
> the first time, then what good does it do?
>   

Can we give a specific reason in the message the user sees when they 
first run the command? Or do all disabled commands get the same message?
If the former, then we could tell the user why it is disabled by 
default. This serves to make them aware of the dangers of viewing image 
files from untrusted sources, and they will then think twice before 
displaying images in future. I don't think they need to be reminded 
every time, the fact that Emacs does not display images automatically 
should be reminder enough.

If we can't give a specific reason, I don't see any value in disabling 
the command.

Re: C file recoginzed as image file

[Juanma Barranquero]

On 1/21/07, Jason Rumney <jasonr@gnu.org> wrote:

> Can we give a specific reason in the message the user sees when they
> first run the command? Or do all disabled commands get the same message?

The first three lines of the disabled command are shown in the "this
command is disabled" message. That's why I added the NOTE: in my
example patch. Reworking the command's docstring would be better, of
course.

                    /L/e/k/t/u

Re: C file recoginzed as image file

[Richard Stallman]

If the `disabled' property is a string, Emacs shows that string.