summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7903.txt
blob: 957b1f12d415939ac925c42ed8f65260a35d88c0 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
Independent Submission                                        S. Leonard
Request for Comments: 7903                                 Penango, Inc.
Category: Informational                                   September 2016
ISSN: 2070-1721


                       Windows Image Media Types

Abstract

   This document registers media types for certain image formats
   promulgated in Microsoft Windows, namely image/wmf, image/x-wmf,
   image/emf, image/x-emf, and image/bmp for use with Windows Metafile,
   Enhanced Metafile, and Windows Bitmap formats.  Originally designed
   for Microsoft Windows 2.0 and 3.0, these image files are intended to
   be portable between applications and devices, and they may contain
   both vector and raster graphics.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This is a contribution to the RFC Series, independently of any other
   RFC stream.  The RFC Editor has chosen to publish this document at
   its discretion and makes no statement about its value for
   implementation or deployment.  Documents approved for publication by
   the RFC Editor are not a candidate for any level of Internet
   Standard; see Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc7903.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.






Leonard                       Informational                     [Page 1]
^L
RFC 7903                Windows Image Media Types         September 2016


Table of Contents

   1. Introduction ....................................................2
      1.1. Windows Metafiles ..........................................2
      1.2. Windows Bitmaps ............................................3
   2. Windows Metafile Media Type Registration Application ............4
   3. Enhanced Metafile Media Type Registration Application ...........6
   4. Windows Bitmap Media Type Registration Application ..............9
   5. IANA Considerations ............................................11
   6. Security Considerations ........................................11
   7. References .....................................................11
      7.1. Normative References ......................................11
      7.2. Informative References ....................................11
   Author's Address ..................................................12

1.  Introduction

1.1.  Windows Metafiles

   Long before the invention of Scalable Vector Graphics, Microsoft
   Corporation recognized the value of recording images in a format that
   its applications and operating systems could easily render
   irrespective of the output device.  With the release of Windows 3.0,
   Microsoft released its Windows Metafile (WMF) format, which can
   contain vector and raster graphics in one package.  As a binary
   format that needed to work on 16-bit machines, WMF is comprised of a
   sequence of record structures.  Each record contains drawing
   commands, object definitions, and configuration settings.  When a
   metafile is processed, the image can be rendered on a display, output
   to a printer or plotter, stored in memory, or saved to some
   persistent storage.  Reflecting the relationship to the Windows
   Graphics Device Interface (GDI) API, WMF data is "played" to a
   playback device context in the same manner that PostScript content is
   treated as an executable program that results in the output of the
   original document.

   As Microsoft's first 32-bit operating system, Windows NT 3.1
   introduced an overhaul to the Windows API ("Win32") and the in-memory
   formats upon which those APIs relied.  The Enhanced Metafile (EMF)
   format was created at this time, using 32-bit values instead of WMF's
   16-bit values.  In Windows XP, Microsoft extended EMF with "EMF+",
   adding support for Windows GDI+.

   Many implementations of WMF and EMF were created because of Windows'
   commercial success in the 1990s.  A large body of free and
   commercially available clip art and other artwork exists in this
   format.  Furthermore, WMF content appears non-normatively in certain




Leonard                       Informational                     [Page 2]
^L
RFC 7903                Windows Image Media Types         September 2016


   standards (e.g., [OOXML]); the usage is common enough that an
   implementer would almost certainly need to support it for basic
   interoperability.

   Microsoft publicly documented the WMF format as early as the 1992
   Windows 3.1 SDK.  Since 2007, Microsoft has released the format
   specifications [MS-WMF], [MS-EMF], and [MS-EMF+] under its Open
   Specification Promise [MS-OSP].

1.2.  Windows Bitmaps

   Long before the invention of Portable Network Graphics (PNG),
   Microsoft Corporation and IBM Corporation needed to record images in
   a format that their applications and operating systems could easily
   render on low-end machines (Intel 80286).  The resulting "BMP" format
   contains a single raster graphic with basic header fields that can be
   easily mapped (or "blitted") to locations in memory.  As computing
   moved from 16-bit to 32-bit, BMP evolved to contain 32-bit
   structures.  As the '90s wore on, the venerable BMP got boosts with
   support for additional color spaces, color profiles, and compression
   formats.  The same basic format can be used to convey 2-bit black-
   and-white bitmaps with a 1-bit alpha mask from the '80s, and full-
   color Ultra HD images on leading-edge displays.  BMP is a building
   block of other formats, including Windows Metafiles, Windows Icons,
   and Windows Cursors.

   Many implementations of BMP were created because of Windows'
   commercial success in the 1990s.  Usage of the format for interchange
   has declined since the advent of PNG (for lossless raster graphics)
   and JPEG (for lossy raster graphics); however, a large body of free
   and commercially available BMP artwork exists.  Since Windows Icons
   are a building block of "favicon.ico" web technology, an implementer
   would almost certainly need to support this format for basic
   interoperability.

   Microsoft publicly documented the BMP format as early as the 1992
   Windows 3.1 SDK (in the Windows Metafile documentation).  Since 2007
   Microsoft has released the format specification [MS-WMF], which
   includes most components of the Windows Bitmap format, under its Open
   Specification Promise [MS-OSP].  See Section 2.2.2.9 of [MS-WMF]
   (DeviceIndependentBitmap Object).  BMP data begins with a
   BITMAPFILEHEADER and is followed by one of the bitmap headers
   (BITMAPINFOHEADER, BITMAPV4HEADER, or BITMAPV5HEADER), optional color
   table data, bitmap data, and optional profile data, in that order
   [BMPSTOR].






Leonard                       Informational                     [Page 3]
^L
RFC 7903                Windows Image Media Types         September 2016


   Implementers need to be aware of the [MICE] vulnerability, and to
   guard against it.  Some details are included in the completed
   registration template.

2.  Windows Metafile Media Type Registration Application

   Type name: image

   Subtype name: wmf

   Required parameters: None.

   Optional parameters:

      DEFAULT_CHARSET: The character set intended when the CharacterSet
         enumeration (see the WMF specification) specifies
         DEFAULT_CHARSET.  The value of this parameter is a charset from
         the IANA "Character Sets" registry
         <http://www.iana.org/assignments/character-sets>.  When this
         parameter is not specified, DEFAULT_CHARSET has the following
         meaning in the WMF specification: "a character set based on the
         current system locale; for example, when the system locale is
         United States English, the default character set is
         ANSI_CHARSET" (which is Windows-1252, more or less).  That is,
         when not specified, the default character set is system
         dependent.  This optional parameter is new to this registration
         and may not enjoy widespread support for some time.  Therefore,
         EMF instead of WMF (or if necessary under the circumstances,
         embedded EMF within WMF) is a more sensible choice when text is
         present.

   Encoding considerations: Binary.

   Security considerations:

      The Windows Metafile format's security history is punctuated in
      2005-2006 with the disclosure of the Metafile Image Code Execution
      ("MICE") vulnerability.  MICE won the 2007 Pwnie Award for "Mass
      0wnage" and "Breaking the Internet".  The official Microsoft
      security bulletin describes that the flaw occurs because Windows
      Metafiles can set the SETABORTPROC value of the MetafileEscapes
      enumeration (accessible via the META_ESCAPE record), allowing for
      arbitrary code execution, i.e., "active content".

      Windows Metafiles can contain Enhanced Metafiles using the
      META_ESCAPE_ENHANCED_METAFILE record; thus, the security
      considerations of EMF apply to WMF.




Leonard                       Informational                     [Page 4]
^L
RFC 7903                Windows Image Media Types         September 2016


      Windows Metafiles are historically very buggy.  As the original
      intent was to replicate Windows GDI calls, flaws in GDI, or in a
      display or printer driver implementing the backend to GDI, could
      be exploitable.  WMF implementations not backed by Windows GDI
      have different risks: namely, while a malicious WMF author may not
      consider the non-Windows GDI implementation as a primary target,
      WMF has many "corner case" records for which an implementation's
      processing may not have received the same level of scrutiny as the
      Windows implementation.  "Fuzzing" the implementation is
      appropriate.

      As a "basic" image format, the image/wmf media type does not
      employ executable content and provides no facilities for privacy
      or integrity.

   Interoperability considerations:

      Windows Metafile is the original 16-bit metafile format; it was
      released in 1990 at what some computer historians might consider
      the "zenith" of the desktop publishing revolution.  Accordingly,
      there is a large body of free and commercially available clip art
      that is still in use, either independently or embedded in
      productivity documents (word processing documents, desktop
      publishing documents, slideshows, presentations, spreadsheets, and
      workbooks).  For example, references to WMF content appear (non-
      normatively) in Office Open XML.  To say that support for this
      format is necessary for interoperability would not be an
      understatement.

      Accommodations for comments or arbitrary data storage in Windows
      Metafiles are virtually non-existent.  However, Windows Metafiles
      can contain Enhanced Metafiles using the
      META_ESCAPE_ENHANCED_METAFILE record, so an implementation that
      handles Windows Metafiles is also expected to handle enhanced
      metafile content.  Windows Metafiles can store and output text
      strings (see META_TEXTOUT and META_EXTTEXTOUT records), but the
      encodings of the strings may be ambiguous.  Unicode encodings are
      not possible without the DEFAULT_CHARSET parameter defined in this
      registration.

      The previously unregistered type image/x-wmf is also in wide use.
      Accordingly, it is registered as a deprecated alias.

   Published specification:

      WMF: Microsoft Corporation, "[MS-WMF]: Windows Metafile Format",
      v20160714 (Rev 13.1), July 2016,
      <http://msdn.microsoft.com/library/cc250370>.



Leonard                       Informational                     [Page 5]
^L
RFC 7903                Windows Image Media Types         September 2016


   Applications that use this media type:

      Office productivity applications; clip art applications; desktop
      publishing applications; some web browsers (e.g., Internet
      Explorer).

   Fragment identifier considerations: None.

   Additional information:

      Deprecated alias names for this type: image/x-wmf

      Magic number(s): D7 CD C6 9A (little-endian DWORD 0x9AC6CDD7)

      File extension(s): .wmf

      Macintosh file type code(s):
         None.  A uniform type identifier (UTI) of "com.microsoft.wmf"
         is suggested.

   Person & email address to contact for further information:

      Sean Leonard <dev+ietf@seantek.com>

   Restrictions on usage: None.

   Author/Change controller: Sean Leonard <dev+ietf@seantek.com>

   Intended usage: COMMON

   Provisional registration? No

3.  Enhanced Metafile Media Type Registration Application

   Type name: image

   Subtype name: emf

   Required parameters: None.

   Optional parameters: None.

   Encoding considerations: Binary.








Leonard                       Informational                     [Page 6]
^L
RFC 7903                Windows Image Media Types         September 2016


   Security considerations:

      Enhanced Metafiles are not afflicted with the Metafile Image Code
      Execution ("MICE") vulnerability.  There has been no public
      disclosure of vulnerabilities specific to EMF or EMF+ to date.
      Neither EMF nor EMF+ are designed to contain "active content".
      Nonetheless, Enhanced Metafiles can contain Encapsulated
      PostScript (EPS) data; thus, the security considerations of
      PostScript processing may also apply to EMF.

      As the original intent was to replicate Windows GDI calls, flaws
      in GDI, or in a display or printer driver implementing the backend
      to GDI, could be exploitable with maliciously crafted EMF content.
      EMF implementations not backed by Windows GDI have different
      risks: namely, while a malicious EMF author may not consider the
      non-Windows GDI implementation as a primary target, EMF has many
      "corner case" records for which an implementation's processing may
      not have received the same level of scrutiny as the Windows
      implementation.  "Fuzzing" the implementation is appropriate.  It
      is also possible that EMF+ data is "safe" while EMF data contains
      an exploit (or vice versa); the EMF+-aware implementation (such as
      an application designed for GDI+ on Windows XP or above) would
      skip the "unsafe" data while another implementation would fall
      prey to the exploit.

      As a "basic" image format, the image/emf media type does not
      employ executable content and provides no facilities for privacy
      or integrity.

   Interoperability considerations:

      Enhanced Metafile is the 32-bit metafile format; it was released
      in 1992 along with Windows NT 3.1.  There is a large body of free
      and commercially available clip art that is still in use, either
      independently or embedded in productivity documents (word
      processing documents, desktop publishing documents, slideshows,
      presentations, spreadsheets, and workbooks).  To say that support
      for this format is necessary for interoperability would not be an
      understatement.

      Enhanced Metafiles have extensive accommodations for comments and
      arbitrary data storage.  Enhanced Metafiles can store and output
      text strings.  Mercifully, the encodings of these strings are
      well-defined.  Record examples include EMR_EXTTEXTOUTA (US-ASCII),
      EMR_EXTTEXTOUTW (UTF16-LE), EMR_POLYTEXTOUTA (US-ASCII),
      EMR_POLYTEXTOUTW (UTF16-LE), and EMR_SMALLTEXTOUT (UTF16-LE or the
      low-order 8 bits of UTF16-LE -- effectively ISO-8859-1 --
      depending on ETO_SMALL_CHARS).



Leonard                       Informational                     [Page 7]
^L
RFC 7903                Windows Image Media Types         September 2016


      Enhanced Metafiles can contain Encapsulated PostScript (EPS) data
      in the EpsData object.  The FormatSignature EPS_SIGNATURE
      (0x46535045, in little-endian) is used instead of
      ENHMETA_SIGNAUTRE (0x464D4520, in little-endian) in such a case.

      Windows XP introduced the GDI+ API, along with EMF+.  EMF+ is
      actually an embedded format in which GDI+ commands are stored as
      EMF comment records (EMR_COMMENT_EMFPLUS record type).  Content
      containing EMF+ data can be identified as "EMF+ Only" (only EMF+;
      the EMF records are not sufficient to reconstitute the drawing) or
      "EMF+ Dual" (both EMF records alone or EMF+ records alone, when
      played back, are sufficient to reconstitute the drawing).  Support
      for EMF+ records may not be as extensive as support for the
      original EMF records.

      The previously unregistered type image/x-emf is also in wide use.
      Accordingly, it is registered as a deprecated alias.

   Published specification:

      EMF: Microsoft Corporation, "[MS-EMF]: Enhanced Metafile Format",
      v20160714 (Rev 12.0), July 2016,
      <http://msdn.microsoft.com/library/cc230514>.

      EMF+: Microsoft Corporation, "[MS-EMFPLUS]: Enhanced Metafile
      Format Plus Extensions", v20160714 (Rev 14.1), July 2016,
      <http://msdn.microsoft.com/library/cc230724>.

   Applications that use this media type:

      Office productivity applications; clip art applications; desktop
      publishing applications; some web browsers (e.g., Internet
      Explorer).

   Fragment identifier considerations: None.

   Additional information:

      Deprecated alias names for this type: image/x-emf

      Magic number(s):
         01 00 00 00 (little-endian DWORD 0x00000001), corresponding to
         the EMR_HEADER Type field.
         The next field (EMR_HEADER Size) should be at least 88 (little-
         endian DWORD 0x00000050).

      File extension(s): .emf (for both EMF and EMF+ content)




Leonard                       Informational                     [Page 8]
^L
RFC 7903                Windows Image Media Types         September 2016


      Macintosh file type code(s):
         None.  A uniform type identifier (UTI) of "com.microsoft.emf"
         is suggested.

   Person & email address to contact for further information:

      Sean Leonard <dev+ietf@seantek.com>

   Restrictions on usage: None.

   Author/Change controller: Sean Leonard <dev+ietf@seantek.com>

   Intended usage: COMMON

   Provisional registration? No

4.  Windows Bitmap Media Type Registration Application

   Type name: image

   Subtype name: bmp

   Required parameters: None.

   Optional parameters: None.

   Encoding considerations: Binary.

   Security considerations:

      Bitmaps have a mostly unremarkable security history.

      Because BMP data can encapsulate JPEG or PNG data (BI_JPEG, BI_PNG
      values of the Compression enumeration in Section 2.1.1.7 of the
      WMF specification), the security considerations of JPEG and PNG
      processing may also apply to BMP.

      As a "basic" image format, the image/bmp media type does not
      employ executable content and provides no facilities for privacy
      or integrity.

   Interoperability considerations:

      Uncompressed Windows Bitmaps can be rather large.  If there is a
      need to compress an image, modern applications should consider
      emitting JPEG or PNG data instead of embedding them in BMP
      payloads.




Leonard                       Informational                     [Page 9]
^L
RFC 7903                Windows Image Media Types         September 2016


   Published specification:

      WMF: Microsoft Corporation, "[MS-WMF]: Windows Metafile Format",
      v20160714 (Rev 13.1), July 2016,
      <http://msdn.microsoft.com/library/cc250370>.

      BMP: Microsoft Corporation, "Bitmap Storage", MSDN ID dd183391,
      <http://msdn.microsoft.com/library/dd183391>.

   Applications that use this media type:

      Office productivity applications; clip art applications; desktop
      publishing applications; web browsers; graphics processing
      applications.

   Fragment identifier considerations: None.

   Additional information:

      Magic number(s):
         42 4D ("BM"), meaning "bitmap".  The next field
         (BITMAPFILEHEADER bfSize) is a little-endian DWORD indicating
         the size of the bitmap content in bytes.

      File extension(s): .bmp, .dib

      Macintosh file type code(s):
         "BMP ", "BMPf", or "BMPp".  Apple has promulgated a uniform
         type identifier (UTI) of "com.microsoft.bmp".

   Person & email address to contact for further information:

      Sean Leonard <dev+ietf@seantek.com>

   Restrictions on usage: None.

   Author/Change controller: Sean Leonard <dev+ietf@seantek.com>

   Intended usage: COMMON

   Provisional registration? No










Leonard                       Informational                    [Page 10]
^L
RFC 7903                Windows Image Media Types         September 2016


5.  IANA Considerations

   IANA has registered the media types image/wmf, image/x-wmf,
   image/emf, image/x-emf, and image/bmp in the standards tree using the
   applications provided in Sections 2, 3, and 4 of this document.

6.  Security Considerations

   See the registration templates for their respective security
   considerations.

   The Metafile Image Code Execution (MICE) vulnerability won the 2007
   Pwnie Award for "Mass 0wnage" and "Breaking the Internet" [PWNIES07].

7.  References

7.1.  Normative References

   [BMPSTOR]  Microsoft Corporation, "Bitmap Storage", MSDN ID dd183391,
              <http://msdn.microsoft.com/library/dd183391>.

   [MS-EMF]   Microsoft Corporation, "[MS-EMF]: Enhanced Metafile
              Format", v20160714 (Rev 12.0), July 2016,
              <http://msdn.microsoft.com/library/cc230514>.

   [MS-EMF+]  Microsoft Corporation, "[MS-EMFPLUS]: Enhanced Metafile
              Format Plus Extensions", v20160714 (Rev 14.1), July 2016,
              <http://msdn.microsoft.com/library/cc230724>.

   [MS-WMF]   Microsoft Corporation, "[MS-WMF]: Windows Metafile
              Format", v20160714 (Rev 13.1), July 2016,
              <http://msdn.microsoft.com/library/cc250370>.

7.2.  Informative References

   [MICE]     Microsoft Corporation, "Vulnerability in Graphics
              Rendering Engine Could Allow Remote Code Execution
              (912919)", MS06-001, V1.0, January 2006,
              <https://technet.microsoft.com/library/security/ms06-001>.

   [MS-OSP]   Microsoft Corporation, "Open Specification Promise",
              February 2007, <https://msdn.microsoft.com/
              en-us/openspecifications/dn646765>.

   [OOXML]    Ecma International, "Office Open XML File Formats",
              Standard ECMA-376, Fourth Edition, ISO/IEC 29500, December
              2012, <http://www.ecma-international.org/publications/
              standards/Ecma-376.htm>.



Leonard                       Informational                    [Page 11]
^L
RFC 7903                Windows Image Media Types         September 2016


   [PWNIES07] Pwnie Awards LLC, "Winners of Pwnie Awards 2007", 2007,
              <http://pwnies.com/archive/2007/winners/>.

Author's Address

   Sean Leonard
   Penango, Inc.
   5900 Wilshire Boulevard
   21st Floor
   Los Angeles, CA  90036
   United States of America

   Email: dev+ietf@seantek.com
   URI:   http://www.penango.com/





































Leonard                       Informational                    [Page 12]
^L