FIT3056 Secure and Trusted software systems

1. FIT3056 Secure and Trusted software systems Lecture 07 Secure networked and distributed programming

2. Outline • Networked and distributed programming • Security issues with networked and distributed programming • Client-server model • Sockets based programming • RPC, RMI, and CORBA • Secure networked and distributed programming

3. Networked and distributed programming: principles • Principle 1: choosing proper communication facility for building networked and distributed applications: it is a critical part of the software development. • Sockets, or RPC, or CORBA? • Principle 2: choosing proper model for client and server to communicate with each other. • Client/server model, peer-to-peer, or object-based model? • Principle 3: the design of the application must have efficiency, high reliability and extendibility: • Software has to be efficient, reliable and extendable.

4. Security issues with networked and distributed programming. • Different communication facility has different security issues. • Sockets? • RPC? • RMI? • CORBA?

5. Security issues with networked and distributed programming. • Requirements for efficiency, high reliability and ease of extendibility can affect the software security. • High efficiency (can make the software vulnerable) • Reliability (support security)? • Easy to extend (may compromise security).

6. Security issues with networked and distributed programming. • Different communication models can have different effects on the security of the design and implementation, testing, and maintenance of the software. • client/server model? • peer-to-peer? • object-based model? • Rendezvous?

7. Networked and distributed programming: Client/Server General communication between a client and a server

8. Networked and distributed programming Client/Server • In general, we can design two types of servers, Stateless servers and stateful servers. However which one is more secure? : • Stateless servers: • Keeps no information about the state of clients • Can change its own state without informing clients • E.g: http server

9. Networked and distributed programming Client/Server • Stateful servers: • Maintains information about its clients • Cannot arbitrarily change its state because clients depend on it • E.g: ftp server

10. Networked and distributed programming Client/Server • Stateless servers: • They are more tolerant of failures • Clients can simply retry failed requests • Server can restart immediately after a crash with no need for recovery How about security? • Stateful servers: • They can be more efficient, but are less tolerant of failures • Knowledge of client state can reduce communication overhead but how about security? • More suitable for new technologies such as wireless networks,handheld devices

11. Networked and distributed programming Client/Server • Stateless Servers: • Mechanisms such as “cookies” can be used to preserve state in stateless protocols like HTTP • Server can store information on client’s machine (such as favorite pages, passwords, session identifiers) • Client sends this information to server when it makes a request

12. Multi-threaded Clients client main thread com. with the server new thread-c2 new thread-c1 doing other task

13. Multi-threaded Clients • Primary Function: hide communication latencies by doing other things while waiting for messages to get through • Example: Web Browser • Fetches HTML page, starts rendering it while data is still being read on the network connection • Multiple threads fetch images and other page components concurrently • Multiple open connections (two browsers loading pages, downloading files from multiple sites, etc.)

14. Multi-threaded Servers

15. Multi-threaded Servers • Primary Function: exploit parallelism (see the example of this week) • Can design server’s threads as sequential programs or threads can be designed to run concurrently • Example: Web Server • One thread listens on port 80, and hands off requests to other threads that serve files from disk

16. Multi-client Server Server new thread s1 to serve client1 com. with client1 main thread new thread s2 to serve client2 com. with client2

17. Multithreaded Client/Multiclient Server client1 Server main thread new thread s1 to serve client1 new thread-c1 new thread-c2 C#1 main thread doing local task C#2 new thread s2 to serve client2 client2

18. Server DesignIterative vs. Concurrent • Iterative: • Server handles all requests and sends all responses itself • Examples: talk • What are the security issues? • Concurrent: • Server passes requests to separate threads or other processes • Examples: http, ftp, telnet • What are the security issues?

19. Server Design – Super Server • Many services have pre-assigned endpoints • Most of these services aren’t used very frequently: echo, daytime, etc. • It’s more efficient to have a single “superserver” (inet on most UNIX-like systems) listen to all these endpoints than to have a separate server process for each of them What are the security issues of this design?

20. Server Design - Super Server client1 Main server inetd Echo server client2 Daytime server Other server client3

21. Multi-client/server - Server (e.g.) import java.net.*; import java.io.*; public class M_Server { public static void main(String[] args) throws IOException { ServerSocket serverSocket = null; boolean listening = true; try { serverSocket = new ServerSocket(5100); } catch (IOException e) {/* handle exception */ } while (listening) /* while true */ { Socket newsock = serverSocket.accept(); HandleCRThread t = new HandleCRThread(newsock); t.start(); } serverSocket.close(); } /* end main */ }

22. HandleCRThread(e.g.) // thread class to handle client’s request import java.net.*; import java.io.*; public class HandleCRThread extends Thread { private Socket socket = null; public HandleCRThread(Socket s) { super("HandleClientRequestThread"); socket = s; }

23. HandleCRThread (eg) (con’t) public void run() {// run method of HandleCRThread class try { PrintWriter out = …(socket.getOutputStream(), true); BufferedReader in = …( socket.getInputStream())); ProcessClientRequest hc = new ProcessClientRequest(); String inputLine, outputLine; while ((inputLine = in.readLine()) != null) { outputLine = hc.processRequest(inputLine); out.println(outputLine); if (outputLine.equals("BYE")) break; } out.close(); in.close(); socket.close(); } catch (IOException e) { e.printStackTrace(); } }}

24. ProcessClientRequest (eg) // converts a string of chars to uppercase public class ProcessClientRequest { private String req; public String processRequest(String rq) { req = rq; if (req.equals("END")) return "BYE"; else return (req.toUpperCase()); } }

25. Multi-client/Server-Client (eg) import java.io.*; import java.net.*; public class M_Client { public static void main(String[] args) throws IOException { Socket clientSocket = null; PrintWriter out = null; BufferedReader in = null; try { clientSocket = new Socket("venus", 5100); out = new …(clientSocket.getOutputStream(), true); in = new …(clientSocket.getInputStream())); } catch (UnknownHostException e) {/* handle error */ } } catch (IOException e) {/* handle error */ } BufferedReader stdIn = new …(System.in)); String fromServer; String fromUser;

26. Client (eg)-con’t while ((fromServer = in.readLine()) != null) { System.out.println("Server: " + fromServer); if (fromServer.equals("BYE")) break; fromUser = stdIn.readLine(); if (fromUser != null) { System.out.println("Client: " + fromUser); out.println(fromUser); } } out.close(); in.close(); stdIn.close(); clientSocket.close(); } }

27. RMI – RO (interface) (e.g.) import java.rmi.*; interface RO extends Remote { public String processRequest(String inStr) throws RemoteException; }

28. RMI – ROImpl (e.g.) import java.rmi.*; import java.rmi.server.*; import java.io.*; public class ROImpl extends UnicastRemoteObject implements RO, Serializable { public ROImpl() throws RemoteException { /* constructor */ } public String processRequest(String inStr) throws RemoteException { String outStr = inStr; return (outStr.toUpperCase()); } }

29. RMI – RemoteServer (e.g.) import java.rmi.*; import java.rmi.registry.*; public class RemoteServer { public static void main(String args[]) { System.setSecurityManager(new RMISecurityManager() ); try{ //create the remote object ROImplro = new ROImpl(); Registry reg = LocateRegistry.createRegistry(6789); reg.bind("myRO", ro); } catch(Exception e) { System.out.println("Error:" + e); } } //end main }

30. RMI- RemoteClient (e.g.) import java.io.*; import java.rmi.*; import java.rmi.registry.*; public class RemoteClient { public static void main(String[] args) { String inputStr , result; System.setSecurityManager(new RMISecurityManager() ); try { ROrefRO = (RO) Naming.lookup("rmi://"+args[0]+":6789/myRO"); BufferedReader stdIn = new BufferedReader(new InputStreamReader(System.in)); while ((inputStr = stdIn.readLine()) != null) { result = refRO.processRequest( inputStr); System.out.println("Result = " + result); } /* end while */ } catch(Exception e) { System.out.println(e); } } /*end main */ } /* end remote client */

31. Concurrent Programming with Sockets, RPC or RMI • When design and implement networked and distributed applications, consider: • Flexibility – sockets may be the choice • Portability – RPC & RMI may be the choice • Interoperability - may consider CORBA and DCOM • How about security? Which one does offer realatively better security?

32. Concurrent Programming with Client/Server Model Many factors should be carefully considered in the design and implementation of Client/Server applications • Consider the main functionality of the server and its services during the design: • Is the server going to provide services to wireless computers; handheld computers; video transmission, etc? • Consider potential problems: • What would happen if you locked a synchronized section on an object object_T, made a remote call, passing object_T to the server, and then the server made a synchronized call back on object_T? • Consider other factors: • Expandability • Crash recovery, etc

33. Distributed systems

34. Why build distributed systems • In a distributed system, processing activities may be located on more than one computer and the computers communicate over a network in order to perform joint tasks • Workstations provide users with local processing power enabling them to perform interactive tasks more efficiently than a time shared system. • In a distributed system, users can share information and resources more effectively and efficiently. • Distributed systems provide better replication and availability – several copies can be maintained on several servers automatically – and when one component fails the others may continue

35. Why Use Remote Procedure Call • Programming with sockets needs to take care of all the differences of computer architectures (such as byte-order) and the underlying operating systems (Windows or Unix) • The use of RPC facilitates the building of distributed applications by extending the traditional procedure calls • RPC removes concerns for the communication mechanisms (a call can be made without worrying about the transport layer), and hardware differences (computers can have different byte orders –left-to-right or right-to-left) • Provides transparent procedure calls on different computers without worrying about their architectures, OSs or without knowing their locations (make remote calls as local ones)

36. Remote Procedure Call (RPC) • To allow a program to call procedures (methods) on another computer as the local one Computer A Computer B request message client server callsprocedure (suspended) resumes executesprocedure returns reply message

37. Remote Procedure Call RPC Flow of Execution Local Process /client Remote Process / server Caller Callee Stub Stub Local OS Remote OS network communication

38. RPC Client/Server Applications 1. Client calls a local procedure on the client stub (the actual procedure is on the server site) 2. The client stub packages the call and the args. 3. The client stub sends this to the remote system (via TCP/UDP) 4. The server stub unpacks the call and args from the client 5. The server stub calls the actual procedure on the server 6. The server stub packages the reply and sends it back to the client

39. RPC software • The RPC software that supports remote procedure calling has three main tasks: • Taking the arguments and results of a procedure call, assembling them into a form suitable for transmission across a network (marshalling) – dispatching them - and disassembling the results on arrival • Combining the RPC modules with client and server programs in conventional languages • Transmitting request messages and reply messages using a message passing protocol

40. RPC Client/Server • Server binding • Locating and setting up communication between the server and the client – server and client are on different hosts, therefore this needs to be done. • Interface definition language (IDL) • Used to define an interface, that the server implements and a client calls. IDL helps overcome the differences between platforms (hardware and software) • Marshalling • Packaging the client arguments into one or more network messages for proper communication

41. Example: Writing a client and a server (1) /* interface.x */ /* Example Interface Definition */ struct square_in { long arg; }; struct square_out { long result; }; program SQUARE_PROG { version SQUARE_VERS { square_out SQUAREPROC( square_in ) = 1; /* Procedure number = 1 */ } = 1; /* Version number = 1 */ } = 0x12300000; /* program number */ Source: R. Stevens, Unix Network Programming (IPC) Vol 2, 1998

42. Example: Writing a client and a server (2) interface.x rpcgen interface.h Client Main interface_clnt.c (client stub) interface_xdr.c interface_svc.c (Server stub) Server.c Runtime lib Client Server Source: R. Stevens, Unix Network Programming (IPC) Vol 2, 1998

43. Example: Writing a client and a server (3) /* Server */ square_out * squareproc_1_svc( square_in *inp, struct svc_req *req ) { static square_out outp; outp.result = inp->arg * inp->arg; return (&outp); } /* Client */ CLIENT *cl; square_in inp; square_out *outp; /* Client creation */ cl = clnt_create( argv[1], SQUARE_PROG, SQUARE_VERS, "tcp" ); inp.arg = 100L; outp = (square_out *)squareproc_1( &inp, cl ); printf( "Result: %ld\n", outp->result ); Source: R. Stevens, Unix Network Programming (IPC) Vol 2, 1998

44. RPC Binding • Server binding • Locating and setting up communication between the server and the client • portmap or RPCbind • A local directory service • Server program registers with portmap with program number and version. • clnt_create contacts the portmap with program number, version info and protocol type (tcp/udp) to get port number (or end point), the server’s port value.

45. Variants • Sun RPC or Open Network Computing (ONC) RPC • Originally built over the Sockets API with support for TCP and UDP • Commonly used in Sun’s network file system (NFS) • Open software foundation’s Distributed Computing Environment (DCE) RPC • More generic specification for the RPC. • Object based implementation derived from DCE RPC • Example of Distributed Object systems: • CORBA, DCOM, RMI,.NET

46. Why Use Remote Method Invocation (RMI)Java ONLY • Sockets and RPC can be used to build distributed applications, however they are not object-oriented and hence more work is required to build object-oriented distributed applications • Socket is considered low level, RPC offers higher level of communication, and RMI offers object-oriented communication • RMI can be thought of as an extension of RPC to provide a better means for building distributed applications • RPC supports traditional procedural programming style (parameters to RPC are ordinary data structures - not objects) • RMI supports object-oriented programming style (parameters to RMI are objects)

47. Remote Method Invocation (RMI)Java ONLY Client Server Stub Skeleton (opt) Remote Reference Server Remote Reference Transport Layer (RMIregistry aids this)

48. Distributed Programming with CORBA • Developers use CORBA (Common Object Request Broker Architecture) to build distributed applications. • It is distributed client-server computing facility. • It uses message-passing systems and most commonly found in UNIX-based environments. • The idea behind CORBA is a software intermediary (Object Broker) that handles and disperses access requests on data sets. • CORBA uses IDL in a similar way as RPC. • Distributed Programming with CORBA is Object-Oriented and simpler than RPC.

49. CORBA • OMG IDL is a purely declarative language designed for specifying programming-language-independent operational interfaces for distributed applications. OMG specifies a mapping from IDL to several different programming languages, including C, C++, Smalltalk, COBOL, Ada, and Java. When mapped, each statement in OMG IDL is translated to a corresponding statement in the programming language of choice.

50. CORBA programming with Java Borrowed from Marc Conrad