Mobile Computing G 22 3033 06

Mobile Computing G 22. 3033. 06 - Lecture April 7 th, 1998 Copyright, 1996 © Dale Carnegie & Associates, Inc. TIP For additional advice see Dale Carnegie Training® Presentation Guidelines

Mobile Code on the Web • Executables – stored on the client – sent to client – interpreted in the browser • Risks – run native code on the machine • little of no protection in WIN 95 or WIN 98 • full user permission on UNIX – access to file and network port connections

JAVA • code can execute remotely and locally • client’s browser used to – display information and forms – interpret (executable) code obtained in remote applets • can create interactive web pages • allows for animation, games, and potential to run unlimited remote applications

Problems with JAVA • execution at client of general-purpose script • enabling technology for the hacker • ideal platform for – stealing, modifying code or erasing information – corrupting client machine and data – malicious users

Types of Attack • integrity – deletion / modification of files – modifications of memory currently in use – killing processes / threads • availability – allocating large amount of memory – creating thousands of windows – creating high priority threads / processes • disclosure – mailing information about client machine (ex. etc/passwd,

Securing Mobile Code • limit the priviledges of the executable (ex. Sandbox model) • obtain asurance that source of executable is trusted – code signing model • limit the set of programs that can run on a client based on executables properties – firewalling aproach • proof-carrying code TIP As appropriate, supplement your presentation with technical support data in hard copy or on disc, e-mail, internet

Sandbox - JAVA • goal is to limit access to: – file system – ability to open connections – mail and other applications • mechanisms in practice: – Class. Loader – bytecode verifier – security manager

Class. Loader and the Bytecode Verifier • Class. Loader – loads local classes – loads and tags remote classes • bytecode verifier checks that remote code: – that does forge pointers – does not violate access restrictions – accesses objects by correct type – accesses methods with correct argument types – contains no stack overflow

Security Manager • uses methods to check specific conditions – check READ (check if a file is to be read) – check ACCEPT (check if a network connection can be accepted) – etc. • provides flexible mechanism for conditionally allowing access to resources • allows sys admin to define flexible security policy • such flexibility is dangerous (sys admins make mistakes)

Code Signing Model • checks list for entities it trusts • executable content is signed by : – a trusted entity – an entity with a certificate signed by a trusted entity • real world example : ACTIVE - X • hybrid scheme: – signed code sections are loaded as local by classloader

Firewalling • Finjan approach – looks for characteristics in applets Similar to a virus checker, the Finjan approach uses this type of pattern-matching • playground approach – split applets into • graphics server • playground, where code actually executes • communication via RMI (Remote Message Invocation) • commercial venture (ex. Digitivity)

Timing Attack • can use timing information to: – recover bit by bit of secret key – each encryption reveals a bit of the key – many existing implementations are vulnerable and not likely to change soon • remote java applet enable attack by gathering timing data

JAVA security • JAVA is an exciting enabling technology • computer hackers might be the most excited • policy decisions have to be made (ex. Allow file system access? ) • policy decision may be difficult to enforce • greatest threat are bugs in: – code – policy enforcement – browser – OS

Recent Hole in IE • discovered by Paul Greene • coverage: CNN, NBC, CBS, Info. World • Microsoft posted a 400 K patch within 48 hours – Why does this worry me? • effects of attack are devastating • we are very lucky that the “good guys” found this one first

The setting • WIN 95 and WIN NT shortcuts – basically symbolic links – stored in. LNK and. URL files depending on where they point – contain relative or absolute path to executables • when a user clicks on (executes) a shortcut, the program it points to runs

The attack • when a shortcut appears in a URL, shortcuts are treated the same as local ones • sample HTML on a page • <A HREF=“SEXY. LNK”> Click here for reward </A> • when a user clicks: – SEXY. LNK is downloaded to the machine – the thing pointed by SEXY. LNK executes

The Consequence • Using WIN 95, SEXY. LNK points to : – c: binmkdir c: haha – c: binrmdir -p c: windows • batch files attacks executes FILE. BAT on client • basic attack allows bad guys to – download a pointer to any program on the machine – include any argument to the program – executes it when you visit the page • more dangerous for WIN 95 because of params

MS Word Macro attack (on IE) • due to Fellen and Balfani • attacker creates FOO. DOT (with macro virus) • attacker renames the FOO. DOT to FOO. CLASS • attacker adds FOO. CLASS to web server • attacker creates a web page that points to an applet named FOO. CLASS <applet codebase: ”http: //host. com/pub/”> code=foo. class </applet> • the page is loaded

Microsoft’s “fix” to both attacks • display a pop-up window – “save to disk or open? ” – SAVE - postpone danger OPEN - it will execute 1. Do users read pop-up windows? 2. Do users pay attention to pop-up windows? 3. Do users just click OK so they can continue? Answers: 1. NO 2. NO 3. YES

Types of Firewalls • basic firewall policy: – insiders are good – ousiders are bad • basic JAVA policy – bad outsiders can be kept under control • basic problem when combining policy

Cryptography • not a silver bullet • need good system implementations (ex. pick good primes) • key management • International Policy Agreement • good, secure tokens

Mobile Computing G 22 3033 06 — Lecture