AN OVEFLOWED BUFER COULD MAKE A 9 ON THE Y2K RICTOR SCALE

greenspun.com : LUSENET : TimeBomb 2000 (Y2000) : One Thread

This one caught my eye. How difficult is an overflowed buffer to fix once it happens? Could the 1,000 cuts scenario be possible with overflow of buffers? Has any y2k failures caused buffer overflows yet? This threat could be a very real danger while everything on the surface appears to be running fine, no worries, can buffers actually overflow in EMBEDDED systems or in buggy code if they do have a buffer to overflow with? Is a divide by zero a buffer overflow? What's the stituation of the embedded systems? Can faulty bogus values from software cause buffer overflows in embedded systems or vice versa?

-- Brent Nichols (b-nichol@ihug.co.nz), January 05, 2000

Answers

Get a grip! What you've posted is basically meaningless.

"Buffer overflow" is a common class of software bug and nothing particularly to do with Y2K. If you're interested, read through the list of bugs fixed in Microsoft NT service pack 5, and you'll see quite a few of them. Despite which, NT is one of Microsoft's better products (and was even before the service pack).

-- Nigel (nra@maxwell.ph.kcl.ac.uk), January 05, 2000.


Oh, there's a bunch of coding scenarios that could bust a gusset anytime now. One of my favorite is the year-as-index logic. You have a list of buckets for year-by-year counts, that kind of thing, defined as 99 items long. You accumulate data by using the 2-digit year as an index. In cobol there would be no zero-th occurrence, and kaboom, you end up accumulating data into whatever data field is defined BEFORE your list. The program runs the accumulation part, but (1) you stomp on that other data, and (2) the output logic almost certainly can't pick up that off-the-list data.

This is a possible reason for the names being replaced by garbage in a problem recently reported in the Southwest, somewhere, don't recall exactly.

Another big problem is that 00 will be out of sequence, and you stop scanning a list (if sorted by date) when the yy is greater than current. (That's just a fer-instance.) So huge chunks of data will be lost in processing, though the program appears to be running ok.

Same thing will tear the guts out of a database, if that 2-digit year is part of a sort key.

Oh, we got a long way to go, and these are not your two, three hour fixes. We are scraping the iceberg now.

-- bw (home@puget.sound), January 05, 2000.


Nigel, not so fast. Buffer overflow is not INEVITABLY a y2k problem, and they happen all the time from poor coding. But buffer problems (overflow or off-the-end) CAN be a y2k problem if the programmer used the year to calc an index into the buffer.

-- bw (home@puget.sound), January 05, 2000.

Despite which, NT is one of Microsoft's better products (and was even before the service pack).

-- Nigel (nra@maxwell.ph.kcl.ac.uk), January 05, 2000.

*********************

Perfectly true statement...I just don't know whether to laugh or cry.

-- (Novel lovin')LM (latemarch@usa.net), January 05, 2000.


bw - agreed, Y2K could trigger a buffer overflow. That in turn could cause anything depending on the layout of data in memory ... just the same as any other buffer overrun bug. But without a specific piece of software to discuss, linking buffer overrun and Y2K is no more or less scary than linking Y2K and infinite loops, or Y2K and off-by-one errors, or Y2K and sort ordering problems, or any number of other bugs that don't fall into one of the common classifications at all!

-- Nigel (nra@maxwell.ph.kcl.ac.uk), January 05, 2000.


I could see how trying to stuff 19100 into a four digit year memory space could easily cause an overflow. Might also corrupt other parts of memory depending on where it happens.

-TECH32-

-- TECH32 (TECH32@NOMAIL.COM), January 05, 2000.


Buffer overflows are VERY difficult to isolate once they happen. It really depends upon how much the data/code beyond the buffer is trashed. Really bad overflows are easier to track down because they over-write code and cause crashes, which are easy to track in the debugger. More subtile overflows just trash data. Then the code trys to use the data with totally unpredictable results which have to be tracked down. If your debugger is good (most are these days) you can set watches on data and find these fairly quickly. The MOST dangerous buffer overflows by far are those cause deliberatly by what is known as malicious code. It is an exploit that 'crackers' use to obtain admin authority on a system and consists of a buffer overflow carefully constructed to leave the system running but wide open to attack thru the supervisor account. Many older systems are vulnerable to overflows, newer systems have libraries rewritten to protect against this sort of thing.

A divide by zero is not an overflow. It is an illegal operation. Different systems treat this error in different ways. Some software is written to ignore this error and keep running. It is done by remapping the error handler routines to local handlers in the program. Some systems just bomb off with the error. This is usually fairly easy to track in the debugger as well. There is also an error known as a nan. It is similar in effect to a divide by zero.

If an imbedded system is actually using data generated by a software system and that software system gives the imbedded system data which it can not handle for example a zero where a real number is expected. It might cause a divide by zero and an halt... but I know very little about embedded systems and you would be better advised to take the advice of someone who does.

These are the sorts of issues with which we now must concern ourselves. This is the part of the y2k scenerio that I seem to notice some many of the EE's having the most trouble. Generally their jobs require them to be concerned with the more immediat problems of process control and hardware interfaces. They seem to have as much difficulty understanding the implications of data corruption as I do understanding their world. My apologies in advance to anyone offended. That is not my intent here.

It is simply that I am concerned at this point with the longer term, less immediatly noticable problems which my betters (Yourdon, Way, et. al.) have suggested might occur, and the extent to which they might occur.

-- Michael Erskine (Osiris@urbanna.net), January 05, 2000.


Yes, we heard you the first time. And the second. You've finally provoked some responses. Happy now?

-- Servant (public_service@yahoo.com), January 06, 2000.

Nerds, Noobs, U DONT'T ANYTHING. DONT EVER POST SOMETHING LIKE THIS AGAIN OR ELSE I'LL PUT A VIRUS ON UR COMPUTER, AND THANKS FOR UR EMAIL ADRESS!!!!!!

-- Yor full name (none-of-you-buisnazz@hotmail.com), September 21, 2003.

Moderation questions? read the FAQ