Epic Software Bugs of All Time, Heartbleed Included

Where there is technology, there will be bugs. There are several bugs history has witnessed in the various technologies we have developed so far. We obviously cannot make everything cent percent perfect. There are always external factors which remain involved in making the available technologies less secure and when they succeed, we have what is called a bug. So, software bug is an error, flaw, failure, or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways.

I have collected some of the most famous bugs ever.

Y2K or Millenium bug

Y2K bug, also known as millennium bug is the best known bug and almost every techie out there is aware of it. There always have been rumors that this bug was the result of the carelessness of the computer professionals who did not take into consideration the dates from year 2000 but the actual reason was cost cutting and as per the estimates, the amount of money saved by programmers using 2 rather than 4 digits was actually four times greater than the cost to fix the so-called 'Y2K bug'. Actually, in the older computers, two digits were used to show the year, i.e. 98 for 1998. There was no issue until year 2000 came. Because that way, year 2000 would appear as 00 and same was as for 1900.


So, there was a fear that many computers would be using incorrect date when the clocks struck midnight on January 1, 2000 and that might result in the failure of the working of the computer softwares.

This bug was not that big an issue to be worried about, as the worst result would not be more than an incorect date. Computer scientists were quite aware of the consequences but it was media that overly hyped the issue naming it one of the biggest software bugs in the mankind history. The affected systems were fixed & verified in time although the process came out to be too expensive.

Year 2038 bug

The year 2038 bug is similar to that of Y2K bug as it too involves a time related problem carelessly handled by the programmers. In case of Y2K, the older machines did not have the century digits for the dates, i.e. 1900 would appear 00, 1996 would appear 96. The issue rose when it was time for 2000, it too would appear 00. This is what they called Y2K bug.


This bug was not that big an issue to be worried about, as the worst result would not be more than an incorect date. Computer scientists were quite aware of the consequences but it was media that overly hyped the issue naming it one of the biggest software bugs in the mankind history. The affected systems were fixed & verified in time although the process came out to be too expensive.

Its not that there are no more date related issues on machines today. Its just that some are more prevalent than the others but it is a fact that almost all computers suffer from a critical limitation. Most programs work out their dates from a perpetual second counter - 86400 seconds per day counting from Jan 1 1970.A recent milestone was Sep 9 2001, where this value wrapped from 999'999'999 seconds to 1'000'000'000 seconds.Very few programs anywhere store time as a 9 digit number, and therefore this was not a problem.

Modern computers use a standard 4 byte integer for this second count. This is 31 bits, storing a maximum value of 231. The remaining bit is the sign. This means that when the second count reaches 2147483647, it will wrap to -2147483648.

The precise date of this occurrence is Tue Jan 19 03:14:07 2038. At this time, a machine prone to this bug will show the time Fri Dec 13 20:45:52 1901, hence it is possible that the media will call this The Friday 13th Bug.

Divide by zero bug

In mathematics, dividing any number by 0 literraly doesn't result in anything proper. Mathematically, the output is infinity or undefined. 0 is the most imortant digit in mathematics and there can be no calculations with it. Almost every machine out there require 0 in their calculations.


Divide by zero bug came into light when a smart ship USS Yorktown was left dead in the water in 1997 for nearly 3 hours after a divide by zero error. USS Yorktown (DDG-48/CG-48) was a Ticonderoga-class cruiser in the United States Navy from 1984 to 2004, named for the American Revolutionary War Battle of Yorktown.

On 21 September 1997, while on maneuvers off the coast of Cape Charles, Virginia, a crew member entered a zero into a database field causing an attempted division by zero in the ship's Remote Data Base Manager, resulting in a buffer overflow which brought down all the machines on the network, causing the ship's propulsion system to fail. The software was installed as part of a wider operation to use computers to reduce the man power needed to run some ships. Fortunately, the ship was engaged in maneuvers at the time of the incident, rather than deployed in a combat environment, which could have had more severe consequences.

Heartbleed bug

The latest and hottest of all is the heartbleed bug which is a open source software bug in OpenSSL. This bug has exposed 17% or half a million of the Internet's secure web servers to security threats making them vulnerable for theft of data and other private informations like keys and passwords.

 This weakness or bug allows stealing of information protected by SSl/TLS encryption used to secure the internet. SSL/TLS is responsible for providing communication security and privacy over the internet for various applications like web, email, IM, etc.

This bug basically allows anyone to decrypt the secure encrypted data and makes it easy for the attackers to eavesdrop on communications, steal data directly from the services an the users.
One of the Google employees actually reported the security flaw of OpenSSL which has been existing in the 1.0.1 series since March 14, 2014. The software bug now causing security issues for the companies actually started at midnight on Dec. 31, 2011.

However, the patches now have been released for different operating systems and everyone has been advised to upgrade to the non-vulnerable versions as soon as possible.

Reference: Wikipedia

Related

technology 2101312787695102250

Post a Comment

  1. In the last example, you don't make it clear why it's invokespecial rather than invokevirtual that is being called.


    I suspect that (I haven't read the Java Bytecode specification, which is a tough one) it's because there's no overriding happening here. 'demoMethod' in BaseClass is private so method with the same name in the DerivedClass has no idea that he himself actually has a ancestor.


    But I don't know exactly how JVM manage to know about this fact, and use invokespecial in demoMethod in BaseClass instead of invokevirtual. It would be great if someone can enlighten me...

    ReplyDelete

emo-but-icon

 

Recent Posts

comments

Join Us

 

Recommended

item