DOCSLIB.ORG

Printf("Function %S Is at Address %016X\N", Name, Addr);

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Printf( Outline Exercise: using Unix permissions CSci 4271W Injection vulnerabilities: format strings Development of Secure Software Systems Day 9: More Unix Access Control Logistics announcements Stephen McCamant Good technical writing (pt. 1) University of Minnesota, Computer Science & Engineering More Unix permissions Setting: files related to this class Users and groups Student and course staff materials Users: smccaman (instructor), paul1155 (TA), Imagine everything is in Unix files on CSE Labs stude003 (student) Versus reality of a mixture of Unix with web-based Groups: csci4271staff (instructor and TA), csci4271all systems like Canvas (staff and students) What I want from you Outline Exercise: using Unix permissions First, think of a kind of file/directory/information that would be relevant to the class Injection vulnerabilities: format strings Then, decide on the appropriate octal permissions Logistics announcements bits, plus owner and group, that would be appropriate Then repeat with a new resource, looking for one Good technical writing (pt. 1) with different permissions bits More Unix permissions Injection vulnerabilities printf reminder printf (and related functions like fprintf are a Common dangerous pattern: interpreter code with convenient way to produce formatted output attacker control The format string argument contains format eval Interpreted language example: specifiers (starting with %) controlling how the other OS example: shell script injection arguments are interpreted Web examples: JavaScript (XSS), SQL injection printf("Function %s is at address %016x\n", C library example: printf format string name, addr); Variable arguments functions Format string attack In secure code, format strings should not be under printf C has special features for functions like that external control take a varying number of arguments Common case: just constant strings Macros va_start, va_arg, etc. What malicious things can an attacker do via a Compiler can’t check type or number of arguments format string? Args will be stored on stack, for pointer access Step one: add extra integer specifiers, dump stack Already useful for information disclosure Format string attack layout Format string attack layout Format string attack: overwrite Practical format string challenges %n specifier: store number of chars written so far to pointer arg Attacker usually must control format as well as one Benign but uncommon use: account for length in other formatting or more arguments Writing a big value requires impractical output size Advance format arg pointer to other Workaround 1: overwrite two bytes with %hn attacker-controlled data Workaround 2: use overlapping unaligned write to control Control number of chars written with padding byte by byte Net result is a “write-what-where” primitive Format string defenses Outline Compilers will warn for printf that looks like it Exercise: using Unix permissions puts should just be Injection vulnerabilities: format strings Several platforms have decided to just remove %n Android Bionic, Visual Studio Logistics announcements %n Linux glibc by default will block if the format Good technical writing (pt. 1) string is writeable Major remaining use is information disclosure More Unix permissions Complete project 1 instructions posted Supplemental office hours Provides more detail beyond previous in-class I will host another office hour after class (5:15-6:15) announcements today Available from Assignments page of public site May continue based on demand Most important reminder: initial report due Friday by Please also take advantage of Piazza, we’ll be active 11:59pm there too Outline Writing in CS versus other writing Exercise: using Unix permissions Key goal is accurately conveying precise technical Injection vulnerabilities: format strings information Logistics announcements More important: careful use of terminology, structured organization Good technical writing (pt. 1) Less important: writer’s personality, appeals to More Unix permissions emotion Still important: concise expression Know your audience When technical terminology makes your point clearly, use it Don’t use long words or complicated expressions But provide definitions if a concept might be new to when simpler ones would convey the same meaning many readers Be careful to provide the right information in the definition Beneficial for both clarity and style Define at the first instead of a later use On other hand, avoid introducing too many new terms Reuse the same term when referring to the same concept Precise explanations Provide structure Don’t say “we” do something when it’s the computer that does it Use plenty of sections and sub-sections And avoid passive constructions It’s OK to have some redundancy in previewing Don’t anthropomorphize (computers don’t “know”) structure Use singular by default so plural provides a Limit each paragraph to one concept, and not too distinction: long - The students take tests Start with a clear topic sentence + Each student takes a test + Each student takes multiple tests Outline Process UIDs and setuid(2) Exercise: using Unix permissions UID is inherited by child processes, and an Injection vulnerabilities: format strings unprivileged process can’t change it Logistics announcements But there are syscalls root can use to change the UID, starting with setuid Good technical writing (pt. 1) E.g., login program, SSH server More Unix permissions Setuid programs, different UIDs More different UIDs If 04000 “setuid” bit set, newly exec’d process will Two mechanisms for temporary switching: take UID of its file owner Swap real UID and effective UID (BSD) Other side conditions, like process not traced Remember saved UID, allow switching to it (System V) Specifically the effective UID is changed, while the Modern systems support both mechanisms at the real UID is unchanged same time Shows who called you, allows switching back Setgid, games Special case: /tmp Setgid bit 02000 mostly analogous to setuid We’d like to allow anyone to make files in /tmp But note no supergroup, so UID 0 is still special So, everyone should have write permission Classic application: setgid games for managing But don’t want Alice deleting Bob’s files high-score files Solution: “sticky bit” 01000 Special case: group inheritance Other permission rules When using group to manage permissions, want a Only file owner or root can change permissions whole tree to have a single group Only root can change file owner When 02000 bit set, newly created entries with chown have the parent’s group Former System V behavior: “give away ” chown (Historic BSD behavior) Setuid/gid bits cleared on Set owner first, then enable setuid Also, directories will themselves inherit 02000.
Load more

Recommended publications
  • Buffer Overflow Exploits
    Buffer overflow exploits EJ Jung A Bit of History: Morris Worm Worm was released in 1988 by Robert Morris • Graduate student at Cornell, son of NSA chief scientist • Convicted under Computer Fraud and Abuse Act, sentenced to 3 years of probation and 400 hours of community service • Now a computer science professor at MIT Worm was intended to propagate slowly and harmlessly measure the size of the Internet Due to a coding error, it created new copies as fast as it could and overloaded infected machines $10-100M worth of damage Morris Worm and Buffer Overflow One of the worm’s propagation techniques was a buffer overflow attack against a vulnerable version of fingerd on VAX systems • By sending special string to finger daemon, worm caused it to execute code creating a new worm copy • Unable to determine remote OS version, worm also attacked fingerd on Suns running BSD, causing them to crash (instead of spawning a new copy) For more history: • http://www.snowplow.org/tom/worm/worm.html Buffer Overflow These Days Most common cause of Internet attacks • Over 50% of advisories published by CERT (computer security incident report team) are caused by various buffer overflows Morris worm (1988): overflow in fingerd • 6,000 machines infected CodeRed (2001): overflow in MS-IIS server • 300,000 machines infected in 14 hours SQL Slammer (2003): overflow in MS-SQL server • 75,000 machines infected in 10 minutes (!!) Attacks on Memory Buffers Buffer is a data storage area inside computer memory (stack or heap) • Intended to hold pre-defined
    [Show full text]
  • Practical C Programming, 3Rd Edition
    Practical C Programming, 3rd Edition By Steve Oualline 3rd Edition August 1997 ISBN: 1-56592-306-5 This new edition of "Practical C Programming" teaches users not only the mechanics or programming, but also how to create programs that are easy to read, maintain, and debug. It features more extensive examples and an introduction to graphical development environments. Programs conform to ANSI C. 0 TEAM FLY PRESENTS Table of Contents Preface How This Book is Organized Chapter by Chapter Notes on the Third Edition Font Conventions Obtaining Source Code Comments and Questions Acknowledgments Acknowledgments to the Third Edition I. Basics 1. What Is C? How Programming Works Brief History of C How C Works How to Learn C 2. Basics of Program Writing Programs from Conception to Execution Creating a Real Program Creating a Program Using a Command-Line Compiler Creating a Program Using an Integrated Development Environment Getting Help on UNIX Getting Help in an Integrated Development Environment IDE Cookbooks Programming Exercises 3. Style Common Coding Practices Coding Religion Indentation and Code Format Clarity Simplicity Summary 4. Basic Declarations and Expressions Elements of a Program Basic Program Structure Simple Expressions Variables and Storage 1 TEAM FLY PRESENTS Variable Declarations Integers Assignment Statements printf Function Floating Point Floating Point Versus Integer Divide Characters Answers Programming Exercises 5. Arrays, Qualifiers, and Reading Numbers Arrays Strings Reading Strings Multidimensional Arrays Reading Numbers Initializing Variables Types of Integers Types of Floats Constant Declarations Hexadecimal and Octal Constants Operators for Performing Shortcuts Side Effects ++x or x++ More Side-Effect Problems Answers Programming Exercises 6.
    [Show full text]
  • System Calls and I/O
    System Calls and I/O CS 241 January 27, 2012 Copyright ©: University of Illinois CS 241 Staff 1 This lecture Goals Get you familiar with necessary basic system & I/O calls to do programming Things covered in this lecture Basic file system calls I/O calls Signals Note: we will come back later to discuss the above things at the concept level Copyright ©: University of Illinois CS 241 Staff 2 System Calls versus Function Calls? Copyright ©: University of Illinois CS 241 Staff 3 System Calls versus Function Calls Function Call Process fnCall() Caller and callee are in the same Process - Same user - Same “domain of trust” Copyright ©: University of Illinois CS 241 Staff 4 System Calls versus Function Calls Function Call System Call Process Process fnCall() sysCall() OS Caller and callee are in the same Process - Same user - OS is trusted; user is not. - Same “domain of trust” - OS has super-privileges; user does not - Must take measures to prevent abuse Copyright ©: University of Illinois CS 241 Staff 5 System Calls System Calls A request to the operating system to perform some activity System calls are expensive The system needs to perform many things before executing a system call The computer (hardware) saves its state The OS code takes control of the CPU, privileges are updated. The OS examines the call parameters The OS performs the requested function The OS saves its state (and call results) The OS returns control of the CPU to the caller Copyright ©: University of Illinois CS 241 Staff 6 Steps for Making a System Call
    [Show full text]
  • XL C/C++ for AIX, V13.1.2 IBM
    IBM XL C/C++ for AIX, V13.1.2 IBM Optimization and Programming Guide Version 13.1.2 SC27-4261-01 IBM XL C/C++ for AIX, V13.1.2 IBM Optimization and Programming Guide Version 13.1.2 SC27-4261-01 Note Before using this information and the product it supports, read the information in “Notices” on page 185. First edition This edition applies to IBM XL C/C++ for AIX, V13.1.2 (Program 5765-J07; 5725-C72) and to all subsequent releases and modifications until otherwise indicated in new editions. Make sure you are using the correct edition for the level of the product. © Copyright IBM Corporation 1996, 2015. US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents About this document ........ vii Using a heap ............. 33 Who should read this document ....... vii Getting information about a heap ...... 34 How to use this document ......... vii Closing and destroying a heap ....... 34 How this document is organized ....... vii Changing the default heap used in a program .. 35 Conventions .............. viii Compiling and linking a program with Related information ........... xii user-created heaps ........... 35 IBM XL C/C++ information ........ xii Example of a user heap with regular memory .. 35 Standards and specifications ....... xiii Debugging memory heaps ......... 36 Other IBM information ......... xiv Functions for checking memory heaps .... 37 Other information ........... xiv Functions for debugging memory heaps .... 37 Technical support ............ xiv Using memory allocation fill patterns..... 39 How to send your comments ........ xiv Skipping heap checking ......... 39 Using stack traces ........... 40 Chapter 1.
    [Show full text]
  • CM-5 C* User's Guide
    The Connection Machine System CM-5 C* User's Guide ---------__------- . Version 7.1 May 1993 Thinking Machines Corporation Cambridge, Massachusetts Frst printing, May 1993 The informatiaonin this document is subject to change without notice and should not be constnued as a commitmentby ThinngMacMachines po Thk Machinesreservestheright toae changesto any product described herein Although the information inthis document has beenreviewed and is believed to bereliable, Thinldng Machines Coaporation assumes no liability for erns in this document Thinklng Machines does not assume any liability arising from the application or use of any information or product described herein Connection Machine is a registered traemark of Thinking Machines Corporation. CM and CM-5 are trademarks of Thinking Machines Corpoation. CMosr, Prism, and CMAX are trademaks of Thinking Machines Corporation. C*4is a registered trademark of Thinking Machines Corporation CM Fortran is a trademark of Thinking Machines Corporation CMMD,CMSSL, and CMXIl are tdemarks of Thinking Machines Corporation. Thinking Machines is a registered trademark of Thinking Machines Corporatin. SPARCand SPARCstationare trademarks of SPARCintematinal, Inc. Sun, Sun,4, and Sun Workstation are trademarks of Sun Microsystems, Inc. UNIX is a registered trademark of UNIX System Laboratoies, Inc. The X Window System is a trademark of the Massachusetts Institute of Technology. Copyright © 1990-1993 by Thinking Machines Corporatin. All rights reserved. Thinking Machines Corporation 245 First Street Cambridge, Massachusetts 02142-1264 (617) 234-1000 Contents About This Manual .......................................................... viU Custom Support ........................................................ ix Chapter 1 Introduction ........................................ 1 1.1 Developing a C* Program ........................................ 1 1.2 Compiling a C* Program ......................................... 1 1.3 Executing a C* Program ........................................
    [Show full text]
  • Automatic Discovery of API-Level Vulnerabilities
    Automatic Discovery of API-Level Vulnerabilities Vinod Ganapathyy, Sanjit A. Seshiaz, Somesh Jhay, Thomas W. Repsy, Randal E. Bryantz yComputer Sciences Department, zSchool of Computer Science, University of Wisconsin-Madison Carnegie Mellon University fvg|jha|[email protected] fsanjit|[email protected] UW-MADISON COMPUTER SCIENCES TECHNICAL REPORT: UW-CS-TR-1512, JULY 2004. Abstract A system is vulnerable to an API-level attack if its security can be compromised by invoking an allowed sequence of operations from its API. We present a formal framework to model and analyze APIs, and develop an automatic technique based upon bounded model checking to discover API-level vulnerabilities. If a vulnerability exists, our technique produces a trace of API operations demonstrating an attack. Two case studies show the efficacy of our technique. In the first study we present a novel way to analyze printf-family format-string attacks as API-level attacks, and implement a tool to discover them automatically. In the second study, we model a subset of the IBM Common Cryptographic Architecture API, a popular cryptographic key-management API, and automatically detect a previously known vulnerability. 1 Introduction Software modules communicate through application programming interfaces (APIs). Failure to respect an API's usage conventions or failure to understand the semantics of an API may lead to security vulnerabilities. For instance, Chen et al. [13] demonstrated a security vulnerability in sendmail-8.10.1that was due to a misunderstanding of the semantics of UNIX user-id setting commands. A programmer mistakenly assumed that setuid(getuid()) would always drop all privileges.
    [Show full text]
  • The AWK Programming Language
    The Programming ~" ·. Language PolyAWK- The Toolbox Language· Auru:o V. AHo BRIAN W.I<ERNIGHAN PETER J. WEINBERGER TheAWK4 Programming~ Language TheAWI(. Programming~ Language ALFRED V. AHo BRIAN w. KERNIGHAN PETER J. WEINBERGER AT& T Bell Laboratories Murray Hill, New Jersey A ADDISON-WESLEY•• PUBLISHING COMPANY Reading, Massachusetts • Menlo Park, California • New York Don Mills, Ontario • Wokingham, England • Amsterdam • Bonn Sydney • Singapore • Tokyo • Madrid • Bogota Santiago • San Juan This book is in the Addison-Wesley Series in Computer Science Michael A. Harrison Consulting Editor Library of Congress Cataloging-in-Publication Data Aho, Alfred V. The AWK programming language. Includes index. I. AWK (Computer program language) I. Kernighan, Brian W. II. Weinberger, Peter J. III. Title. QA76.73.A95A35 1988 005.13'3 87-17566 ISBN 0-201-07981-X This book was typeset in Times Roman and Courier by the authors, using an Autologic APS-5 phototypesetter and a DEC VAX 8550 running the 9th Edition of the UNIX~ operating system. -~- ATs.T Copyright c 1988 by Bell Telephone Laboratories, Incorporated. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopy­ ing, recording, or otherwise, without the prior written permission of the publisher. Printed in the United States of America. Published simultaneously in Canada. UNIX is a registered trademark of AT&T. DEFGHIJ-AL-898 PREFACE Computer users spend a lot of time doing simple, mechanical data manipula­ tion - changing the format of data, checking its validity, finding items with some property, adding up numbers, printing reports, and the like.
    [Show full text]
  • User's Manual
    rBOX610 Linux Software User’s Manual Disclaimers This manual has been carefully checked and believed to contain accurate information. Axiomtek Co., Ltd. assumes no responsibility for any infringements of patents or any third party’s rights, and any liability arising from such use. Axiomtek does not warrant or assume any legal liability or responsibility for the accuracy, completeness or usefulness of any information in this document. Axiomtek does not make any commitment to update the information in this manual. Axiomtek reserves the right to change or revise this document and/or product at any time without notice. No part of this document may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of Axiomtek Co., Ltd. Trademarks Acknowledgments Axiomtek is a trademark of Axiomtek Co., Ltd. ® Windows is a trademark of Microsoft Corporation. Other brand names and trademarks are the properties and registered brands of their respective owners. Copyright 2014 Axiomtek Co., Ltd. All Rights Reserved February 2014, Version A2 Printed in Taiwan ii Table of Contents Disclaimers ..................................................................................................... ii Chapter 1 Introduction ............................................. 1 1.1 Specifications ...................................................................................... 2 Chapter 2 Getting Started ......................................
    [Show full text]
  • Operating System Lab Manual
    OPERATING SYSTEM LAB MANUAL BASICS OF UNIX COMMANDS Ex.No:1.a INTRODUCTION TO UNIX AIM: To study about the basics of UNIX UNIX: It is a multi-user operating system. Developed at AT & T Bell Industries, USA in 1969. Ken Thomson along with Dennis Ritchie developed it from MULTICS (Multiplexed Information and Computing Service) OS. By1980, UNIX had been completely rewritten using C langua ge. LINUX: It is similar to UNIX, which is created by Linus Torualds. All UNIX commands works in Linux. Linux is a open source software. The main feature of Linux is coexisting with other OS such as windows and UNIX. STRUCTURE OF A LINUXSYSTEM: It consists of three parts. a)UNIX kernel b) Shells c) Tools and Applications UNIX KERNEL: Kernel is the core of the UNIX OS. It controls all tasks, schedule all Processes and carries out all the functions of OS. Decides when one programs tops and another starts. SHELL: Shell is the command interpreter in the UNIX OS. It accepts command from the user and analyses and interprets them 1 | P a g e BASICS OF UNIX COMMANDS Ex.No:1.b BASIC UNIX COMMANDS AIM: To study of Basic UNIX Commands and various UNIX editors such as vi, ed, ex and EMACS. CONTENT: Note: Syn->Syntax a) date –used to check the date and time Syn:$date Format Purpose Example Result +%m To display only month $date+%m 06 +%h To display month name $date+%h June +%d To display day of month $date+%d O1 +%y To display last two digits of years $date+%y 09 +%H To display hours $date+%H 10 +%M To display minutes $date+%M 45 +%S To display seconds $date+%S 55 b) cal –used to display the calendar Syn:$cal 2 2009 c)echo –used to print the message on the screen.
    [Show full text]
  • CENG328 Operating Systems Laboratory Chapter 7
    CENG328 Operating Systems Laboratory Chapter 7 1 File System Unix and Linux based operating systems use specific filesystems (ext2 / ext3 / ext4, xfs, btrfs, etc) for storing files, directories and other filesystem objects such as links, pipes and sockets. These filesystems usually store information such as filename, size, inode number, owning user / group info, access modes, timestamps, etc. When listing files with ls command, these different file types can be recognized by the first character next to the permissions: • Regular File: Stores data (text, image, audio...) that can be read/written by programs. Denoted by \-" sign. • Directory: A data structure that stores other files, directories, etc. Denoted by \d" sign. • Link: A softlink (symlink) is a file that acts as a pointer to another file. Denoted by \l" sign. • Socket: A filesystem-level IPC method to establish communication between processes. Denoted by \s" sign. • Pipe: A filesystem-level IPC method to establish communication between processes. Denoted by \p" sign. • Character device: A device which the driver communicates with single characters. Denoted by \c" sign. • Block device: A device which the driver communicates with blocks of data. Denoted by \b" sign. $ ls drwxrwxr-x 2 user user 4096 May 3 18:29 backups lrwxrwxrwx 1 user user 6 May 3 18:29 list -> list.1 -rw-rw-r-- 1 user user 132 May 3 18:29 list.0 -rw-rw-r-- 1 user user 218 May 3 18:29 list.1 -rw-rw-r-- 1 user user 63 May 3 18:29 list.2 brw-rw---- 1 root disk 7, 6 Apr 24 10:11 sda1 prw-rw-r-- 1 user user 0 May 3 18:29 somepipe
    [Show full text]
  • A Type System for Format Strings E
    ifact t * r * Comple t te A A n * te W E is s * e C n l l o D C A o * * c T u e m S s E u e S e n I R t v A Type System for Format Strings e o d t y * s E a * a l d u e a t Konstantin Weitz Gene Kim Siwakorn Srisakaokul Michael D. Ernst University of Washington, USA {weitzkon,genelkim,ping128,mernst}@cs.uw.edu ABSTRACT // Untested code (Hadoop) Most programming languages support format strings, but their use Resource r = ... format("Insufficient memory %d", r); is error-prone. Using the wrong format string syntax, or passing the wrong number or type of arguments, leads to unintelligible text // Unchecked input (FindBugs) output, program crashes, or security vulnerabilities. String urlRewriteFormat = read(); This paper presents a type system that guarantees that calls to format(urlRewriteFormat, url); format string APIs will never fail. In Java, this means that the API will not throw exceptions. In C, this means that the API will not // User unaware log is a format routine (Daikon) log("Exception " + e); return negative values, corrupt memory, etc. We instantiated this type system for Java’s Formatter API, and // Invalid syntax for Formatter API (ping-gcal) evaluated it on 6 large and well-maintained open-source projects. format("Unable to reach {0}", server); Format string bugs are common in practice (our type system found Listing 1: Real-world code examples of common programmer 104 bugs), and the annotation burden on the user of our type system mistakes that lead to format routine call failures.
    [Show full text]
  • Automatic Protection from Printf Format String Vulnerabilities
    USENIX Association Proceedings of the 10th USENIX Security Symposium Washington, D.C., USA August 13–17, 2001 THE ADVANCED COMPUTING SYSTEMS ASSOCIATION © 2001 by The USENIX Association All Rights Reserved For more information about the USENIX Association: Phone: 1 510 528 8649 FAX: 1 510 548 5738 Email: [email protected] WWW: http://www.usenix.org Rights to individual papers remain with the author or the author's employer. Permission is granted for noncommercial reproduction of the work for educational or research purposes. This copyright notice must be included in the reproduced paper. USENIX acknowledges all trademarks herein. FormatGuard: Automatic Protection From printf Format String Vulnerabilities Crispin Cowan, Matt Barringer, Steve Beattie, and Greg Kroah-Hartman WireX Communications, Inc. http://wirex.com/ Mike Frantzen Jamie Lokier Purdue University CERN Abstract their trouble. Since June 2000, format bugs have eclipsed buffer overflow vulnerabilities for the most In June 2000, a major new class of vulnerabilities called common form of remote penetration vulnerability. “format bugs” was discovered when an vulnerability in WU-FTP appeared that acted almost like a buffer over- There are several obvious solutions to this problem, flow, but wasn’t. Since then, dozens of format string which unfortunately don’t work: vulnerabilities have appeared. This paper describes the format bug problem, and presents FormatGuard: our Remove the %n feature: The printf %n directive is proposed solution. FormatGuard is a small patch to the most dangerous, because it induces printf to glibc that provides general protection against format write data back to the argument list. It has been pro- bugs.
    [Show full text]