COMMAND

	Digital signature for Adobe Acrobat/Reader plug-in can be forged

SYSTEMS AFFECTED

	These versions of Adobe Acrobat/Reader are vulnerable on Win32  platform
	(Windows 95/98/ME/NT/2000/XP):
	
	  Adobe Acrobat 4.x
	  Adobe Acrobat 5.x
	  Adobe Acrobat Reader 4.x
	  Adobe Acrobat Reader 5.x
	

PROBLEM

	ElcomSoft   Co.Ltd.   [info@elcomsoft.com]    [http://www.elcomsoft.com]
	advisory :
	
	 http://www.kb.cert.org/vuls/id/549913
	
	
	 Description of the vulnerability
	 - --------------------------------
	
	Adobe  provides  plug-ins  SDK  and  plug-ins  certification   (signing)
	mechanism.
	
	Adobe  Acrobat  Reader  can  only  load  plug-ins  signed  with  "Reader
	Integration Key", and in some critical  cases  both  Adobe  Acrobat  and
	Adobe Acrobat Reader load only plug-ins certified as  "trusted"  (signed
	by Adobe itself), that is, plug-ins that respect the  security  settings
	of the document.
	
	But certificate checking  algorithm  makes  decision  about  certificate
	validity  upon  plug-in's  Portable  Executable  header  only.  So,  any
	correction in plug-in code will pass unnoticed.
	
	Moreover, it is possible to modify certified plug-in to load  any  other
	plug-in, and pass control to it. Hence, any plug-in could be  loaded  as
	if it was certified by Adobe, making certification completely useless.
	
	We were able  to  write  a  'fake'  plug-in  "fakecert.api"  which  does
	nothing, but being loaded by Adobe Acrobat (and Reader) 4 and 5  as  the
	certified one even in 'trusted' mode, though we  don't  have  a  'Reader
	Integration Key' (this plug-in has  been  provided  only  to  Adobe  and
	CERT). When  installed  into  'plug_ins'  subfolder,  plug-in  is  being
	loaded every time when Adobe Acrobat (or Reader)  starts,  and  shows  a
	simple message box.
	
	Technical information (how it was written) follows:
	
	If we have completed 'IMAGE_NT_HEADERS peHdr'  structure,  here  is  the
	data that goes through MD5 hashing routine (in the given order):
	
	WORDpeHdr.FileHeader.NumberOfSections
	WORDpeHdr.FileHeader.Machine
	DWORD peHdr.FileHeader.PointerToSymbolTable
	DWORD peHdr.FileHeader.NumberOfSymbols
	WORDpeHdr.FileHeader.SizeOfOptionalHeader
	WORDpeHdr.FileHeader.Characteristics
	WORDpeHdr.OptionalHeader.Magic
	BYTEpeHdr.OptionalHeader.MajorLinkerVersion
	BYTEpeHdr.OptionalHeader.MinorLinkerVersion
	DWORD peHdr.OptionalHeader.SizeOfCode;
	DWORD peHdr.OptionalHeader.SizeOfInitializedData;
	DWORD peHdr.OptionalHeader.SizeOfUninitializedData;
	DWORD peHdr.OptionalHeader.AddressOfEntryPoint;
	DWORD peHdr.OptionalHeader.BaseOfCode;
	DWORD peHdr.OptionalHeader.BaseOfData;
	DWORD peHdr.OptionalHeader.SizeOfImage;
	DWORD peHdr.OptionalHeader.SizeOfStackReserve;
	DWORD peHdr.OptionalHeader.SizeOfStackCommit;
	DWORD peHdr.OptionalHeader.LoaderFlags;
	DWORD peHdr.OptionalHeader.NumberOfRvaAndSizes;
	for (i = 0; i < IMAGE_NUMBEROF_DIRECTORY_ENTRIES; i++) {
	IMAGE_DATA_DIRECTORY peHdr.OptionalHeader.DataDirectory[i];
	}
	
	The   important   elements   are:   number   of   sections,   size    of
	code/data/image,   entry   point   address,   and   IMAGE_DATA_DIRECTORY
	(addresses and sizes of import table, export table, relocations etc).
	
	It is really easy to defeat all these  checks  by  just  'applying'  his
	characteristics  to  our  plug-in  (which  we   would   like   to   make
	'certified').
	
	Number of sections: as far as Acrobat does  not  verify  the  attributes
	(name, RVA, address in the file, length,  flags)  and  contents  of  the
	sections, we can merge a few sections  into  a  single  one,  or  create
	additional (empty) sections as needed, so the total number  of  sections
	will be the same as in the real (certified) plug-in.
	
	Size of code/data/image:  there  are  two  workarounds.  First,  we  can
	select the Adobe plug-in that is large enough (so  our  own  code  would
	fit into it); or make the code small and  move  the  most  functionality
	into the external DLLs.
	
	Needed  entry  point  address  can  be  achieved  by   inserting   'jmp'
	instruction at the address of the certified plug-in.  Some  manual  work
	might be needed (if  there  is  some  important  code  at  this  address
	already).
	
	No problems at all with IMAGE_DATA_DIRECTORY. In most cases,  PE  loader
	just ignores the size set in Directory. Besides, the mandatory data  for
	that address is just a small import/export table,  and  all  other  data
	could be stored in some other place.  So  it  is  enough  (to  fool  the
	certification checks) to put resources/Relocations/Import/Export at  the
	needed addresses, and fix some references manually.
	
	
	 The impact of this vulnerability
	 - --------------------------------
	
	1. One of the purposes of  Adobe  plug-in  certification  system  is  an
	ability to identify an author/developer of any plug-in used  by  Acrobat
	Reader. However, using the method described above,  it  is  possible  to
	use  bogus  digital  certificate  to  forge  digital  signature,  or  to
	'certify' any plug-in using certificate that actually  has  been  issued
	to another (trusted, well-known) developer such  as  SoftLock,  FileOpen
	etc., so making impossible to identify the real authorship of plug-in.
	
	2. Plug-ins have full access to the system, i.e. can  read/write  files,
	execute any code etc. The 'trusted' mode in Adobe Acrobat/Reader  should
	be safe (by design), because only  Adobe-certified  plug-ins  are  being
	loaded; however, as shown above, any plug-in can  be  manually  'signed'
	as Adobe's, and so it will be loaded  regardless  security  settings  in
	Adobe software. All plug-ins have some kind of  start-up  code  that  is
	being executed  immediately  when  Acrobat/Reader  is  started  (and  so
	plug-in is  loaded),  but  that  code  may  include  malicious/arbitrary
	routines such as viruses,  trojan  horses  etc.  Alternatively,  plug-in
	itself can perform such useful operations, but contain a malicious  code
	that will be activated only when specific PDF  file  (e.g.  downloadable
	from the Internet, or sent by email as attachment) is being opened.
	
	3. 'Trusted' mode is activated  automatically  by  Adobe  Acrobat/Reader
	when it loads documents that are protected using  various  DRM  (Digital
	Rights Management) schemes such as WebBuy, InterTrust DocBox etc  --  to
	prevent protected contect from being  saved  with  protection  stripped.
	However, a plug-in with 'fake' certificate can be loaded anyway, and  so
	it will be able  to  do  anything  with  DRM-protected  documents,  e.g.
	altering or removing security options.

SOLUTION

	none yet