THREE RECENT SECURITY INCIDENTS

Three recent internet security incidents illustrate why massive multi-dimensional empowerment of users of the internet is needed and may be urgent.

Yesterday, June 10th, a notice, posted in the usenet forum named "muc.lists.bugtraq", reported that a 'security hole' had been found in recent versions of the browser named Internet Explorer for the Macintosh. The security gap exists the Apple 'JAVA engine' program MRJ prior to the recent version 2.2 (systems running MAcOS9 and MRJ 2.2 are not affected).

On April 19th, Peacefire.org published a web page containing the following introductory comment: "This page demonstrates a security hole in Netscape Communicator 4.x which allows a malicious Web site to read HTML files on a user's hard drive (including the user's bookmarks file and browser cache files, which reveal Web-surfing history). The exploit works by setting a cookie whose value contains JavaScript code."

In October of last year, Princeton Secure Internet Programming Lab announced the discovery of a "bug in Microsoft's bytecode verifier [which] allows a malicious applet [to] proceed to do anything it wants to do on the victim's computer. For example, a malicious applet might . . . read private data, modify or delete files, or eavesdrop on the user's activities. . . . As of October 11, 1999, all recent versions of Microsoft's JVM for Windows appear to be vulnerable, so users of recent versions of Internet Explorer are affected by this flaw. . . .We have reported this flaw to Microsoft and they are working to address it."

Back in 1996, the author of the NSClean program, sold by NSClean Privacy Software, made the following remarks in testimony before the Federal Trade Commission: "It has been demonstrated recently that there are a number of security issues in all of the popular browsers that allow a remote site to access the contents of a user's machine through the use of rogue ActiveX, Java and Javascript programs. The presence of such detailed information on the usage of a person's computer could allow this information to be gathered and used."

Keep in mind that this was back in 1996. Sun Microsystems has devoted major efforts to make JAVA, and the derivative emulator programs that browsers use to interpret Javascript, solid protectors of security from the time JAVA appeared on the scene about 1995.

Indeed, the frequency of security gaps in JAVA or Javascript (the latter used by browsers) seems to have declined markedly compared to 1996-97. Yet, security holes that can help bad guys snoop on you and me continue to be found.

These discoveries of new routes for privacy invasions involving the internet browsers and JAVA are still happening despite the fact that computer science experts have been grappling with internet security issues for over five years.

WHAT'S THE BASIC PROBLEM HERE?

Here is the basic problem, which is not in any way limited to JAVA.

The entire internet security apparatus relies upon barriers, or gates, built in software. Rock solid defense against unwanted breaching of those gates requires that software designers imagine all the possible sequences of computer instructions and combined data that might become challenges to the security-checking system.

Well, it is conceivable that the number of possible combinations of machine instructions (code) and data that night become routes for such challenges runs into the hundreds, if not thousands. Even though finding one such route is rare event the number of possible routes to creating a security gap could still be huge.

Hence, there seems little chance that the software designers will ever be effective in imagining all the possible sequences of computer instructions (code) in combination with data that will present unanticipated situations to the security-checking system.

This reality arises not merely from bugs. It also arises from the inherent complexity of the 'zillions' of possible paths of computer behavior arising from variations in the combinations of instructions and data presented to the computer.

IT'S MORE SERIOUS THAN COOKIES -- WHAT SHOULD WE DO?

Therefore, all the scary talk about invasions of privacy on the internet focused on cookies may be substantially mis-directed. Yes, a network of cookies concerning your computer that are placed at different web sites you visit, sets the stage for a juicy dossier to be secretly compiled about your revealed preferences and aspects of your life style.

But Javscripts seem to be a much greater source of concern about continued chances that your privacy will be plundered on the internet. This is so because Javascript code becomes an EXECUTING PROGRAM on your computer, albeit ALMOST ALWAYS within software-designed limits that prevent bad guys from snooping around in your electronic environment in the search for superior targeted marketing opportunities.

To address these realities, massive multi-dimensional empowerment of users of the internet is the best available answer, even if this answer is not perfect. The dimensions of empowerment include: (1) more widespread basic knowledge about the various technologies being used to gather and sell information about your demographics and some aspects of your behavior, (2) improved access to the means to thwart these technologies from our homes when we so wish, and (3) better spread of practical know-how in applying the thwarting methods in with our own computers.

These are very old issues for big companies that hire full-time IT staffs. They have built firewalls that tend to be breached only due to operator and client negligence of one kind or another -- e.g. easy-to-guess passwords. But what about the millions of small businesses that cannot afford to hire such people. And, further, what about the systems we use at home to access the internet? It seems clear we all need the protections provided by the IT staffs to the big companies!

And let's forget about the idea that future legislation will do any more than help out in some degree, depending upon active cooperation of the major stakeholders. No matter what the future legislation warrants as restraints upon wanton privacy invasions, we have in place a fundamentally flawed technology for thwarting the bad guys at the point where internet browsers, related operating system features, and related security software features are built.

The nature of the fundamental flaw is outlined above -- software developers cannot anticipate all of the hundreds of combinations of machine instructions and data that could create routes for security breaches. And even if they could, an effective program to block all those routes at the browser-design or operating-system-design stages might be too expensive to be marketable.

It needs to be emphasized that JAVA and Javascript are in no way culprits as a result of careless programming work. On the contrary, the available literature shows beyond doubt that Sun Microsystems (JAVA creator) were conscious of the need to build strong security checking into JAVA from Day One. As the text that follows illustrates, their efforts over the years have been elaborate and impressive from an intellectual-accomplishment viewpoint.

Their problem is that they are trying to climb up the face of a very high cliff with lots of smooth rocks to cause slippage along the way.

WHY WE SHOULD WORRY WHEN THE WEB BROWSER IS INTEGRATED WITH THE OPERATING SYSTEM

According to the author of NSClean, their task of building effective security is compounded by the integration of a web browser into an operating system. On this issue, he wrote as follows back in 1996: "The greatest risk of all to personal privacy on the internet however comes from the integration of browsers into the operating system itself. At one time, browsers were external applications which did not have hooks directly into the computer's operating system. Java and javascript applets were kept isolated from the operating system entirely which meant that the only risks to privacy were those voluntarily or unwittingly given up by the user. . . . Now we are faced with [efforts to place the] Internet Explorer product directly into the operating system where no walls of separation will exist which will serve to protect the user against unauthorized rummaging through the most personal and private parts of their computers. Netscape has now similarly provided capabilities in their Javascript version 1.2 which similarly places the entire contents of a user's machine at the hands of outsiders who are savvy enough to use these controls to access the operating system itself. To my own sensibilities, this constitutes a violation of the fifth amendment whereby one's own computer fulfills the prophecy of Orwell's '1984.'
   Both companies insist that they will only allow such deep penetration of a person's systems to those who provide a "signed" document which will identify the perpetrator after the damage is done. This is woefully inadequate as such documents can be readily forged. The user is merely handed a familiar box warning them that they are accepting an applet that could be dangerous. Many users disregard all such warnings as they are delivered all too frequently and most people do not read them before hitting the "OK" button to proceed. "

In essence, then Javascript has allowed web browsing experience to be more entertaining, and web site designers to create more meaningful interactions with visitors to their sites. But it has compounded the security problem. The integration of the browser into the operating system may take us one more step further away from security-rich internet browsing, while no doubt offering more opportunities for programmers to create rewarding internet browsing experiences. If only the marketers had not decided that this is a wonderful basis to take targeted marketing to new levels of effectiveness -- the reason for all the snooping that is going on.

IT'S THE BAD GUYS, STUPID

The security holes by themselves are totally harmless -- like a loaded gun sitting a policeman's holster. The issue here is that the world is filled with bad guys only too happy to grab that gun and pull the trigger in the effort to make gains for themselves and their colleagues.

     This has happened over and and over again in history. It is scarcely credible that we have somehow managed to confine those behaviors and those kinds of determined people into our historic past.

A SHORT COURSE ON SUN MICROSYSTEM'S GREAT EFFORTS TO BE HELPFUL

For the remainder of this article, we will provide synopses of educational material about JAVA that has been gleaned from several web sites, notably that of Sun Microsystems; who should be thanked for being so open about the realities we all face.

In 1996, JAVASoft summarized Sun's security strategy as follows: "Our goal is to provide security in four ways. First, you'll know the source of the applets you're running (authentication); second, you'll be assured that the bits you receive over the wire haven't been altered (integrity); third, you'll be assured that the network connection is confidential (encryption); fourth, your local resources will still be protected (sandbox).
* In a browser environment, applets run in a "sandbox," which prevents applets from gaining full access to the user's file systems, network connections and other resources.
* The applet security manager runs the sandbox, acting like the playground cop. The borders of the sandbox are strict: applets can't read or write to the local disk; they can't establish network connections except to the server that they came from; they can't load libraries; they can't read sensitive system properties; etc. . . .
* The sandbox and applet security manager build on the basic safety features of the Java language and Java Virtual Machine -- strict typing, garbage collection, lack of pointer arithmetic, "private" and "protected" and "final" access modifiers, immutable strings, bounds-checked arrays, the lack of a preprocessor. All of these features are valuable for any developer who is trying to build more robust and safe applications."

Details about the basic safety features are provided in a 1996 article by Frank Yellin: "The lowest levels of the Java interpreter implement security in several ways.
· The complete source code for both the Java interpreter and the Java compiler are available for inspection [and audit].

· The Java language is strict in its definition of the [data types and operations]: All primitive types in the language are guaranteed to be a specific size. All operations are defined to be performed in a specified order.
· The Java language does not have pointer arithmetic [this means you cannot tell the computer to resume execution at the byte that lies in the position computed as X+10, where X is the only thing you actually know]. . . . All references to methods and instance variables . . . are via symbolic names. [Thus] "the user cannot create code that . . . bash system variables or that accesses private information.
· [Aggressive] garbage collection [clearing and releasing unused memory]
· The Java compiler performs extensive, stringent, compile-time checking so that as many errors as possible can be detected by the compiler. Objects cannot be cast to a subclass without an explicit runtime check. All references to methods and variables are checked to make sure that the objects are of the appropriate type. In addition, the compiler checks that "security barriers" (e.g., referencing a private variable or method from another class) are not violated. Integers cannot be converted into objects. Objects cannot be converted into integers. The compiler also strictly ensures that a program does not access the value of an uninitialized local variable.

This is impressive stuff and care for security issues!

Elsewhere in the Sun Microsystems web site is the following question and anwser. It's worthy of being quoted in full, to help avoid contributing to a sense of panic over JAVA applets.

"WHAT ARE JAVA APPLETS PREVENTED FROM DOING?

In general, applets loaded over the net are prevented from reading and writing files on the client file system, and from making network connections except to the originating host.

In addition, applets loaded over the net are prevented from starting other programs on the client. Applets loaded over the net are also not allowed to load libraries, or to define native method calls. If an applet could define native method calls, that would give the applet direct access to the underlying computer.

There are other specific capabilities denied to applets loaded over the net, but most of the applet security policy is described by those two paragraphs above."

These preventions are enforced by the "applet security manager" -- a Java mechanism for enforcing the applet restrictions described above."

THE BOTTOM LINE, WHEN THESE EFFORTS FAIL TO GUARANTEE SECURITY

Despite these wonderful specifications, the pudding eaten as proof indicates that we still have some important problems with the implementation of internet security.

According to one expert commentary on the usenet: "The problem has been that in [some] browsers, there has been bugs in the implementation, allowing javascript to read any file on your hard drive and submit the contents to a cgi somewhere on the net."

Another usenet input provides this bottom-line comment: "The heart of the problem is that any language powerfull enough to do useful things will be powerfull enough to do bad things." What we as consumers need to do, in the face of this reality, is to become more active parts of the internet security system that surrounds our computers. And this is where the empowerment concept cited near the start of this article comes in.

Finally, credits for sources for this article are also due to Deja.com newsgroup servics (www.deja.com). A serious effort has been made here to respect peoples' copyrights. Any lingering violation will be corrected promptly, as soon as someone points out where the violation takes place. Contact lestone@arawak.net.

© 2000 Arawak Enterprises. All rights reserved.