DOCSLIB.ORG

Incorporating Cert Secure Coding Standards in Terms of Undefined Behavior and Useless Conditions Into the Cppcheck Project

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Incorporating Cert Secure Coding Standards in Terms of Undefined Behavior and Useless Conditions Into the Cppcheck Project INCORPORATING CERT SECURE CODING STANDARDS IN TERMS OF UNDEFINED BEHAVIOR AND USELESS CONDITIONS INTO THE CPPCHECK PROJECT A thesis submitted to Kent State University in partial fulfillment of the requirements for the degree of Master of Science in Computer Science By Anwar Alsulaiman August 16th, 2014 Thesis written by Anwar Alsulaiman B.S., King Faisal University, KSA 2009 M.S., Kent State University, USA 2014 Approved by Dr. Michael Rothstein , Advisor Dr. Javed I. Khan , Chair, Department of Computer Science Dr. James Blank , Dean, College of Arts and Sciences ii TABLE OF CONTENTS LIST OF FIGURES ........................................................................................................ VI LIST OF TABLES ......................................................................................................... VII ACKNOWLEDGEMENTS ........................................................................................ VIII CHAPTER 1 INTRODUCTION ....................................................................................... 1 1.1 Open Source Software ................................................................................................ 1 1.1.1 History .............................................................................................................. 1 1.1.2 What is Open Source? ...................................................................................... 2 1.1.3 Open Source vs. Closed Source ....................................................................... 3 1.2 CPPCHECK ................................................................................................................ 5 1.2.1 How Does CPPCHECK Work? ....................................................................... 6 1.2.1.1 Control Flow Analysis ...................................................................................... 6 1.2.2.2 Token List Method ......................................................................................... 10 1.3 CERT ........................................................................................................................ 13 1.3.1 What is CERT? ............................................................................................... 13 1.3.2 CERT Secure Coding Standards .................................................................... 13 CHAPTER 2 STATIC CODE ANALYSIS TOOLS ..................................................... 15 2.1 What is Static Code Analysis? .................................................................................. 15 2.2 Static Code Analysis Methods .................................................................................. 15 2.3 Advantages and Disadvantages of Static Code Analysis ......................................... 16 2.4 Most Popular Commercial Static Code Analysis Tools ........................................... 17 2.4.1 PC-Lint ........................................................................................................... 17 2.4.2 Klockwork Insight .......................................................................................... 18 2.4.3 Coverity Prevent ............................................................................................. 18 2.5 Static Code Analysis Types ...................................................................................... 18 2.5.1 Non-Annotated Static Code Analyzers .......................................................... 19 2.5.2 Annotated Static Code Analyzers ................................................................... 20 2.5.2.1 Splint .............................................................................................................. 20 2.5.2.2 CSSV .............................................................................................................. 21 2.5.2.3 CQUAL .......................................................................................................... 22 2.5.2.4 Meta-Complication (MC) ............................................................................... 22 2.5.2.5 CPPCHECK ................................................................................................... 22 2.6 Why CPPCHECK? ................................................................................................... 23 CHAPTER 3 CONTRIBUTION TO CPPCHECK ....................................................... 24 3.1 CPPCHECK Environment ........................................................................................ 24 3.2 The Procedure of New Checks Implementation ....................................................... 25 3.3 Implemented CERT Rules Checks ........................................................................... 27 3.3.1 ARR02-C/C++ (Explicitly specify array bounds, even if implicitly defined by an initialize) ................................................................................................................ 27 3.3.2 EXP01-C/C++ (Do not take the size of a pointer to determine the size of the pointed-to type): ......................................................................................................... 30 3.3.3 FIO01-C/C++ (Be careful using functions that use file names for identification) ............................................................................................................. 32 3.3.4 FIO17-C/C++ (Prefer streams to C-style input and output) ........................... 36 iv 3.3.5 INT06-C/C++ (Use strtol ( ) or a related function to convert string token to an integer) ................................................................................................................... 38 3.3.6 CON30-C/C++ (Clean up thread-specific storage) ........................................ 39 3.3.7 SIG32-C/C++ (Do not call longjmo ( ) from inside signal handler) .............. 41 3.3.8 STR32-C/C++ (Do not pass a non-null-terminated character sequence to a library function that expects a string) ......................................................................... 43 CHAPTER 4 FUTURE WORKS .................................................................................... 45 4.1 Adding a Setting in CPPCHECK Library ................................................................ 45 Example (string copy) ................................................................................................ 47 Example (buffer size smaller than size parameter) .................................................... 47 CHAPTER 5 CONCLUSION .......................................................................................... 48 APPENDIX A ................................................................................................................... 49 APPENDIX B ................................................................................................................... 52 REFRENCES ................................................................................................................. 155 v LIST OF FIGURES Figure 1.1: Token list method mechanism ........................................................................ 10 Figure 1.2: Example of token list method process ............................................................ 12 Figure 3.1: Flowchart of ARR02 rule ................................................................................ 29 Figure 3.2: Flowchart of EXP02 rule ................................................................................ 30 Figure 3.3: Flowchart of FIO01_1 rule ............................................................................. 33 Figure 3.4: Flowchart of FIO01_2 rule ............................................................................. 34 Figure 3.5: Flowchart of FIO17 rule ................................................................................. 36 vi LIST OF TABLES Table 1.1: Open source software project vs. closed source software project ...................... 4 Table 2.1: Average cost of fixing defects depending on the time they were detected ...... 17 ACKNOWLEDGEMENTS My master degree thesis would not have been possible without the support of many caring individuals in my life including supporting faculties and family members. First in the list is my advisor, Dr. M. Rothstein, who helped me to make sense by directing my thinking to the right path and paving the road for this study. As a result, he added value to my work in order to accomplish this important milestone toward fulfilling my objective. Of course, many thanks go to my supporting thesis committee members, Dr. M. Austin, and Dr. H. Peyravi, who valued and accepted my study. Moreover, I would not forget the support of my husband, parents, and numerous friends who endured this long process with me, always offering support and love. Cheers to all of them! Anwar Alsulaiman June 14, 2014, Kent, Ohio viii CHAPTER 1 Introduction In this thesis, we propose a way to make the open source software project called CPPCHECK as secure as possible by adding high-potential static checkers for program vulnerabilities. Therefore, we are looking to implement static checkers with high-level security standards. The Computer Emergency Response Team (CERT) secure coding standards meet our requirements. In particular, this thesis will address the security limitation of CPPCHECK in the detection of undefined behavior and useless conditions. We will use new techniques of modeling these more elaborate rules’ checkers using the token list and initial rule file methods, which are feasible for this project,
Load more

Recommended publications
  • 1.1 Introduction to C Language
    1.1 Introduction to C Language 1 Department of CSE Objectives • To understand the structure of a C-Language Program • To write a minimal C program • To introduce the include preprocessor command • To be able to create good identifiers for quantities in a program • To be able to list, describe and use the basic data types in C • To be able to create and use variables and constants in a C program 2 Department of CSE Agenda • Background of C Language • Structure of a C program • C Comments • Identifiers in C • Data types in C • Variables in C • Constants in C 3 Department of CSE Background of C • C is a middle level language it combines the best elements of high-level languages with the control and flexibility of assembly language • Like most modern languages, C is also derived from ALGOL 60 (1960) • Developed by Dennis Ritchie in 1972 using many concepts from its predecessors – ALGOL,BCPL and B and by adding the concept of data types • American National Standards Institute (ANSI) began the standardization of C in 1983 which was approved in 1989 • In 1990 International Standards Organization (ISO) adopted the ANSI standard version known as C89 • Minor changes were made to C89 in 1995 which came to be known as C95 • Much more significant updates were made in 1999 and named as C99 4 Department of CSE Features of C • C is a structured programming language which allows compartmentalization of code and data • A structured language offers a variety of programming possibilities. For example, structured languages typically support several loop constructs, such as while, do-while, and for.
    [Show full text]
  • Washington Apple Pi Journal, May 1988
    Wa1hington Journal of WasGhington Appl e Pi, Ltd Volume. 10 may 1988 number 5 Hiahliaht.1 ' . ~ The Great Apple Lawsuit- (pgs4&so) • Timeout AppleWorks Enhancements - I IGs •Personal Newsletter & Publish It! ~ MacNovice: Word Processing- The Next Generati on ~ Views & Reviews: MidiPaint and Performer ~ Macintosh Virus: Technical Notes In This Issue. Officers & Staff, Editorial ................................ ...................... 3 Personal Newsletter and Publish It! .................... Ray Settle 40* President's Corner ........................................... Tom Warrick 4 • GameSIG News ....................................... Charles Don Hall 41 Event Queue, General Information, Classifieds ..................... 6 Plan for Use of Tutorial Tapes & Disks ................................ 41 AV-SIG News .............................................. Nancy Sefcrian 6 The Design Page for W.A.P .................................. Jay Rohr 42 Commercial Classifieds, Job Mart .......................................... 7 MacNovice Column: Word Processing .... Ralph J. Begleiter 47 * WAP Calendar, SIG News ..................................................... 8 Developer's View: The Great Apple Lawsuit.. ..... Bill Hole 50• WAP Hotline............................................................. ............. 9 Macintosh Bits & Bytes ............................... Lynn R. Trusal 52 Q & A ............................... Robert C. Platt & Bruce F. Field 10 Macinations 3 .................................................. Robb Wolov 56 Using
    [Show full text]
  • Download, Including1 17N REU, Ramlink Partition, Jimymon-64 (ML Monitor)
    C 0 T E T S ISSUE Published June 1996 COMMODORE WORLD 6 Wheels-Laying More Than A Patch THE NEWS MAGAZINE FOR COMMODORE 64 » 1'■ I 1J',[ K1. Bruce Thonuu 14 GOFA-A Modulap- Pcogpamming System Fob The Coeimodore 64 http://wviw.cmiweb.am/cwhtme.hlml George Flanagan General Manager Chinks ft Christiansen ♦ Editor Review; Doug Cot Ion ♦ 24 Software: Centipede 126 E>r Gaelwe R. Gasson Advegtisinq Sales A Look ai ihe Newesi Commodore I2S BBS Program Charles A. Christiansen (413) 525-0023 ♦ Graphic Acts Doug Cotton .UMN! '♦ 26 Jusr Fob Starters by Jason Compton Electronic Pre-Press & Pointing Maiuir/Holden Helpful Hints for Handling Disk Drives ♦ 30 Graphic Interpretation by Bruce Thomas Cover Design by Doug Cotton GEOS: For ti Good lime... 32 Carrier Detect by Gaelyne B. Gasson Tclecommunicationi News & Updates 36 S16 Beat by Mark Fellows Things to Look Out For When Program/Hint- the 65X16 Commodore1" and [he respective Commodore producl names are trademarks or registered trademarks of Commodore, a 38 Over The Edge by Jeffrey L. Jones division of Tulip Compulers. Commodore World is in no way aftiliated wilrtthe owner n! ".he Commodore logo ana technology. Commodore Programming in a SuperCPU World Commodore Worla (ISSN 1078-2515) is published 8 limos annually by Creative Micro Designs. Inc.. 15 Benton Drive, Easl Longrneadow MA 01028-0646. Secono-Class Postage Paid at EasL Longmeaflow MA. (USPS «)n-801| Annual subscnpiion rale is USS29.95 fci U.S. addresses. USS35.95(orC3nada0'Maiico.USSJS.95!orallECCounlnB5. Department paymanlsmusl be provided in U S. Dollars. Mail subscriptions 2 From the Editor to CW Subscriptions, do Crestiva Micro Designs.
    [Show full text]
  • A Simple, Possibly Correct LR Parser for C11 Jacques-Henri Jourdan, François Pottier
    A Simple, Possibly Correct LR Parser for C11 Jacques-Henri Jourdan, François Pottier To cite this version: Jacques-Henri Jourdan, François Pottier. A Simple, Possibly Correct LR Parser for C11. ACM Transactions on Programming Languages and Systems (TOPLAS), ACM, 2017, 39 (4), pp.1 - 36. 10.1145/3064848. hal-01633123 HAL Id: hal-01633123 https://hal.archives-ouvertes.fr/hal-01633123 Submitted on 11 Nov 2017 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. 14 A simple, possibly correct LR parser for C11 Jacques-Henri Jourdan, Inria Paris, MPI-SWS François Pottier, Inria Paris The syntax of the C programming language is described in the C11 standard by an ambiguous context-free grammar, accompanied with English prose that describes the concept of “scope” and indicates how certain ambiguous code fragments should be interpreted. Based on these elements, the problem of implementing a compliant C11 parser is not entirely trivial. We review the main sources of difficulty and describe a relatively simple solution to the problem. Our solution employs the well-known technique of combining an LALR(1) parser with a “lexical feedback” mechanism. It draws on folklore knowledge and adds several original as- pects, including: a twist on lexical feedback that allows a smooth interaction with lookahead; a simplified and powerful treatment of scopes; and a few amendments in the grammar.
    [Show full text]
  • A Theory of Type Qualifiers
    A Theory of Type Qualifiers∗ Jeffrey S. Foster Manuel F¨ahndrich Alexander Aiken [email protected] [email protected] [email protected] EECS Department University of California, Berkeley Berkeley, CA 94720-1776 Abstract Purify [Pur]), which test for properties in a particular pro- gram execution. We describe a framework for adding type qualifiers to a lan- A canonical example of a type qualifier from the C world guage. Type qualifiers encode a simple but highly useful is the ANSI C qualifier const. A variable with a type an- form of subtyping. Our framework extends standard type notated with const can be initialized but not updated.1 A rules to model the flow of qualifiers through a program, primary use of const is annotating pointer-valued function where each qualifier or set of qualifiers comes with addi- parameters as not being updated by the function. Not only tional rules that capture its semantics. Our framework al- is this information useful to a caller of the function, but it lows types to be polymorphic in the type qualifiers. We is automatically verified by the compiler (up to casting). present a const-inference system for C as an example appli- Another example is Evans's lclint [Eva96], which intro- cation of the framework. We show that for a set of real C duces a large number of additional qualifier-like annotations programs, many more consts can be used than are actually to C as an aid to debugging memory usage errors. One present in the original code. such annotation is nonnull, which indicates that a pointer value must not be null.
    [Show full text]
  • S 314 Area Code BBS Directory
    FIRE ESCAPE'S St. Louis BBS Directory: MID-MARCH/APRIL 1996 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ All PREVIOUS "Directories" are now outdated, please delete them! The Deadline for the Mid-April/May 96 edition is April 14th! ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ BULLETIN BOARD SYSTEM NAME L# P PHONE # STATS SYSOP NAME HOURS MODEM SOFT ============================ == = ======== === ============= ===== ====== ==== 911 Online 09 - 872-9990 R ? 24 v.34-B WGRP ACME Acres BBS -- - 426-5159 *CR Wizlord 24 14.4-B SLGT Aerie BBS L1 - 773-8316 --- Journeyman 24 14.4-N VBBS Aerie BBS L2 - 773-8186 --- Journeyman 24 14.4-B VBBS Affinity BBS 26 - 771-6800 --- Aqualung 24 2.4-N MISC Affinity BBS 09 - 771-6300 --- Aqualung 24 9.6-B MISC Affinity BBS 04 - 771-9374 --- Aqualung 24 2.4-N MISC After Dark BBS -- - 227-9828 R Harvester 24 14.4-N WWIV After Thought -- - 423-6312 --- Shade Tree 24 14.4-B WWIV Alien BBS, The -- - 544-3668 --- Alien 24 2.4-N C-64 All Night Thing -- - 752-3308 R Dr. Tone 24 14.4-M WWIV Andromeda II BBS, The -- - 869-5171 A Linus 06-01 14.4-B TLGD A.R. Ware BBS -- - 231-9270 N? Weekend Warri 24 14.4-B UNKW Arena, The -- - 845-6849 C Jake Blues 24 v.34-B VBBS Asgardian Realm, The -- - 291-6762 R Lancer 24 DS34-B WWIV Babylon 7 -- - 926-2206 R Strider 24 v.34-B SLGT BadMedicine BBS -- T 341-5038 AR BadMedic 22-07 14.4-B TRI Balls & Shaft -- - 532-4409 --- Gambit 24 DS34-B WWIV Banana Republic, The -- - 282-3337 CR Dr.
    [Show full text]
  • Lclint User's Guide
    ÿþÿýüû LCLint User’s Guide ÿ Version 2.5 May 2000 David Evans University of Virginia Department of Computer Science ii LCLint User’s Guide Acknowledgments John Guttag and Jim Horning had the original idea for LCLint, have provided valuable advice on its functionality and design, and been instrumental in its development. This work has also benefited greatly from discussions with Mike Burrows, Stephen Garland, Colin Godfrey, Steve Harrison, Yanlin Huang, Daniel Jackson, John Knight, David Larochelle, Angelika Leeb, Ulana Legedza, Anya Pogosyants, Avneesh Saxena, Seejo Sebastine, Navneet Singh, Raymie Stata, Yang Meng Tan, and Mark Vandevoorde. I especially thank Angelika Leeb for many constructive comments on improving this document, Raymie Stata for help designing and setting up the LCLint web site, Mark Vandevoorde for technical assistance, and Dorothy Curtis and Paco Hope for systems assistance. Much of LCLint’s development has been driven by feedback from users in academia and industry. Many more people than I can mention here have made contributions by suggesting improvements, reporting bugs, porting early versions of LCLint to other platforms. Particularly heroic contributions have been made by Eric Bloodworth, Jutta Degener, Rick Farnbach, Chris Flatters, Huver Hu, John Gerard Malecki, Thomas G. McWilliams, Michael Meskes, Richard O’Keefe, Jens Schweikhardt, and Albert L. Ting. Martin “Herbert” Dietze and Mike Smith performed valiantly in producing the original Win32 and OS2 ports. LCLint incorporates the original LCL checker developed by Yang Meng Tan. This was built on the DECspec Project (Joe Wild, Gary Feldman, Steve Garland, and Bill McKeeman). The LSL checker used by LCLint was developed by Steve Garland.
    [Show full text]
  • Lecture Slides
    Security via Type Qualifiers Jeff Foster University of Maryland Joint work with Alex Aiken, Rob Johnson, John Kodumal, Tachio Terauchi, and David Wagner Introduction • Ensuring that software is secure is hard • Standard practice for software quality: – Testing • Make sure program runs correctly on set of inputs – Code auditing • Convince yourself and others that your code is correct Security Summer School, June 2004 2 1 Drawbacks to Standard Approaches • Difficult • Expensive • Incomplete • A malicious adversary is trying to exploit anything you miss! Security Summer School, June 2004 3 Tools for Security • What more can we do? – Build tools that analyze source code • Reason about all possible runs of the program – Check limited but very useful properties • Eliminate categories of errors • Let people concentrate on the deep reasoning – Develop programming models • Avoid mistakes in the first place • Encourage programmers to think about security Security Summer School, June 2004 4 2 Tools Need Specifications spin_lock_irqsave(&tty->read_lock, flags); put_tty_queue_nolock(c, tty); spin_unlock_irqrestore(&tty->read_lock, flags); • Goal: Add specifications to programs In a way that... – Programmers will accept • Lightweight – Scales to large programs – Solves many different problems Security Summer School, June 2004 5 Type Qualifiers • Extend standard type systems (C, Java, ML) – Programmers already use types – Programmers understand types – Get programmers to write down a little more... const int ANSI C ptr(tainted char) Format-string vulnerabilities
    [Show full text]
  • Flow-Insensitive Type Qualifiers
    Flow-Insensitive Type Qualifiers JEFFREY S. FOSTER University of Maryland, College Park and ROBERT JOHNSON and JOHN KODUMAL University of California, Berkeley and ALEX AIKEN Stanford University We describe flow-insensitive type qualifiers, a lightweight, practical mechanism for specifying and checking properties not captured by traditional type systems. We present a framework for adding new, user-specified type qualifiers to programming languages with static type systems, such as C and Java. In our system, programmers add a few type qualifier annotations to their program, and automatic type qualifier inference determines the remaining qualifiers and checks the annotations for consistency. We describe a tool CQual for adding type qualifiers to the C programming language. Our tool CQual includes a visualization component for displaying browsable inference results to the programmer. Finally, we present several experiments using our tool, including inferring const qualifiers, finding security vulnerabilities in several popular C programs, and checking initialization data usage in the Linux kernel. Our results suggest that inference and visualization make type qualifiers lightweight, that type qualifier inference scales to large programs, and that type qualifiers are applicable to a wide variety of problems. Categories and Subject Descriptors: D.2.1 [Software Engineering]: Requirements/Specifications; D.2.4 [Software Engineering]: Software/Program Verification; D.3.3 [Programming Lan- guages]: Language Constructs and Features; F.3.1 [Logics and Meanings of Programs]: Specifying and Verifying and Reasoning about Programs General Terms: Algorithms, Design, Reliability, Experimentation, Languages, Theory, Verification Additional Key Words and Phrases: Type qualifiers, types, security, constraints, const, taint, static analysis 1. INTRODUCTION Software continues to increase in size and complexity, yet our ability to ensure its quality lags behind.
    [Show full text]
  • XL C/C++: Language Reference the Static Storage Class Specifier
    IBM XL C/C++ for Blue Gene/Q, V12.1 Language Reference Ve r s i o n 12 .1 GC14-7364-00 IBM XL C/C++ for Blue Gene/Q, V12.1 Language Reference Ve r s i o n 12 .1 GC14-7364-00 Note Before using this information and the product it supports, read the information in “Notices” on page 511. First edition This edition applies to IBM XL C/C++ for Blue Gene/Q, V12.1 (Program 5799-AG1) 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 1998, 2012. US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents About this information ........ix The register storage class specifier ......54 Who should read this information .......ix The __thread storage class specifier (IBM How to use this information .........ix extension) ..............56 How this information is organized .......ix Type specifiers .............58 Conventions ..............x Integral types.............58 Related information ...........xiii Boolean types ............59 IBM XL C/C++ information .......xiii floating-point types...........59 Standards and specifications .......xiv Character types ............60 Other IBM information .........xv The void type ............61 Other information ...........xv Vector types (IBM extension) .......61 Technical support ............xv User-defined types ...........62 How to send your comments ........xv The auto type specifier (C++0x) ......81 The decltype(expression) type specifier (C++0x) . 83 Chapter 1. Scope and linkage .....1 Compatibility of arithmetic types (C only) ....88 Type qualifiers .............89 Scope .................2 The __align type qualifier (IBM extension) .
    [Show full text]
  • Type Qualifiers As Composable Language Extensions
    Type Qualifiers as Composable Language Extensions Travis Carlson Eric Van Wyk Computer Science and Engineering Computer Science and Engineering University of Minnesota University of Minnesota Minneapolis, MN, USA Minneapolis, MN, USA [email protected] [email protected] Abstract 1 Introduction and Motivation This paper reformulates type qualifiers as language exten- Type qualifiers in C and C++, such as const or restrict, sions that can be automatically and reliably composed. Type enable the programmer to disallow certain operations on qualifiers annotate type expressions to introduce new sub- qualified types and to indicate simple subtype relationships typing relations and are powerful enough to detect many between types. For example, only initializing assignments kinds of errors. Type qualifiers, as illustrated in our ableC are allowed on a variable declared with a const qualifier, extensible language framework for C, can introduce rich and a function with an argument declaration int *x cannot forms of concrete syntax, can generate dynamic checks on be passed a value of type const int * as this would allow data when static checks are infeasible or not appropriate, and changes to the const int via the pointer. The type int * inject code that affects the program’s behavior, for example is considered to be a subtype of const int *. for conversions of data or logging. In their seminal paper “A Theory of Type Qualifiers”, Fos- ableC language extensions to C are implemented as at- ter et al.[12] formalize this subtyping relationship and show tribute grammar fragments and provide an expressive mech- how user-defined type qualifiers can be added to a language anism for type qualifier implementations to check for ad- to perform additional kinds of checking.
    [Show full text]
  • FIRE ESCAPE's AREA CODE 314 BBS DIRECTORY: May 1998 Edition
    FIRE ESCAPE'S AREA CODE 314 BBS DIRECTORY: May 1998 Edition +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Phone numbers valid through: 06-01-1998 MAIL: [email protected], TELNET: fe.ddns.org, HTTP://fe.ddns.org, OR 314-741-0341 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ BBS NAME NUMBER BAUD SOFT SYSOP NAME LN# BBS CODES =========================== ======== ==== ==== =========== === ============ * 963-7751 14.4 WWIV Furious/Tex 1 - Absolute Zero 209-7228 33.6 WWIV AntiChrist 1 G Affinity BBS 771-6800 9600 DLX Aqualung 27 AT After Thought 423-6312 14.4 WWIV Shade Tree 1 - Alien BBS, The 544-3668 2400 CENT Alien 1 G Andromeda II BBS 227-9640 28.8 TLGD Linus 1 DFM Asgardian Realm, The 291-6762 33.6 WWIV Lancer 1 G Assassins For Hire 645-8995 28.8 WWIV Dr Assassin 1 M Babylon 7 926-2206 28.8 SLGT Strider 2 G Barb's Lookout Window 894-0919 14.4 WWIV Barb C 1 - BizNet 994-0957 ISDN WVUA William L. 12 $FIT Black Triangle 453-0662 28.8 WWIV Tracker 1 G Boeing Employees RCC STL BBS 830-4287 33.6 FIDO T. Mueller 1 M Bone Yard BBS, The 447-7999 v.FC WCAT Bones 2 FT Cave, The 629-6383 28.8 SPIT Caveman 4 DFGIT Changewinds BBS 426-8775 33.6 WWIV Stormie 1 MR Cindex Tech Support Hotline 837-5422 33.6 REMT John F. 1 - Dawg House, The 940-1253 33.6 WWIV Dawg 1 AFIM Diplomatic Herb, The 868-2558 33.6 WINS Floridian 5 $ACDFIT DWANGO 638-0722 14.4 UNID Ginter 64 $GT Eagle's Nest, The 544-3226 14.4 WWIV Bald Eagle 1 - Earthen Levee BBS, The 458-2054 28.8 WWIV Levee 1 FGM Electronic Classroom 2 595-4489 28.8 WINS ? 1 - File Exchange, The 296-2348 33.6 SLGT Michael B.
    [Show full text]