into account, but rather that, like multiple other aspects of computer science, it ... is to introduce developers to several security tools, and to provide a complete ...
Methodical Secure Software Development by the Example of PICO A. Apvrille, M. Pourzandi Open Systems Lab, Ericsson Research Canada, 8400 D´ecarie Blvd, Town of Mount-Royal (QC) Canada H4P 2N2 {Axelle.Apvrille, Makan.Pourzandi}@Ericsson.ca
Abstract
[1, 2]. Though all of them are (very) interesting background to read, developers most often end with (1) eiA new requirement in software development has risen: se- ther absolutely no clue how to apply those principles to curity. However, developers are often left clueless regard- their own software, or (2) with the feeling that security ing how to achieve this, with either too theoretical infor- is so difficult to achieve there’s no way they can hope to mation they are unable to apply, or exhaustive and dis- write anything secure, which usually leads them to simcouraging recommendation lists. ply cast security aside. Security actually is a complex To assist developers in their task, this article proposes a topic, however this does not mean it should not be taken walk through of security concerns at each step of project’s into account, but rather that, like multiple other aspects of life cycle. This approach is applied to the sample case computer science, it requires training. For instance, a meof PICO, a simple Presence and Instant COmmunication thodical approach should be used to tackle security issues, application. and split their complexity into smaller concerns developFirst, the article goes through the analysis stage, using ers can handle more easily. attack trees, security policies and risk evaluation. Then, Some other articles, such as [3], focus rather on pracit designs the application using security patterns and an tical aspects of secure software development. We beextension of UML, named UMLsec. Then, typical tricks lieve they are very valuable to developers, because they of implementation are detailed. Finally, the development are written for developers by developers, providing techprocess ends with how to validate software security. nical examples which can be used straight away. HowKey words: Security, Software Development, Life ever, those articles usually deal with secure implementacycle. tion, which is only one step in development process, and make developers hastily jump to the conclusion that once buffer overflows or format strings are handled, their ap1 Introduction plication is secure... As a consequence, this article has chosen to focus on In the last few years, there has been a growing conpractical aspects of secure development at all stages of cern about security. The daily alerts entered in CERT project’s life [4]. databases or BugTraq mailing-lists have conveyed a general fear for security holes, even for initially non-security As an example, the whole article, apart from this inrelated applications such as Apache or Wu-FTP. This has troduction, shall illustrate the development of a very simconsequently resulted in an additional stress onto software ple presence and instant messaging application. Our goal development, with a new central question: how to build is to introduce developers to several security tools, and secure software. Furthermore, in most areas, security is to provide a complete process for development of secure not a dominant requirement, and is forced to co-exist with software. Of course, we wouldn’t guarantee to produce other requirements. a security bug-free program (indeed, 100% security does Already much literature has been written on the subject not exist), however we hope this case-study shall be easier
to adapt to other situations developers encounter. The article is organized as follows. Section 2 gives a brief overview of the secure application we wish to build and the various steps of its development. Then, next sections detail each phase of development’s life cycle: section 3 deals with security at analysis step, section 4 concerns the design, section 5 focuses on implementation of security issues, and section 6 explains the testing step. Finally, we conclude with lessons learned in section 7.
2
Methodology
Projects’ life cycles generally follow an iterative process of analysis, design, implementation, testing and maintenance [4, §18.2]. In this paper, we focus more precisely on how to adapt this methodology so as to converge to satisfactory security, i.e produce a trustworthy application. Our approach is described at Figure 1. We insert security concerns at each step of the life cycle, and the following sections basically study practical solutions to handle security issues at each phase. Securing the maintenance stage is important too (issuing secure patches, reviewing etc), however it is omitted from this study because we focus exclusively on steps directly related to development.
ment. PICO (Presence and Instant COmmunication) is a very simplified ICQ or AIM. Initially, users must subscribe to a PICO server. Then, they can signal their presence and send short instant messages to each other. Next sections apply each step of development’s life cycle to this sample application.
3 3.1
Security Analysis Security Environment and Objectives
The first step in any development is to define clearly the expected behaviour of the software. The same rule applies to security, for which security environment and security objectives must be defined in the early stages of development. Security environment. It describes the context the software is expected to evolve in. It is important to security because it impacts the kind of threats the application is likely to encounter. For instance, PICO is a client-server application based on exchanging messages over the Internet. In such an environment, presence information of users and messages are exposed to malicious modifications. Security objectives. Typical threats a given security environment is exposed to lead us to the definition of security objectives. Security objectives are highlevel security issues, often business-centric. For PICO, as malicious modifications may occur, we have defined two main security objectives: integrity protection of exchanged messages, and client authentication.
3.2
Figure 1: Secure life cycle. To illustrate this methodology and keep to practical issues, this paper conducts the study of PICO’s develop-
Threat Model
Then, developers should define the threat model for their application. A threat model describes possible threats which may occur in a given security environment. To do so, we propose use of attack trees [1]. Briefly, an attack is represented as a tree where the root is the attack goal and leaf nodes are different ways of achieving it. In the case of PICO, the application is exposed to various threats such as identity theft, message tampering or
communication eavesdropping. As an example, we show an attack tree for identity theft in PICO, at Figure 2.
acceptable risk level. On a concrete point of view, this consists in eliminating nodes in the attack tree (see §3.2). For instance, in PICO, we have considered that attackers would be individuals, with possibly some UNIX back3.3 Security Policy ground, but without considerable means. Typically, orIn the end, definition of application’s threat model should ganized criminal organizations are excluded from such a lead us to the elaboration of a security policy. Indeed, profile. Consequently, we have chosen to delete the at[4, §18.1.2] states a security policy can be seen as a set tacks “Looking over shoulder” or “Blackmail” from our of security requirements. In addition, those security re- attack tree. Also, we have eliminated “Hijacking TCP quirements can be prioritized according to information’s connections”, although its risk is more questionable, depending on attacker’s actual expected skills. In the end, a sensitivity. For PICO, we have established the following list of se- simplified attack tree remains in Figure 2, with only the attacks we wish to handle. curity requirements, from higher to lower priority: To summarize, the analysis phase consists in (1) defin• The application requires users to be authenticated so ing the security environment and objectives of the applias to use the presence or the instant messaging ser- cation, (2) modeling an initial attack tree, (3) elaborating vices. a security policy and setting priorities to security requirements, and finally (4) refining the attack tree according to • Messages should not be tampered with. risk evaluation. • Message sender should be properly authenticated. • Presence information should not be tampered with. • Messages’ confidentiality should be guaranteed.
4
Designing Security
Once security requirements and threat model are defined, it is time to design the application. However, usual de• Privacy of subscriber database should be guaranteed. sign methodologies must be adapted to security because we need to be able to express security concerns such • Message sending should be timestamped securely: if as critical data, communication security etc. To do so, user A sends a message at time t to B, he cannot we first propose use of security patterns to solve typical modify the message so that B believe it was sent at recurrent situations. Second, we use UMLsec [5] to detime t0. sign and model security aspects of software. UMLsec is a In this list, information sensitivity of messages has been UML profile, which extends the UML standard by adding rated as low, because we have considered that conver- stereotypes (such as an encrypted or critical), tagged valsations between users would concern private matters of ues (secrecy, integrity) and constraints. life, but not sensitive financial information such as credit The PICO application consists in three different sercard numbers. As a consequence, the security require- vices: a subscription service which handles initial regment “messages’ confidentiality” has been classified as istration of users, a presence service which keeps a list of low priority. on-line users, and an instant messaging service responsible to forward users’ instant messages to the appropriate recipients. 3.4 Risk Evaluation As a complete design would be too long for a single Finally, analysis ends with an evaluation of risks. Ob- article, we have selected here only two typical design exviously, all threats do not induce the same risk: some amples: design of the presence service using security patare more difficult to exploit, others have bigger impact terns (see §4.1) and design of the instant messaging seretc. Consequently, according to security priorities and at- vice with UMLsec (see §4.2). We shall not detail the subtackers’ typical profile, it is possible to settle down for an scription service, and shall only assume for the rest of the
ID theft
Hijacking TCP Conn
Retrieve Password
AND Modify Passwd Database
Root shell on the server
Eavesdrop
Sniff Communication
Guess password
Looking over shoulder
Get Passwd from Target
DoS attack on Target's PC
IP Spoofing
Blackmail
Figure 2: Threat model for identity theft. Boxes with hashed lines are eliminated at the risk evaluation step.
paper that a user registers by choosing a nickname and a password. Then, both information are transmitted on a secure channel, and finally, server adds them to a table of users in memory.
suggests use of a Message Authentication Code (MAC), which is basically a one-way hash function that uses a secret key. The user computes some token (his nickname for instance) with the MAC algorithm using its own password, and sends the result to the server. The latter retrieves user’s password from his database, and checks 4.1 Security Patterns and Presence Service whether its own computation of the nickname is equal to At design level, it is frequent to encounter the same user’s. typical security situations. As there is generally at least one good way to solve the problem (and most certainly Applied to PICO, this pattern has the advantage not to multiple bad ways), the idea of re-using security solutions seems very promising. This is what security patterns try transmit the password in clear text. However, we need to to achieve: a security pattern tends to solve a particu- slightly improve it, because it is vulnerable to replay atlar recurring security problem that arises in specific con- tacks where an attacker would simply eavesdrop the comtexts and presents a well-proven generic scheme for its munication, retrieve user’s computed MAC and simply resolution. It describes the context to which it applies, the play it later on. problem to be solved, and provides a generic solution with optional implementation notes and examples. In this paragraph, we explain how to adapt a security pattern to our A standard way to counter this is to use a challengecontext, i.e PICO’s presence service. response identification protocol [7, §10.3] to the pattern. In PICO, presence is signalled by authenticating on the It consists in having the server send a challenge, different server. A user is said to be on-line once he has success- for each connection attempt. Then, the client computes a fully authenticated. As user’s password should not be sent response based on his credentials and the challenge. So, in in clear text, the authentication process must either use an PICO’s case, we request the server to generate a random encrypted link (as for subscription), or use a proper au- number - which acts as the challenge - and have the client thentication protocol. MAC the challenge with his password as key (or better, a As authentication is a common security issue, we look derived session key). Hence, the resulting presence profor a corresponding security pattern: [6] proposes a Mes- tocol achieves (1) password secrecy, and (2) replay attack sage Authentication pattern which matches our needs. It mitigation.
4.2
UMLsec and Instant Messaging Service
Instant messaging {integrity=message,
{secrecy=userDatabase}
{integrity=channel} nickname,channel} Then, we illustrate use of UMLsec for the Instant Mes sage service of PICO. UMLsec is interesting at design Instant Messager Forwarder +message -userDatabase level, because it builds above the powerful design capabil+nickname of the other user -channels with users -channel with server +forwardMessage(in message) ities of UML, and is moreover capable of adding security -isLoggedOn(): boolean +sendMessage() +receiveMessage() concepts to any UML diagram. More precisely, it adds Sender Recipient Server:Forwarder stereotypes to UML links (such as Internet), dependencies :InstantMessager :InstantMessager (integrity), objects (critical) or subsystems (data security, message & recipient's secure links...), and refines them with tagged values and nickname constraints (for instance {secrecy=userDatabase}). Write Check sender message is logged in In PICO, once users have successfully logged in, a no channel is established between each user and the server. yes There is one channel per user, the server assumes that Check recipient all messages he receives on a given channel come from is logged in message & the user it is dedicated to. The user sends a message by yes sender's nickname no Receive defining the destination as the nickname of the recipient. message The message is sent to the server, who checks sender and recipient are both logged in (if not, packet is simply ignored), and then forwards the message to the recipient. In UMLsec, we have chosen to represent the Instant Pico server Pico client Messaging service with a UMLsec subsystem (see Fig Instant Forwarding ure 3). This subsystem contains a class diagram (the upmessage center per diagram), an activity diagram (middle) and a deployment diagram (the lower diagram). All diagrams look like UML diagrams, except that they use special UMLsec vocabulary. On a design point of view, they depict a few Figure 3: The Instant Messaging subsystem violates the problems the Instant Messaging service faces: secure links stereotype if integrity is required for depen• it is impossible to guarantee messages or nicknames dencies.
won’t be modified by an attacker. As a matter of fact, the secure links stereotype is violated because the Internet stereotype used between PICO client and server does not guarantee integrity required by the dependency between InstantMessager and Forwarder. In clear, this means the end-user cannot be sure who sent the message, nor if message’s integrity is preserved. • furthermore, if an intruder forges a packet which looks like a packet originating from a given user channel, the server is unable to detect it, and shall forward the message. This means a non-authorized user is capable of using a restricted service (instant messaging).
when they log in, but not when they send their message. Rather than adding an authenticated and encrypted link (which would impact performances for all messages), we have chosen to re-authenticate the user when sending a message. However, this double authentication does not require the user to type his password twice: password is cached on the PICO client once user has logged in and used afterwards. So, the client application computes a MAC of the message, recipient’s nickname and user’s password. Then, the server checks users are logged in, and verifies the MAC. Finally, if everything is correct, message is forwarded to the recipient.
Both problems rely on the fact that users do not use proper authentication on channels: they are authenticated
It might seem strange, at first, to need to authenticate to log in and to send messages, but it is important to under-
stand we are dealing with with two difference services: logging in concerns the Presence service, whereas message sending is of Instant Messaging service’s responsability.
5.1
Programming Languages
Before starting the actual implementation, we shortly discuss the question of programming language selection. Of course, in most cases, this choice shall be done tacitly for compatibility reasons (with previous versions or required libraries), or out of developer’s past experience. However, there are some cases where the issue is actually raised. Se4.3 Reviewing PICO’s design rious research has highlighted that all languages are not In section 2, we have noted that secure development is equivalent in terms of bug rate, and hence security [8]. We would not want to enter in the debate of which lanan iterative process, so it is important, at some point, to guage is the most secure, but truly, each language has its review security features provided by PICO and compare own strengths and weaknesses. Programmers should be them to requirements (see §3.3). We emphasize that, in aware of this and make up their mind accordingly. some cases, it is acceptable not to handle a given threat: 100% secure system do not exist, and security is always a tradeoff between the effort to fix a problem and the risks 5.2 Implementing Cryptography that are at stake. However, what we most specially try to prevent are scenarios where security holes are found in In this subsection, all paragraphs are organized as follows. features which were assumed to be secure. First, they start with a brief reminder of a given security In PICO, many threats are not handled: an attacker can rule. Second, the importance of this security rule is apkick-off another user by impersonating his logoff mes- plied to PICO. sages, he can also read all messages between users, or prevent a user from logging in by continously stealing 5.2.1 “Never roll your own cryptography” [2, §11] and replacing server’s login challenge etc. As long as corresponding risks are considered “acceptable” (see §3.4), As a general rule, developers should keep in mind they PICO can be shipped as is. If not, another loop from the should not write their own cryptography, but rather base their work on already existing solutions. Writing cryptoanalysis phase should be done. To conclude, this section has illustrated possible solu- graphic algorithms is a job of its own - which is different tions to design security. First, we have improved pres- from being a (good) security developer. This is illustrated ence service’s design by using a message authentication in the PICO application, where cryptography is used (1) pattern. Second, we have used UMLsec to formalize the to authenticate users, and (2) for secure subscription comsecurity needs of the system. This revealed initial weak- munication: nesses of the instant messaging service. Finally, we have reviewed security features of PICO according to estimated needs. This step has helped decide whether design is acceptable or not.
5
Implementing Security
Although a neat design is certainly a good starting point, it is unfortunately not enough to achieve secure software. As a matter of fact, there are several pitfalls to secure implementation this section highlights.
• using a home-made Message Authentication Code (MAC) is bad idea. For instance, both secret prefix and postfix keyed hashes where, respectively, MAC(m)=H(key || m) and MAC(m)=H(m || key) with || being concatenation - have proved out to be unsecure [7, §9.64,§9.65]. • unless there are some specific constraints, using a home-made secure communication layer is simply a loss of time in circumstances where SSH or STunnel can meet the same requirements. Also for login challenge generation, rewriting a random number generator is a lot of work when a well-known
• buffer overflows do not only concern str* functions. Functions like gets() should also be handled with care.
(and performant) library such as OpenSSL is available. 5.2.2
• using strn* functions instead is not a guarantee. [12] shows that misuse of those functions can lead to buffer overflows too.
“Cryptography is Very Difficult” [9, §2.7]
Sometimes, application use experienced cryptographic algorithms, but still introduce major security holes. Possible reasons are: • programmation error: recent statistics show that programmers commonly write 1 bug per 55 lines of code.So, as any other piece of code, cryptographic implementations are likely to contain bugs. An example of cryptographic implementation bug is NTLMv2’s HMAC-MD5 implementation, where long keys are truncated to 64 bits instead of hashing them as RFC 2104 specifies, hence resulting in possible security breaches. • misunderstanding or misuse of the algorithm: the algorithm is fine, but it is being used for something it wasn’t meant for. For instance, in the PICO application, authentication is done with the well-known HMAC-SHA1 algorithm. However, careful reading of RFC 2104 stipulates that, for optimum security, the key for HMAC should be both random and at least of 20 bytes. As user passwords are usually much smaller, and passphrases have less entropy than random data, we should in fact use a password deriving algorithm [10, §3] to obtain a acceptable key for HMAC. For simplicity reasons, we have merely asked users to enter long passphrases.
5.3
Buffer Overflows
In brief, buffer overflows occur when a given size λ is allocated in memory, but more than λ is written. The additional bytes overwrite the memory, a bug which can be exploited in various malicious ways and which actually concerns approximately 60% of security advisories. Several articles focus exclusively on buffer overflows, and for a detailed explanation, we warmly invite readers to refer to them [3, 11]. This paragraph shall merely highlight a few frequent thoughts:
• even small overflows can cause a security hole. In [13], Bailleux demonstrates this with a 2-byte overflow. In the PICO application, buffer overflows are (hopefully) handled the following way. First, user’s input is strictly controlled through the readInputString function which reads at most len-1 characters, and ensures the returned string includes a trailing ’\0’ (see listing 1). For instance, if 8 bytes have been allocated to buffer, and user enters “Instant Messaging\n”, the buffer shall exactly contain “Instant\0”. If user enters “PICO\n”, buffer contains “PICO\0xxx” (where x represents any character). Listing 1: Reading fixed size user input 1
5
int readInputString(char *buffer, int len) { int i; /* fgets reads in at most one less than len characters */ if (fgets(buffer, len, stdin) == NULL) return -1; /* fgets stores the newline character if it is read, so we take it off */ for (i=0;i ./PicoServer & the idea of security patterns very promising, but only few [root@glacier src]# nmap -sT 127.0.0.1 of them are available at the moment, and developers are -p 8001 often unaware of their existence. A security pattern reposThe results show that PicoServer’s messaging port itory might be a good starting point for developers in that (8001 by default) succeeds to the test, but that the sub- area. scription port (8000 by default) crashes with a Broken Finally, we learned that, currently, the best tool for sePipe after a TCP scan. This is an excellent oppurtunity curity testing is code review. We had placed much hope in for Denial of Service attacks. security scanners (probably too much), but unfortunately we found them too limited in scope: often limited to classical C implementations, and detecting only few patterns 6.5 Evaluating Bugs of vulnerabilities. We believe there is still much effort to In PICO, table 3 lists all bugs found so far: conduct in that field, because code review - though effiThen, bugs’ criticality should be rated according to the cient and necessary - is really time consuming, and desecurity policy established in §3.3 and associated risks pends very much on reviewer’s professionalism and de(how easily the bug can be exploited and fixed, its impact gree of competence. etc). For example, given the numerous tools for exploiting buffer overflows and the consequences of such an exploit, we might place the second bug as the highest priority. On 8 Conclusion the contrary, we might decide the first bug is less important, because rated too “complex” to set up according to This paper has presented a structured, methodical approach to security in software development from analysis attacker’s profile.
to testing. Furthermore, we have shown how to integrate coherently our sample application with security tools, and have reviewed various security testing techniques. Although, our approach cannot guarantee finding all possible vulnerabilities in the system, we believe by adopting its methodical, step by step approach, developers can drastically improve their software’s security level. Also, we have focused on illustrating our approach with practical examples, such as use of various security mechanisms and tools. First, during analysis, we have shown use of attack trees. Then, at design level, we have found UMLsec and security patterns very promising. At implementation stage, we have tracked down typical implementation errors, including bad implementation of cryptography or buffer overflows. Finally, we have compared several security testing tools, and have concluded they were yet no match to skilled peer reviewing’s efficiency in finding vulnerabilities. As future work, we plan to generalize our results for PICO, and extend them to a complete and practical methodology to develop secure software.
References [1] Schneier B., Secrets and Lies, Digital security in a networked world, Ed. Wiley Publishing Inc, ISBN 0-471-25311-1, 2000. [2] Viega J., McGraw G., Building Secure Software, Ed. Addison Wesley, Professional Computing Series, ISBN 0201-72152-X, 2002. [3] Wheeler D., Secure Programming for Linux and Unix HOWTO, v3.010, http://www. dwheeler.com/secure-programs, 2003. [4] Bishop M., Computer Security: Art and Science, Ed. Addison-Wesley, ISBN 0-20144099-7, 2003. [5] J¨urjens J., UMLsec: extending UML for Secure Systems Development, Fifth International Conference on the Unified Modeling Language (UML 2002), Dresden, Germany, 2002.
[6] Braga A. M., Rubira C. M. F., Dahab R., Tropyc: A pattern Language for Cryptographic Software, in the Proceedings of the Pattern Languages of Programs (PLOP) Conference, 1998. [7] Menezes A., van Oorschot P., Vanstone S., Handbook of Applied Cryptography, CRC Press, 1996. [8] Phipps G., Comparing Observed Bug and Productivity Rates for Java and C++, http://www.spirus.com. au/papersAndPresentations.htm, 1999. [9] Ferguson N., Schneier B., Practical Cryptography, Ed. Wiley Publishing Inc., ISBN 0-47122357-3, 2003. [10] Burnett S., Paine S., RSA Security’s Official Guide to Cryptography, RSA Press, ISBN 007-213139-X, 2001. [11] Aleph One, Smashing the Stack for Fun and Profit, Phrack no.49, vol. 7, file 14/16, August 1996. [12] Gay O., Pitfalls of strn* functions, MultiSystem and Internet Security Cookbook Magazine no. 3, pp. 57-61, July-August 2002, in French. [13] Bailleux C., Small stack buffer overflows, Multi-System and Internet Security Cookbook Magazine no. 2, pp. 55-58, Avril-May-June 2002, in French. [14] TESO Team, Exploiting Format String Vulnerabilities, Version 1.2, http: //www.team-teso.net/articles/ formatstring, September 2001. [15] Whittaker J., Why Secure Applications are Difficult to Write, IEEE Security & Privacy magazine, vol.1, no. 2, pp. 81-83 March-April 2003. [16] Lenstra A. K., Verheul E. R., Selecting Cryptographic Key Sizes, Journal of Cryptology, vol. 14, no. 4, pp. 255-293, 2001.
[17] Shankland S., Open Source code as flawed as proprietary: Study, CNET News.com, http://asia.cnet.com/newstech/ systems/0,39001153,39138830, 00.htm, July 2, 2003. [18] Thompson H. H., Why Security Testing is Hard, IEEE Security & Privacy magazine, vol. 1, no. 4, pp. 83-86, July-August 2003.
