COMMAND

	Microsoft build of the java virtual machine  is  succeptible  to  remote
	attacks

SYSTEMS AFFECTED

	All builds of the Microsoft VM up to and including  build  5.0.3805  are
	affected by these vulnerabilities.
	

	

PROBLEM

	Jouko   Pynnonen   [jouko@solutions.fi]   of   Online   Solutions    Ltd
	[http://www.solutions.fi] in an original advisory found here :
	

	 http://www.solutions.fi/index.cgi/?lang=eng

	

	1) The constructor of class com.ms.jdbc.odbc.JdbcOdbc  can  be  used  to
	load any DLL from the local filesystem. The constructor takes  a  String
	parameter which is used to form a name of  a  JDBC-ODBC  driver  DLL  to
	load. The DLL name is formed by concatenating the string  "MSJDBC10"  to
	the parameter. However, if the constructor's parameter string ends  with
	a null byte, the rest of the string is ignored,  so  the  DLL  name  and
	path can be freely chosen by a malicious applet. For  instance  to  load
	the DLL "C:\mydll.dll" the applet can do
	

	  new com.ms.jdbc.odbc.JdbcOdbc("C:\\mydll\000");

	

	Loading an arbitrary DLL equals to running  any  code  on  the  program,
	because the initialization code of the DLL  may  contain  any  code;  it
	could read or write to files, download programs from  internet  and  run
	them, install a  backdoor or a keyboard logger, etc.
	

	In order to the attack to work, the attacker has to upload  a  malicious
	DLL to the client's system and know it's exact location there. This  can
	be done by using some of the other,  yet  unpatched  vulnerabilities  in
	the Microsoft's Java implementation.
	

	MS02-52 corrected this flaw by hardcoding the  DLL  name  "MSJDBC10"  in
	the Java code. The parameter given to the constructor  is  now  ignored.
	This was reported to Microsoft on 14 Aug 2002.
	

	

	2) Methods of some classes of the pacakge com.ms.osp are  accessible  by
	any Applet. Some of them may be used to compromise the client system.
	

	MS02-52 corrected this  flaw  by  restricting  access  to  the  package.
	Invoking the methods now generates an IllegalAccessException. This  flaw
	was reported to Microsoft on 10 Aug 2002.
	

	

	3) The class com.ms.jdbc.odbc.JdbcOdbc contains some methods  which  are
	declared "protected native" and which take ODBC  handles  as  parameter.
	Due to the visibility declaration, any Applet may declare  a  new  class
	which is inherited from the JdbcOdbc class  and  gain  access  to  these
	protected native methods. It can then call the machine language code  in
	these methods and pass them carefully chosen  parameters  to  cause  the
	native code to modify or read  memory  in  arbitrary  memory  addresses.
	This may allow the applet to be able to read the process's memory  space
	in ways it shouldn't be able to, or to direct the program  execution  to
	malicious "shellcode". This hasn't been confirmed with an  exploit  yet,
	but similar, yet unpatched vulnerabilities in some  other  Java  classes
	allow execution of arbitrary code.  If  the  methods  are  invoked  with
	random parameters, Internet Explorer crashes when it tries to access  or
	modify memory in illegal addresses.
	

	MS02-52 corrects this vulnerability by restricting the  access  to  this
	class for trusted Applets only. This was reported  to  Microsoft  on  29
	Aug 2002.
	

	

	4) The class com.ms.jdbc.odbc.JdbcOdbcDriver has an error in a  security
	check, which allows any Applet  to  access  ODBC  data  sources  of  the
	client's system. The method connect() of the class is  used  to  connect
	to a data source. Before  establishing  the  connection  it  performs  a
	security check to see if the caller is trusted. Only  a  trusted  caller
	is supposed to  be  able  to  connect  to  the  local  datasources,  ie.
	databases,  because  it's  obviously  a  big  problem   if   an   applet
	originating from a random web page may access the  databases  which  are
	configured on your system.
	

	The check is done in the method  trusted()  which  is  called  from  the
	method acceptsURL() which is  called  from  the  connect()  method.  The
	trustedness of the code is checked by checking if the  caller  has  file
	write permission. Untrusted applets don't have file  permissions  so  if
	the permission exists, then the caller is supposed  to  be  trusted  and
	permitted to connect to ODBC data sources. When  an  ordinary  untrusted
	applet does the connect() call, the trusted() method check fails and  it
	prints a SecurityException on the  Java  console.  If  ODBC  tracing  is
	enabled, it also logs that security check of  JDBC-ODBC  bridge  failed.
	The error happens after this: even  after  setting  a  boolean  flag  to
	false, it's again set to value true in the end of the method  trusted().
	In other words the method always returns true, and thinks  every  applet
	is trusted at that point. Regardless of the error  message,  the  applet
	can connect to databases configured on the local system  (Control  Panel
	-> ODBC data sources) and access the data in them. The attacker  has  to
	know the data source name the applet connects to. The data  sources  may
	also require additional authentication.
	

	The flawed code  also  exists  in  Sun's  code,  but  isn't  exploitable
	because Sun's Java Plug-in doesn't allow  untrusted  applets  to  access
	the class at all. In order to access the JDBC-ODBC classes in the  Sun's
	implementation, the Applet needs additional privileges  granted  by  the
	user, in which case the error in the security  check  doesn't  have  any
	impact.
	

	Microsoft's  security  bulletin  doesn't  mention  anything  about  this
	rather  serious  vulnerability,  but  the   patch   corrects   this   by
	restricting the access to the  package  com.ms.jdbc.odbc,  ie.  changing
	the restrictions to what they are in Sun's implementation. This bug  was
	reported to Microsoft on 29 Aug 2002.

SOLUTION

	These issues  are  corrected  by  the  patch  MS-02-52  which  Microsoft
	released September 18. The patch and Microsoft's bulletin are  available
	at
	

	http://www.microsoft.com/technet/security/bulletin/MS02-052.asp

	

	The patch doesn't fix all of the vulnerabilities reported,  so  enabling
	Java support in the Internet Zone even after applying  the  patch  gives
	the possibility for a malicious Java Applet to  gain  control  over  the
	system.