		*Últimos Cambios*
	Blog personal: El hilo del laberinto

RE: [NTSEC] Source code for boink.c, a modified bonk.c

Última Actualización: 23 de Enero de 1.998 - Viernes

Date: Sat, 10 Jan 1998 08:03:36 -0500 (EST)
From: Ken Williams <jkwilli2@unity.ncsu.edu>
To: Geoffrey P Waigh <gpw@sagitta.cybersurf.net>
CC: Paul Leach <paulle@microsoft.com>, ntsecurity@iss.net
Subject: RE: [NTSEC] Source code for boink.c, a modified bonk.c
In-Reply-To: <Pine.LNX.3.96.980109175945.2096B-100000@baabaa.blacksheep>
Message-ID: <Pine.SOL.3.96.980110073148.20694A-100000@c00954-100lez.eos.ncsu.edu>

TO UNSUBSCRIBE: email "unsubscribe ntsecurity" to majordomo@iss.net
Contact ntsecurity-owner@iss.net for help with any problems!
---------------------------------------------------------------------------

On Fri, 9 Jan 1998, Geoffrey P Waigh wrote:

>On Fri, 9 Jan 1998, Paul Leach wrote:
>
>> Yeah -- we love staying up all night providing patches that close off each
>> port, one by one, as smart crackers change which port they hit... And you
>> know what they say about the PR -- "there's no such thing as bad publicity".
>
>But you don't seem to mind staying up all night providing patches that
>close off each illegal data bug, one by one. Protocol specifications tell
>you what inputs should yield meaningful results, not what the wiley
>hackers are going to send across the net.
>
>I wonder if the programmers (and managers - don't forget their role in
>ensuring things go out the door on schedule,) get commendations for the PR
>they generate.
>
>Geoffrey

if only systems analysis and design, and life itself were that simple....

let's break this down into a simplified, yet accurate, outline:

Programmers tell the computer what to do, matching computer instructions to design specifications.

Systems analysts are the ones who tell the programmers what to do; they design the systems to match the users' specifications or needs.

Computer systems don't happen overnight. It takes lots of work and planning to match computer capabilities to user needs.

These steps are generalized, but they do display the basic actions performed in creating a new operating system. Different individuals or companies might carry out these actions in their own way, or have their own names for the various actions.

The "waterfall" model of the systems analysis process

Steps in building a System

Preliminary investigation (feasibility study or system survey)

Situation--a business or enterprise perceives that there is a problem or deficiency in their operations.
What to do

Determine the nature of the problem
Establish the scope of the problem inquiry
Objectives

Possible results

Drop the matter
Fix the problem quickly
Go on to a new system

Analysis

Data gathering--note that no technique by itself has all the advantages; the techniques are complementary.

Examine written documents or the present computer system-- find out what the people use now for records and how they use them. This will often be a good starting point for the construction of data files.
Interviews-- formal or informal, to find out what people do.
Written questionnaires--these often will get responses that people will not make in face to face interviews.
Observation--watch the system in action.
Sampling--test the system, small amounts of data may be enough to get the full picture of how the system works.

Data analysis--use the information to understand how the system works and decide what will have to be done.

chart the flow of data through a system
show the criteria used to make decisions

System requirements--The result of the analysis phase should be a system requirements specification. This is a document that lists the conditions that a new system must meet.

Design

Preliminary design examine alternative candidates to determine which method is most feasible to solve the problem. Possible use of prototyping to develop unfinished versions of the system to test it out before a final design is finished.

Detailed design

The "what"

Output requirements--the information needed and its form.
Input requirements--the information entered into the system.
File structures and processing--(see below) the form in which information will be stored and the operations required on the input to get the output.

The "how"

System structure--develop the major operations of the system.
System error-checking--develop the procedures for handling any problems.

Development

Scheduling--Lay out a time frame for creating the system.

Get the parts of the system

Hardware
Software possibilities

prepackaged software
custom or modified software
developed in-house
contracting programming, hiring outside programmers to write all or part of your program for you

Outsourcing or service bureau work

Let an outside firm that specializes in the data processing your firm needs do the computing for you.
Some may create the software "in house" and hire the hardware from another company to run their programs and store their data.
Advantages

A firm does not have to develop all the expertise in-house.
A firm does not have to purchase hardware.
Security--no one within your business has to work with sensitive data.

Disadvantages

May require double entry to move the data to another location for processing.
Security--can the outside firm be trusted?
Continuous fees instead of a one-time purchase.

Release to customers and maintenance

Training--tell people how to use the new system

Equipment conversion--install the new equipment

File conversion. Convert data to the new formats. Often the most important step, due to the time invested in creating the data stored in an existing system.

System conversion: Direct cutover -- everything is converted at once. Phased conversion--parts of the system are phased in. For example, a new accounting system might start first with inventory, then add payroll, etc. in later steps. Pilot conversion--the entire system is used by some users or locations. It is then converted to other sites after being debugged. Parallel conversion--the new system is implemented while the old system carries on in order to compare results. Can be difficult due to the extra time involved.

Maintenance is often the largest part (over 50%) of the total development effort expended on a system. This is because much of the work on a system is not the initial design, but the continual changes that occur once the system has been installed and used.

Audit trails--These are methods that give a record of all transactions on the system. They can be used to find bugs and recreate data

Evaluation--constantly monitor the system to be sure it is doing its job.

Three types of Maintenance

enhance--add new features desired for the system, based on experience with the system.
fix--correct bugs that may be discovered after the system is installed and running.
update--modify the system to reflect changes required externally, e.g. new government or business regulations, new report forms required, new procedures introduced.

Alternate possibilities

In recent years, the "waterfall" model given above has come under attack from computer scientists as being inadequate for many types of system development projects. Some weaknesses: It assumes that you are able to picture the entire system up front before any development occurs. This fails in such systems as those with an extensive user interface, as it may be difficult to predict how the system will work for the users. The method is not flexible. Not only may the user not be able to completely specify requirements up front, but outside forces may change the project during its development stage.

Prototyping

Possible Reasons for prototyping

The designers are unsure how to create the system
To test a 'real' system on the user
To work bugs out gradually
Mistakes are easier to fix if the system is small

Method

Design a system
Implement in part with:

limited error trapping
limited user interface
limited functionality

Test and get feedback on design
Repeat the process at next level of complexity or modularity until the system is complete. The prototype can then serve as the basis for development of the actual product; in some methods the prototype will be refined until it is the actual working system.

Prototyping and incremental approaches have their own weaknesses.

A means must be found to ensure the cycle has a stopping point; otherwise there is a temptation to continue fine- tuning the system without ever producing a working version.

There may be schedule or budget pressures to use a roughly developed prototyped system in place of a completed, well-developed system. Some prototyping tools or methods may produce a system that is suitable for field use. However, others are best used to develop an idea of how the product should be designed, with the idea of using the prototype as a model to develop the actual working version.

A prototype might be used as a means of getting around proper planning before developing a product.

Developing Software

Programming process. This is the process the programmer might follow if a custom software package is being developed as part of new system. You will see that this process also has s set of steps that are followed that are similar to those for the whole system.

Requirements

Defining the problem. Decide what it is that we need a computer to do. From the systems perspective, how will the design be translated into commands that the computer can run. It is important that the problem be well defined at this level. Problems are easiest to fix when found here. In other words, your solution will be wrong if your idea of what the problem is is wrong.

Design

Planning the solution. This is where the real work. takes place. If a proper plan is made at this stage, the coding part will be very straightforward. Top-down design--Emphasizes breaking everything up into small chunks. Compare the process to outlining a term paper. The process uses step-wise refinement-- (Procrastination can be good, don't try to solve all the details at once). Decide first on a broad breakdown of the processes to be done into individual steps or sections. Concentrate on the parts of the breakdown individually and break these parts down in turn into smaller steps. Continue this process until you have broken the problem down into "chunks" that can be performed (or programmed) as one unit.

Implementation

Coding the program. Convert your plans into the syntax of a computer language or the commands or entries required by your applications. Often the easiest part, if your planning has been good.

Documenting the program. Manuals--for the users and future programmers. The manuals will tell how the program works. It is often extremely difficult to go back to an old program and figure out what it does just by reading the computer code alone, even if you were the programmer. The code tells "what" the computer does, but not "why". Good documentation can supply the "Why".

Documentation has become an important factor as end-users have begun programming practical applications. Most end- users have not been trained in the importance of proper documentation. A spreadsheet may be just as difficult to understand without proper documentation as a machine language program. A good trick for documenting spreadsheets is the "Note" function in Excel or a similar function in other spreadsheets. This will attach a written free-form message to a cell that could be used to explain the entry.

Testing

Testing and debugging the program. Assuring it works as desired. Proper debugging is crucial for any application with practical uses. Many problems are subtle. Bugs may not show themselves until a particular combination of actions are made or specific data is entered. This may be long after the program has been put into use. A system long thought reliable might suddenly fail or crash. Bugs involving calculations might produce incorrect results that are not noticed until an audit is made showing the incorrect figures. For example, a tax calculation program might give incorrect results for only certain types of income or the difference might be small enough that it is not noticed. Testing and debugging may be particular problems for end-users. It can apply to spreadsheets and other end-user applications just as much as to traditional programming languages. Debugging requires a methodical approach to determining that the program will work with all possible input, not just a few example cases. Many users (and some professionals!) will feel the program is correct after the syntax and runtime errors are gone, even though logic or design logic errors may pop up.

Testing from the system perspective. There is a saying that "You can make software foolproof, but you can't make it damn-fool proof." Often end-users will discover bugs in software by doing actions unanticipated by the developers and testers. Products that are for commercial sale often go through a round of testing at a limited number of actual end-user sites before the product is released for sale to the general public. ("alpha" testing would be testing by end-users under the direction of the system developer, "beta" testing is testing at actual end-user sites without direct control by the developer.)

Maintenance

Fix bugs found by users, and add new features requested by users.

To sum it all up:

(Time Frame [set release date]) + (Corporate Investment [money, time and manpower]) + (Development Requirements/Limitations [customer and corporate requirements, technologoical limitations, prima donna coders, pressured and/or clueless mid and upper level management, etc...]) = A VIRTUALLY IMPOSSIBLE TASK!

i won't complain until i can do a better job by myself.

NOTE: many thanks go to Dana Lasher for breaking this all down and providing me with a vast majority of the above information.

Ken Williams

/--------------|  TATTOOMAN -aka- rute  |--------------\  
  NCSU Computer Science    Member of E.H.A.P.   
  jkwilli2@unity.ncsu.edu  http://www.hackers.com/ehap/ 
  UNIX ICQ UIN# 4231260    ehap@hackers.com     
  FTP Site:  ftp://152.7.11.38/pub/personal/tattooman/
  WWW 2:     http://www4.ncsu.edu/~jkwilli2/
  PGP Key:   http://www4.ncsu.edu/~jkwilli2/pgp.asc
      http://www4.ncsu.edu/~jkwilli2/pgp_fingerprint
\---------|  http://152.7.11.38/~tattooman/  |---------/

Date: Sat, 10 Jan 1998 13:07:45 -0600 (CST)
From: Aleph One <aleph1@dfw.net>
To: Ken Williams <jkwilli2@unity.ncsu.edu>
CC: Geoffrey P Waigh <gpw@sagitta.cybersurf.net>, Paul Leach <paulle@microsoft.com>,
ntsecurity@iss.net
Subject: RE: [NTSEC] Source code for boink.c, a modified bonk.c
In-Reply-To: <Pine.SOL.3.96.980110073148.20694A-100000@c00954-100lez.eos.ncsu.edu>
Message-ID: <Pine.SUN.3.94.980110125849.4870B-100000@dfw.dfw.net>

On Sat, 10 Jan 1998, Ken Williams wrote:

> To sum it all up:
>
> (Time Frame [set release date]) + (Corporate Investment [money, time and
> manpower]) + (Development Requirements/Limitations [customer and
> corporate requirements, technologoical limitations, prima donna coders,
> pressured and/or clueless mid and upper level management, etc...])
> = A VIRTUALLY IMPOSSIBLE TASK!
>
>
> i won't complain until i can do a better job by myself.
>
> NOTE: many thanks go to Dana Lasher for breaking this all down and
> providing me with a vast majority of the above information.

Ha! If it only where so simple. No _one_ uses a model resembling that any more. I suggest you read "How Microsoft Builds Software" by Michael A Cusumano and Richard W. Selby, Communications of the ACM, June 1997 Volume 40, Number 6. The truth is that software is never "done". It's an endless stream of Betas. All stages (coding, testing, planning, are done concurrently such as that you always have a product ready to ship if the market conditions or your deadlines require it (with bugs or without).

> Ken Williams
> 
> /--------------|  TATTOOMAN -aka- rute  |--------------\  
>   NCSU Computer Science    Member of E.H.A.P.   
>   jkwilli2@unity.ncsu.edu  http://www.hackers.com/ehap/ 
>   UNIX ICQ UIN# 4231260    ehap@hackers.com     
>   FTP Site:  ftp://152.7.11.38/pub/personal/tattooman/
>   WWW 2:     http://www4.ncsu.edu/~jkwilli2/
>   PGP Key:   http://www4.ncsu.edu/~jkwilli2/pgp.asc
>       http://www4.ncsu.edu/~jkwilli2/pgp_fingerprint
> \---------|  http://152.7.11.38/~tattooman/  |---------/

Aleph One / aleph1@dfw.net
http://underground.org/
KeyID 1024/948FD6B5 
Fingerprint EE C9 E8 AA CB AF 09 61  8C 39 EA 47 A8 6A B8 01

Message-ID: <418996AD2954D11180860000E8D5C6670186E5@ns.rc.on.ca>
From: Russ <Russ.Cooper@rc.on.ca>
To: "'Aleph One'" <aleph1@dfw.net>, Ken Williams <jkwilli2@unity.ncsu.edu>
CC: Geoffrey P Waigh <gpw@sagitta.cybersurf.net>, Paul Leach <paulle@microsoft.com>,
ntsecurity@iss.net
Subject:: [NTSEC] Source code for boink.c, a modified bonk.c
Date: Sun, 11 Jan 1998 01:44:32 -0500

I'll try to make it as simple as it can be.

All programmers have code, of some sort, that's lying around waiting for a product. Its in varying stages of completeness, somewhat debugged, and usually mentally indexed into a product category.
All marketing folks are actively seeking someone to buy whatever it is their selling, but usually the customer wants something ever so slightly different than the off-the-shelf product.
Typically, marketing funds developers efforts to build the product they (marketing) want, so developers rarely have the resources to fully develop everything they create.
Nothing is ever bug-free.

The combination often leads to the reality that bug fixes are not funded per se, or at the least the resources are typically different than the original development teams. There are always many of them, more than can be handled with the highest time sensitivity that people want, so they have to be prioritized. Understanding why a bug does what it does is one thing, understanding what code modules are affected with the endless combinations available is quite a different story.

To assume that exploit coders are trivially coming up with these exploits in hours is definitely not to accept reality. Many of them are working endlessly to come up with just one, while the majority of others are stumbled upon as a result of debugging other programs.

No vendor can possibly do the debugging required to capture all of these possibilities, particularly in today's complex OS'. I have no doubt that many of us have, in the past, had these amazing ideas of creating a packet generator that endlessly throws combinations of legal and illegal packets at a box, just to discover these sorts of exploits. Unfortunately the realization of such a tool is not as simple as it sounds, so more structured and formalized methods have to be used. They are slower, less effective, but accommodate the majority of likely problems.

I liken putting your (box, data, code, corporate life) out on the net to driving your car on any road. Bird's may shit on you, a passing truck may throw a stone against your beautiful paint job, the weather may be good or bad, etc... Like security, nothing is 100%.

Remember, providing a Hot Fix means getting something out the door ASAP, and as a result Microsoft already forego formal regression testing, not to mention the virtually complete lack of understanding of HFs by 3rd party vendors. It therefore makes very good sense to modify as little as possible to prevent an exploit when creating HFs. Too much may lead to the SP2-syndrome, where too many fixes cause too many other bugs/incompatibilities.

Most of the patches I've seen for the spate of DoS attacks over the last year have had to be re-done to accommodate the variants, regardless of OS.

Cheers,
Russ Cooper
Owner/Moderator of the NTBugTraq mailing list

Message-ID: <418996AD2954D11180860000E8D5C6670186E9@ns.rc.on.ca>
From: Russ <Russ.Cooper@rc.on.ca>
To: "'Jiva DeVoe'" <jiva@devware.com>
CC: "'Aleph One'" <aleph1@dfw.net>, Ken Williams <jkwilli2@unity.ncsu.edu>,
Geoffrey P Waigh <gpw@sagitta.cybersurf.net>, Paul Leach <paulle@microsoft.com>,
ntsecurity@iss.net
Subject: RE: [NTSEC] Source code for boink.c, a modified bonk.c
Date: Sun, 11 Jan 1998 15:07:13 -0500

>However, with all due respect, I'll simply point out that perhaps the
>untold millions MS just spent on hotmail.com or Microsoft car, or Bill
>Gate's new house might have been better spent hiring a few more
>developers/testers.

Jiva,

I don't mean to be insulting, but this is very naive. The facts are that very few customers of any OS are particularly concerned about security to the extent they'll actually not buy said OS because of security issues. The number of exploits across all OS' is testimony to that fact.

The number that will drop an OS due to inefficient support of an exploit/bug is greater, but again, they are still not enough to make a dent in sales unless said inefficient support extends over a long period of time (i.e. years).

Don't get me wrong, I'm all for better HFs that are proactive as well as reactive, but my point is to try and say that thinking HFs should be the be all and end all to an exploit (or its variants) is unrealistic. For a piece of code to achieve that it would *have* to be regression tested, and IMO, tested by the 3rd party community as well. That takes time, time that most people would not want to wait.

As for where MS spends its money, talk to their shareholders and see what they think about the Hotmail deal versus more people writing HFs. The HF mechanism is adequate to satisfying the major concern, namely loss of sales or existing customers. I know for a fact, based on a tour of their facilities and a talk to the people involved, that MS is bringing more resources to bear on the problem of exploits. Surely, however, you must realize the lack of available skilled NT developer resources versus the amount of current development being done, both inside MS and out. Finding a damn good NT programmer is a difficult task regardless of what tasks you want to assign them, then tell a good programmer that their going to be doing HFs instead of helping make the next biggest selling software product and you'll find they aren't incredibly enthusiastic about the idea.

As for Billg's personal investments, try and understand how stocks work so you can understand why shareholders would not be thrilled with an additional investment by him into MS.

>I mean, if Microsoft is so strapped for cash (ha
>ha) that they can't afford a few extra people to produce quick and
>effective patches, then perhaps Mr. Gates should take a pay cut or
>something so they can.

Its not the cash, its the availability of resources.

>The excuse of "making hotfixes is expensive" is
>acceptable for software which is free, shareware, or for software
>companys that Microsoft is presently running out of business due to it's
>anti-competitive marketing strategies, but it is NOT acceptable for a
>company like Microsoft.

I didn't say "making hotfixes is expensive", so don't put quotes around something unless I actually said it. What I implied was that HFs don't generate revenue to marketing, so their funding is different than other development efforts.

>Personally, I think no matter how you cut it, if I was Microsoft, I
>would feel like I have egg on my face, and for those of us who work with
>Microsoft products, and base our careers on it, that's really uncool.

I'm sorry, but using this thinking *almost every OS vendor* has egg on their face. However, I think this gives too much credit to the exploit coders. I think its a lot easier to find a flaw in something than it is to make that something work with the diversity of applications we use today, again, regardless of OS.

>Respectfully,

Equally...;-]

Cheers,
Russ

Más información sobre los OpenBadges

Donación BitCoin: 19niBN42ac2pqDQFx6GJZxry2JQSFvwAfS