home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / hacking / internet / javabug.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  7.6 KB  |  176 lines
  1.  
  2.           NASIRC BULLETIN B-96-24         June 10, 1996
  3.  
  4.                      JAVA Class Loader Hole Recently Discovered
  5.            ===========================================================
  6.               NASA Automated Systems Incident Response Capability
  7.                  __    __      __      ___   ___  ____     ____
  8.                 /_/\  /_/|    /_/\    / _/\ /_/| / __/ \  / __/\
  9.                 | |\ \| ||   /  \ \   | /\/ | || | /\ \/  | | \/
  10.                 | ||\ \ ||  / /\ \ \   \ \  | || |_\/ /\  | |
  11.                 | || \ \|| / /--\ \ \ /\_\\ | || | |\ \ \ | \_/\
  12.                 |_|/  \_|//_/    \_\/ \/__/ |_|/ |_| \_\/ \___\/
  13.             Serving NASA and the International Aerospace Communities
  14.            ===========================================================
  15.  
  16.            This bulletin reports a recently announced security vulner-
  17.            ability.    It   may   contain   a   workaround or software
  18.            patch.  Bulletins should be considered urgent  as  vulnera-
  19.            bility information is likely to be widely known by the time
  20.            a patch is issued or other solutions are developed.
  21.  
  22.            ===========================================================
  23.  
  24.  
  25.           NASIRC has recently received new information about another attack
  26.           method using the class loader of Java.  This attack enables
  27.           execution of native machine instructions with Java capable
  28.           browsers.  This discovery expands the scope of vulnerable systems
  29.           initially identified for Netscape Version 2.02 browsers, reported
  30.           in NASIRC Bulletin B-96-11-C.
  31.  
  32.  
  33.  
  34.   PROBLEM DESCRIPTION
  35.  
  36.  
  37.           Attacks on the class loader allow running native code in current
  38.           Java implementations.  Running native code allows machine
  39.           specific instructions to be executed by the delivered applet.
  40.           This presents a problem since an attack was successful in
  41.           deleting files.  An exploit has been written for Appletviewer and
  42.           HotJava; versions for Netscape and Oracle PowerBrowser are also
  43.           possible, although more difficult.
  44.  
  45.  
  46.  
  47.  
  48.   SYSTEMS AFFECTED
  49.  
  50.  
  51.           The native code vulnerability applies to currently available Java
  52.           capable browsers.
  53.  
  54.           The following systems are known to be vulnerable to the new
  55.           attack:
  56.  
  57.           *       Netscape up to and including Versions 2.02 and 3.0beta4
  58.                   (except Windows 3.x).
  59.  
  60.           *       Oracle PowerBrowser for Win32.
  61.  
  62.           *       HotJava 1.0 beta.
  63.  
  64.           *       "appletviewer" from Java Development Kit, up to and
  65.                   including Version 1.0.2.
  66.  
  67.  
  68.  
  69.   RECOMMENDED ACTION
  70.  
  71.  
  72.           NASIRC reiterates its recommendation to use all Internet browsers
  73.           with all Java and JavaScript features disabled.  If the known
  74.           host is a trusted site, then enabling Java or JavaScript after
  75.           the initial page is displayed and then using the "reload" option
  76.           to invoke Java or JavaScript is a safer approach.  Before leaving
  77.           a trusted page, the Java and JavaScript features should again be
  78.           disabled.
  79.  
  80.  
  81.  
  82.  
  83.   Technical Paper about Java Security
  84.  
  85.  
  86.           Drew Dean, Edward Felten, and Dan Wallach, Department of Computer
  87.           Science, Princeton University, have written a paper, "Java
  88.           Security: From HotJava to Netscape and Beyond," presented at the
  89.           IEEE Symposium on Security and Privacy on Oakland, California, on
  90.           May 6-8, 1996.
  91.  
  92.           This paper gives a technical description of the weaknesses that
  93.           exist in the security methods used to build Java and that can be
  94.           obtained from the following site.
  95.  
  96.  
  97.                   http://www.cs.princeton.edu/sip/pub/secure96.html
  98.  
  99.  
  100.  
  101.           The conclusion is as follows:
  102.  
  103.                   "6. Conclusion
  104.  
  105.                    Java is an interesting new programming language
  106.                    designed to support the safe execution of applets
  107.                    on Web pages. We and others have demonstrated an
  108.                    array of attacks that allow the security of both
  109.                    HotJava and Netscape to be compromised. While many
  110.                    of the specific flaws have been patched, the
  111.                    overall structure of the systems leads us to believe
  112.                    that flaws will continue to be found. The absence of
  113.                    a well-defined, formal security policy prevents the
  114.                    verification of an implementation.
  115.  
  116.                    We conclude that the Java system in its current form
  117.                    cannot easily be made secure. Significant redesign of
  118.                    the language, the bytecode format, and the runtime
  119.                    system appear to be necessary steps toward building a
  120.                    higher-assurance system. Without a formal basis,
  121.                    statements about a systems security cannot be
  122.                    definitive.
  123.  
  124.                    The presence of flaws in Java does not imply that
  125.                    competing systems are more secure. We conjecture that
  126.                    if the same level of scrutiny had been
  127.                    applied to competing systems, the results would have
  128.                    been similar.  Execution of remotely-loaded code is
  129.                    a relatively new phenomenon, and more work is required
  130.                    to make it safe."
  131.  
  132.  
  133.  
  134.  
  135.           -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  136.                   ACKNOWLEDGMENTS: Fred Blonder of NASIRC for identifying
  137.                           this information, Alan Coopersmith of UC Berkeley
  138.                           for submitting this to
  139.                           best-of-security@suburbia.net, and David Hopwood
  140.                           of Oxford University, England, for maintaining a
  141.                           Web site of Netscape vulnerability information.
  142.                           Drew Dean, Edward Felten, and Dan Wallach,
  143.                           Department of Computer Science, Princeton
  144.                           University, for publishing "Java Security: From
  145.                           HotJava to Netscape and Beyond."
  146.  
  147.  
  148.                   BULLETIN AUTHOR: Jordan Gottlieb
  149.           -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  150.  
  151.  
  152.           This advisory may be forwarded without restriction.  Persons
  153.           within the NASA community or operating in support of a NASA
  154.           contract may contact NASIRC with any questions about this
  155.           advisory.
  156.  
  157.               Telephone: 1-800-7-NASIRC (1-800-762-7472) FAX: 1-301-441-1853
  158.               International: +1-301-441-4398         STU III: 1-301-982-5480
  159.               Internet E-Mail: nasirc@nasa.gov
  160.               24-Hour/Emergency Pager: 1-800-759-7243/Pin:2023056
  161.               WWW: http://nasirc.nasa.gov/NASIRC_home.html
  162.               FTP: nasirc.nasa.gov, login "anonymous"
  163.  
  164.           Anyone requiring assistance or wishing to report a security
  165.           incident but not operating in support of NASA may contact the
  166.           Forum of Incident Response and Security Teams (FIRST), an
  167.           international organization of incident response teams, to
  168.           determine the appropriate team.  A list of FIRST member
  169.           organizations and their constituencies may be obtained by
  170.           sending E-mail to "docserver@first.org" with an empty "subject"
  171.           line and a message body containing the line "send first-contacts"
  172.           or via WWW at  http://www.first.org/  .
  173.  
  174. -------------------------------------------------------------
  175.  
  176.