CS 390 S Week 7 Calling Programs Trust

CS 390 S, Week 7: Calling Programs, Trust Pascal Meunier, Ph. D. , M. Sc. , CISSP February 21, 2007 Developed thanks to support and contributions from Symantec Corporation, support from the NSF SFS Capacity Building Program (Award Number 0113725) and the Purdue e-Enterprise Center Copyright (2004) Purdue Research Foundation. All rights reserved.

The Wrapper Problem Calls to an insecure application can be wrapped inside and protected by another program that performs input validation and access control Wrapper must have an exact and complete model of the grammar and semantics used by the protected application, otherwise: – Insecure application loses functionality – Wrapper lets through dangerous (“unexpected”) commands Updates to an insecure application require an updated wrapper

Example Wrapper Problem wu-ftpd CVE-1999 -0997 – FTP server wu-ftp with FTP conversion enabled allows an attacker to execute commands via a malformed file name that is interpreted as an argument to the program that does the conversion, e. g. tar or uncompress. – Conversion is used to compress or uncompress files – File names passed to tar without checking if one really is a command line option that can be abused! e. g. , --use-compress-program e. g. , --remove-files

Wrapper Through Interpreted Code When application is invoked by a command processed through a complex interpreter Examples: – calling programs through the system() and wsystem() calls (UNIX and Windows) – other cases of dynamic code generation (SQL, etc. . . ) Modeling the interpreter is difficult. – “exec” family of UNIX calls presents a simplified interface that limits misinterpretations and engineered attacks. – Windows "Create. Process*", "Shell. Execute", "Win. Exec" have complex cases that allow engineered attacks

Windows Call Complexity Create. Process ( lp. Application. Name, lp. Command. Line, . . . ) If lp. Application. Name is NULL, then lp. Command. Line is interpreted. . . – Looks for an application name White space separators White space in directory names are "tried" as separators – – – C: \Program Files\Application. Dir\Appname. exe C: \Program. exe would get executed if present Solution: enclose application in quotes, but why not specify lp. Application. Name then? (From Howard and Leblanc, 2003)

UNIX “system " Call Program and arguments are interpreted by a shell! – very difficult to model and sanitize Also available on Windows! Exec calls – exect and execle allow the separation of path, arguments, and environment Fewer risks – int exect(const char *path, char *const argv[], char *const envp[]);

Differences between Exec Functions execl, execle, execv take as first argument – const char *path – Path must be unambiguous execlp, execv. P take as first argument – const char *file – The environment's PATH will be searched to find the file – execv. P: a replacement for PATH is specified in the call Which is less prone to mishaps?

Question Rank the following calls in order of safety (high to low): – – system execle execvp a) execv, execvp, execle, system b) execle, execvp, system c) execvp, execle, execv, system

Question Rank the following calls in order of safety (high to low): – – system execle execvp a) execv, execvp, execle, system b) execle, execvp, system c) execvp, execle, execv, system

File Descriptors UNIX: forked and exec’ed processes inherit file descriptors Remember the principle of complete mediation – every access must be checked for permissions Close all unneeded file descriptors (before calling exec)

Towards a Basis for Trust: Plan of Study Motivation: Trust "train wreck story" Notion: Trust Boundaries – Failure modes of trust boundaries MITRE CWE examples Are there assurances that something can be trusted? – Taint tracking – Cryptographic assurances Why, who and what do you trust? – Formal trust and policies

Motivation: Gross Trust Management Failure Trust web browser client to keep data safe HTML forms: hidden input Cookies Because the server put the data there, programmer thinks the data is valid Threat: users can easily view and change those values

Black" src="https://present5.com/presentation/cb95c0ba13c5eaa8178a99353b203b45/image-13.jpg" alt="Real-Life Example: dansie. net shopping cart Black" /> Real-Life Example: dansie. net shopping cart Black Leather purse with leather straps
Price: $20. 00
http: //online. securityfocus. com/archive/1/55172 CVE-2000 -0253

Hidden fields in shopping carts http: //www. iss. net/security_center/static/4621. php CAN-2000 -0101: Make-a-Store CAN-2000 -0102: Sales. Cart CAN-2000 -0103: Smart. Cart CAN-2000 -0104: Shoptron CAN-2000 -0106: Easy. Cart CAN-2000 -0108: Intellivend CAN-2000 -0110: Web. Site. Tool CAN-2000 -0123: Filemaker example CAN-2000 -0134: Check It Out CAN-2000 -0135: @Retail CAN-2000 -0136: Cart 32 CAN-2000 -0137: Cart. It CVE-2000 -0253: dansie

Discussion What should the developers have done? Could input validation have helped? – Where input validation is defined as verifying the type and range of an input e. g. , positive integer less than 10000 What is the difference between trusting the source of the data and validating an input?

Notion: Trust Boundary Role of a trust boundary – Know which data is trusted and which is not on the basis of rules or storage location, instead of keeping track of individual pieces of data Simpler than tracking taint Boundaries simplify the life of programmers Example: Information stored in this table or the session object has been validated and is trusted to be well-formed" May be several different levels and types of trust – More details later on why and what to trust

Example Trust Boundaries Inputs, outputs, UI elements Networks, host-network interfaces Physical locations Sub-systems (databases) Modules, scripts, objects (encapsulation) Accounts, processes, shared memory locations, IPC (inter-process communication) mechanisms

Crossing Boundaries Moving low-trust data across a boundary to a hightrust area, or for a high trust use, requires input validation – Type, range, format, validity – If even allowed. . . (c. f. access control later) Additional Issues: – Source authentication Did this data really come from where it says it did, or from where I think it did? – Data Integrity Has this data been tampered with? – Is the storage location trustworthy?

Ill-Defined Trust Boundary Can lead to ambiguities, misinterpretations, and inconsistent treatment of information Trust Boundary Violation (CWE ID 501) – Mixing trusted and untrusted data in a trusted storage location, such as in a session object the HTTP session object contains trusted information – Java Example: – usrname = request. get. Parameter("usrname"); if (session. get. Attribute(ATTR_USR) == null) { session. set. Attribute(ATTR_USR, usrname); } – In the example, the assignment is done before authentication happens

Inconsistent Validation Mechanisms Same source handled differently in different code locations At different times In different circumstances Different rules are applied to equivalent sources: – Unprotected Alternate Channel, ID 420 Example: software has different layers and subsystems (database, API, UI, etc. . . ) that are simultaneously accessible, but input is inconsistently handled. » CAN-2002 -1578 - Product does not restrict access to underlying database, so attacker can bypass restrictions by directly querying the database. Authentication Bypass by Alternate Path/Channel (288) » Example: web applications that have scripts that can be invoked directly if the url is known

Misplaced or Absent Trust Boundaries Self-reported information (unauthenticated data) – Trusting self-reported IP address, ID 291 – Trusting self-reported DNS name, ID 292 – Using referrer field for access control, ID 293 Trusting the client – Client-Side Makes Server Security Decisions – Server trusting client-side-controlled data Web Parameter Tampering, ID 472 Trusting Cookie Information ("Use of Cookies", ID 565) Trusting events – Unprotected Windows Messaging Channel ('Shatter') 422 – Trust of system event data, ID 360

CWE 291 -293: Self-Reported Information IP Address Spoofing – Trivial for UDP packets Source IP can be anything you wish – More work for TCP packets but still possible (if sequence number can be guessed) – Source IP address of packets can't be trusted Reverse DNS lookups – Who is at IP W. X. Y. Z? You ask the same people who control W. X. Y. Z – They can answer whatever they want HTTP Referrer field – Sent by client web browser, could be fake

Trusting the Client The client may not be what you think it is Firefox extension "Tamper Data" – Modify forms before submitting them Firefox extension "Add N Edit Cookies" – Create cookies – Modify cookie values You send Java. Script to the browser. Does it really execute? – Firefox extension "Firebug" Edit CSS, HTML and Java. Script live Applies to all clients (games, etc. . . )

Example: CWE ID 565, Use of Cookies CVE-2002 -1730 - Authentication bypass by setting certain cookies to "true". CVE-2002 -1734 - Authentication bypass by setting certain cookies to "true". CVE-2002 -2064 - Admin access by setting a cookie. CVE-2002 -2054 - Gain privileges by setting cookie. CVE-2004 -1611 - Product trusts authentication information in cookie.

Web Parameter Tampering, ID 472 Access Control Bypass Through User-Controlled SQL Primary Key, CWE ID 566 Scenario – You list items on a web page (orders, invoices, etc. . . ) with links to view more details about a specific item – Bob is not supposed to be able to access someone else's items – urls are of the form: list_specific_item? id=98 – Mallory can change the id and view someone else's items It's not because you list only good values as choices that you won't get an incorrect one back. . .

Trusting Events Unprotected Windows Messaging Channel ('Shatter' attack) 422 Any application, in Windows, on a given desktop can send a message to any window on the same desktop. – no access control You need to verify the source before acting upon it

Trusting Event Data (CWE 360) Checking if a specific button was pressed is meaningless, it could be faked. – Especially if the whole event was faked. . . Java example: public void action. Performed(Action. Event e) { if (e. get. Source()==button) System. out. println("print out secret information"); }

Assurances: Taint Idea Track the flow of data All untrustworthy sources are considered "tainted" The result of any operation that used tainted data is also tainted Dangerous operations (e. g. , "system", or custom operations such as "bill") are forbidden from using tainted data Can be made to work in conjunction with input validation, but taint tracking can be useful independently of input validation How does that work? Mini-lab! (next slide)

Exercise: Perl's taint mode Start a script with: – #! /usr/bin/perl -Tw -T switch turns on taint mode To untaint data, it must go through a regular expression Regular expression may do nothing (defeats the purpose) – $tainted =~ /(. *)/; / / specifies a regular expression () specifies a match – The $1 variable contains the first match Example: $clean = $1;

Perl Taint Mode Exercise Here is a perl script that will safely run the "wc" (word count) command on any file whose 8. 3 format name is passed to it as an argument: #!/usr/bin/perl –w. T $ENV{PATH} = ""; # Try commenting out this line foreach $file (@ARGV) { print "Processing $file: n"; if ($file =~ m/(^w{1, 8}. w{0, 3}$)/) { system("/usr/bin/wc $1"); } else { print "non-conformant file name: %filen"; } }

Perl Taint Mode Exercise Run the program and modify it to answer the following questions – perl –w. T taint. pl filename. txt 2 file 2. txt What happens 1. 2. 3. 4. If you don't purge the PATH environment variable? If you don't use a regular expression? If you use system("/usr/bin/wc", $file)? If the regular expression is changed to m/(. *)/?

Cryptographic Assurances Idea: use mathematical operations that support: – – Authentication Accountability (incl. non-repudiation) Confidentiality (e. g. , encryption) Integrity (e. g. , encrypted hashes, a. k. a. signatures) Related Programming Errors – Change order of operations – Omit operations – Misunderstood algorithm or protocol Vague specifications – Randomness issues

Cryptographic Use of Cookies Encryption may allow you to trust cookies for storage Related Mistake: Plaintext Storage in Cookie, 315 – CAN-2002 -1800 - Admin password in plaintext in a cookie. – CAN-2001 -1537 - Default configuration has cleartext usernames/passwords in cookie. – CAN-2001 -1536 - Usernames/passwords in cleartext in cookies. – CAN-2005 -2160 - Authentication information stored in cleartext in a cookie.

Certificates issues (295) Certificates allow cryptographic operations that authenticate hosts Complex and Lengthy Procedure – Failure to follow chain of trust in certificate validation (296) – Failure to validate host-specific certificate data (297) No Open. SSL Certificate Check Performed before this Use (599) – Certificate may be valid, but for a *different* host! – Failure to validate certificate expiration (298) – Failure to check for certificate revocation (299) – Race condition in checking for certificate revocation (370)

More Trust basis Trust analysis and validation – Formal trust and policies – Trust types – Trust modeling Trust verification and limitation – Authentication – Access control – Process privileges

Why do you trust? Reduce costs – Economies of scale – Fewer tests – Simpler procedures Benefit from the skills of another Delegate and gain – Power – Focus Hopefully, not because you have no choice – that's not trust, it's being dependent and at the mercy of. . . Need to balance risks and benefits – What are threats?

Trust Types Direct – You perform the validation yourself – No delegation Transitive – Entities with the same standards and criteria trust the evaluation results of the others A trusts B B trusts C A trusts C transitively through B Assumptive (a. k. a. "spontaneous") – Trusting the results of an evaluation conducted with different standards, criteria or procedures

Example Assumptive Trust A friend tells you that Brand Z's mint ice cream is great, so you buy some. – Your tastes are somewhat different but you trust the evaluation Can you provide another example?

Example Assumptive Trust #2 PGP chain of trust – Signing another's key – What are the criteria and procedures? – You have to accept the signature or not, even if you require 8 pieces of ID, and someone else may sign just on someone's word PGP key signing is not quite transitive trust Example adapted from Andert et al. (2002), Sun Blueprints Online

Foundations of Trust Identification Authentication Accountability Authorization Availability

Trust Modeling Who and what do you trust? – Trust binds a property or attribute (expected behavior) to an identifiable asset – Need authentication to assert identity – Need access control to provide just enough authority for desired capabilities

Trust Model A trust model is expressed in relation to a threat model – How can you trust that the threats won't materialize? Specify defense mechanisms – e. g. , security functional requirements Change design if necessary Validate implementation Cost/benefit analysis – Threats vs Defense mechanisms More expensive design options More expensive assurance requirements and processes

Threat Modeling Identify and enumerate threats – Data flow analysis design implementation correctness – Who could do what? Insider threats are usually significant – Insiders are not necessarily your co-workers » e. g. , anyone who can access your internal LAN. . . Analyze possible costs of exploits Danger: shape threat model with what we know how to solve cheaply, instead of what the threats really are – Discussion: http: //iang. org/ssl/wytm. html

Authentication Trust is specific to a user, asset, protocol, applet or group thereof, so identity must be verified – Identity verification is called authentication Principle of Separation of Privileges – Increase trust by requiring that several conditions be met, e. g. , authentication by several different mechanisms – Two- or three-factor authentication e. g. , owned by different people who must all agree – – Nuclear missiles Bank accounts

Goal of Access Controls Limit a user or asset to capabilities that match the trust model and policies Provide guarantees about the transfer of capabilities and the properties of assets Tradeoff of flexibility vs complexity and administration costs Multiple simultaneous mechanisms are possible

Access Control Types All or none (access to system is complete or nil) Discretionary a. k. a. Identity-based – Object owner can decide access by others Mandatory, a. k. a. rule-based – Owner can't change or control access by others Originator-controlled – Current owner can't change access, but creator can Role-based – Role is a template applied to a user's privileges Policy engines – Real-time interpretation of policies

Access Control Management Access control lists Access control matrix Central server and distributed services – Kerberos – Session ID valid over several related web sites, or services

Conclusions There are different types and levels of trust Erecting clear trust boundaries helps programmers manage trust consistently and systematically Trust is managed with: – – Input validation Authentication Access control Assurances Code quality Cryptographic assurances According to policies and a trust model

Questions?

About These Slides You are free to copy, distribute, display, and perform the work; and to make derivative works, under the following conditions. – You must give the original author and other contributors credit – The work will be used for personal or non-commercial educational uses only, and not for commercial activities and purposes – For any reuse or distribution, you must make clear to others the terms of use for this work – Derivative works must retain and be subject to the same conditions, and contain a note identifying the new contributor(s) and date of modification – For other uses please contact the Purdue Office of Technology Commercialization. Developed thanks to the support of Symantec Corporation

Pascal Meunier pmeunier at CERIAS Contributors: Jared Robinson, Alan Krassowski, Craig Ozancin, Tim Brown, Wes Higaki, Melissa Dark, Chris Clifton, Gustavo Rodriguez-Rivera