After all the debate about disclosing security vulnerabilities within software, Google is trying to reshape the process for fixing bugs. There has always been discussion on whether or not responsible disclosure was actually responsible or not, but it came to a head (at least from a media standpoint) last month with the Microsoft/Tavis Ormandy occurance.

Google Pushing To Redefine 'Responsible Disclosure'

This post from the Google Online Security Blog discusses what Google would like to see changed in the current "responsible disclosure" model. Currently, when a security researcher finds a vulnerability in a piece of software, that researcher is supposed to inform the software vendor privately of the risk. The bug is not supposed to be released to the public until a fix is released.

According to Google's blog post, "The emotionally loaded name suggests that it is the most responsible way to conduct vulnerability research - but if we define being responsible as doing whatever it best takes to make end users safer, we will find a disconnect. We've seen an increase in vendors invoking the principles of "responsible" disclosure to delay fixing vulnerabilities indefinitely, sometimes for years; in that time frame, these flaws are often rediscovered and used by rogue parties using the same tools and methodologies used by ethical researchers. The important implication of referring to this process as "responsible" is that researchers who do not comply are seen as behaving improperly. However, the inverse situation is often true: it can be irresponsible to permit a flaw to remain live for such an extended period of time."

This does not seem like the best system to have in place for protection of the end user. Basically, this is saying that because security researchers are not allowed to release details of a bug to the public until there is a fix, there is no reason for the vendor to take action. It also takes notice of the fact that by using the term 'responsible' disclosure, it is barring anyone from breaking with the mold by labeling them as irresponsible.

Despite what it may seem like, Google is not trying to plunge us into a state of anarchy by proposing a full-disclosure method of dealing with bugs. They want to find a balance, where end users receive security updates in a timely manner, and software vendors have enough time to provide those fixes to the users. Their suggestion? A 60 day window between being informed of the vulnerability and having a fix available to to the public. In this situation, everybody wins.

This week, Mozilla released a security update for their popular Firefox web browser. Firefox 3.6.7 fixes several security issues that were found in the 3.6.6 version. Over half of the vulnerabilities fixed were listed as "Critical," which is the highest danger level that Mozilla associates with security issues.

Mozilla Rolls Out Security Update For Firefox

Of the 14 vulnerabilities listed on the Firefox update site, eight are listed as critical. Mozilla defines a critical issue as a "vulnerability [that] can be used to run attacker code and install software, requiring no user interaction beyond normal browsing." Basically, a hacker can run their code on your computer to access your information and install malware on your system. For instance, they list an issue with PNG issues. If you browse a site with a maliciously crafted image on it without clicking on anything, you can get a computer virus.

The way that most of these vulnerabilities are able to execute code on your machine are to take advantage of pointers to unallocated memory. These pointers are caused by array overflows or de-allocating objects with multiple pointers pointing to it. By using these dangling pointers, they are able to put their code into sections of memory that your computer doesn't realize are being used, and therefore doesn't know to protect. Once the malicious code is in memory, it is easy to execute.

The best way to protect yourself is to make sure that your browser is always up to date with the most current software. In Firefox, this is as easy as clicking the "Check for updates..." link in the Help menu, or by going to mozilla.com and clicking the big green button in the middle of the screen. This will update your browser to ensure that you have the best protection for your web browsing pleasure.

This week, Microsoft released a new security patch for issues affecting the XP and Server 2003 operating systems. The vulnerabilities were all related to remote code execution, though only the XP patches were listed as critical by the Microsoft Security Bulletin.

Windows XP Security Patch

On June 5, Tavis Ormandy, a Google security researcher discovered a zero-day vulnerability in Windows Help that he reported to Microsoft. When Microsoft and Ormandy could not agree on the terms of creating a fix, he published the vulnerability four days later, creating a huge media storm. There were people on both sides, some arguing that Ormandy acted irresponsibly by spoon feeding a security exploit to hackers who would use it to cause harm. Others argued that without full disclosure, Microsoft would not have taken this threat seriously and wouldn't act towards fixing the issue.

Whether or not Ormandy was right in his actions, the outcome speaks in his favor. This past Tuesday, Microsoft released Microsoft Security Bulletin MS10-042, which addresses these vulnerabilities. This is an amazingly quick turnaround. The normal time frame for "responsible disclosure" is to allow the software manufacturer a 60 day window to fix the problem before public release. To have a fix only five weeks after the bug was brought to Microsoft's attention makes a strong argument for the proponents of full disclosure.

On the other hand, since the release of this particular bug, Microsoft has reported over 10,000 computers have been affected by hackers using this security hole. This is a significant amount of people being affected by a previously unpublished issue. The fact that it was unpublished does not necessarily mean that it was unknown to the people who could exploit it. It is unlikely that Ormandy was the only person that would ever discover this problem. Thanks to his actions, we now have a solution to what could have become a serious problem for more than just the 10,000 people who were unfortunately targeted.

Apple is in the news this week about the new security measures it will be implementing in the wildly popular iTunes store. Granted, this is not a major security upgrade, but it does help to prevent the kind of security holes that have been recently exposed.

iTunes Store To Receive Security Makeover

This all began when a Vietnamese app developer named Thuat Nguyen's apps covered 42 of the top 50 apps in the app store. This raised a few red flags, especially after people commented on the apps that they never purchased them. After some investigating, Apple determined that Nguyen had obtained account information from 400 accounts with stored credit card information and had used them to purchase his apps from the App Store. He then used these accounts to purchase his apps, driving up sales and his revenue.

In order to combat this type of security breach, iTunes will now require an extra step be taken by its customers. On accounts with saved credit card information, customers will need to enter their CCV code from the back of their card more frequently. That's it. Admittedly, this is not a full security overhaul, but the truth is that that would be unnecessary. The "hacked" accounts are more than likely victims of fishing attacks, as Apple has stated that their servers were unaffected by any kind of security breach.

Overall, the damage caused by this problem was minimal (assuming you are not one of the 400 accounts that were targeted). 400 accounts out of 150 million comes to roughly 0.0003% of accounts worldwide. This coupled with the fact that Nguyen and his apps have been banned from the App Store makes this a fairly open and shut case. For anyone who was affected by this fraud, Apple recommends that you contact your credit issuing agency about canceling your card and issuing a charge back for unauthorized transactions.

These days, with threats of computer hackers stealing data to insurance companies "accidentally" publishing hundreds of thousands of peoples most sensitive information on the internet, data security is a very prevalent issue. A CBS news investigation recently turned up a new source of potential data leakage, the standard office copy machine.

The "New" Paper Trail

Unknown by the majority of Americans, almost every single copier built since 2002 has an internal hard drive which stores a digital copy of each document copied, scanned, or printed using the machine. This can be a useful feature for storing fax cover sheets and other commonly used documents. The problem comes when personal information is copied for office use. For example, doctors making copies of medical records, insurance companies making copies of claims information, or employers making copies of drivers licenses. Each time a copy is made, that information is stored in a way that is easily retrievable by anyone with access to the machine.

There are numerous rental services which rent out copiers to businesses with no set policies on dealing with this kind of security. Some offer to scrub the hard drive when it is returned, but they can charge up to $500 for the service. There are also refurbished copiers for sale containing data from any previous owners. At least in these cases, the owner has physical access to the machine to be able to take steps on their own, such as purchasing an encryption service for the internal hard drive, or their own data deletion tools. What is more worrisome are the copy and print shops where there are no guarantees on document security. Anything copied there is stored on their machines, where it is unlikely that any measures are taken to wipe the drives on a regular basis, if ever.

If your office handles private information, or anything else that doesn't need to be shared with others, steps should be taken to make sure that the information stored inside your copier is safe. There are usually services available from the manufacturers to have the data removed from the device after each job is completed, or at least encrypted, although this can significantly add to the cost of the machine.

Apple has released the newest version of the iPhone/iPod/iPad software, collectively known as iOS. Formerly known as iPhone OS, the new name is not the only change to be had with this update.

Security Holes Fixed By IOS 4

On Apple's website, there is a list of 64 security risks which have been fixed in this new version. The area of the operating system which was apparently the most vulnerable to security breaches is WebKit. WebKit is the browser engine which powers mobile safari on iDevices, and was the cause for 50 of the security patches. That's three quarters of the errors fixed. Of the security holes in WebKit, over half of them would allow "arbitrary code execution" which is a nice way of saying run a program on your device which could either harm your device or access your personal information, just by pointing your mobile browser at the wrong website.

There were 14 non-WebKit related security updates. Safari itself receives the blame for a few of these. There were problems with cookies being accepted when they should have been disabled. There were also issues with URLs during redirects between http and https sites. Furthermore, there were vulnerabilities when viewing "maliciously crafted" BMP, TIFF, and JPEG images. These images could cause data from Safari's memory to be sent to the web server or for more "arbitrary code execution" on the device.

Another severe security vulnerability relates to the passcode lock on iDevices. The first issue is with the Remote Lock via MobileMe. In this instance, the device must be unlocked due to receiving a text message or voicemail, then locked with Remote Lock. The next time the device is unlocked, the passcode will be displayed, thereby granting access to anyone who is in physical possession of said device. The other vulnerability comes in the form of pairing devices with a new computer. As it stands, this can only be done while unlocked. There is a chance for a race condition when the device is initially booted, if it was unlocked when shut down. This can allow the device to be paired with a new computer without unlocking the device first.

All of these issues have been fixed with the release of iOS 4. Now the only question is whether or not there will be more opportunities for these security holes to be exploited before the iPad version is released this fall, especially now that they have been published.

Recently a formerly classified document was declassified describing how the NSA used computers to crack codes.

In Part II, we covered the ATLAS II, the second type of computer used by the NSA for code cracking. The next computer built, ABNER, was very different from its predecessors.

After the Pendergrass Report was published in December of 1946, the Army Security Agency made plans to acquire a computer similar to the Navy's proposed ATLAS. In 1948, ASA analysts visited the three major computer installations currently in existence. The analysts performed experiments using different programming order codes. They concluded that four-address logic (RAYDAC and EDVAC) was preferred over one-address logic (ATLAS and UNIVAC). The ability to use binary notation was found to be a necessary requirement (this disqualified UNIVAC).

The Reeves Instrument Corporation provided the design of ABNER. Mercury delay lines with access time between 48 and 348 microseconds were used to compose a 1024 word memory bank. Basic logic was based on the EDVAC design of 16 four-address instructions and 45-bit words.

ABNER's memory was based on the idea that electric pulses would be converted to an analog acoustic signal that could travel through tubes of mercury that used amplifiers at the opposite end to reconstruct the analog wave into an electrical signal. This digital to analog conversion and subsequent analog to digital conversion allowed the storage of data as the signals moving through the mercury could only move at the speed of sound, much slower than electrical signals. A tank of mercury was a glass tube around two feet long. Two cabinets containing 64 mercury delay lines each made up the memory bank. Each tube was held eight words of 48 bits at one-megacycle-per-second with the aforementioned delay time of 384 microseconds.

ASA engineers worked closely with programmers to build ABNER. This allowed the ASA to incorporate new feature improvements as ABNER was constructed. This was preferred rather than waiting for the next successor computer. Paired stream comparison, data stream manipulation, and character transformations as modular additions were a few of the logic features added. Besides the new logic features, ABNER, had several input-output features including: a console with status lights, an input-output typewriter, a data conversion unit, punched card and punched paper-tape readers and punches, and it could utilized up to six magnetic tape drives.

The construction of ABNER took about two years. The first ABNER was delivered in 1951, followed by a second ABNER in 1955 using quartz instead of mercury for its memory banks. NSA engineers also constructed an clone of of ABNER's logical design, but with parallel circuits called BAKER. BAKER was a slow-speed analog of ABNER, based on the design of ATLAS I. Unfortunately, BAKER was never reliable enough to really use in training or debugging, but BAKER was a great achievement. It is thought however, that BAKER's use of parallel circuits to simulate a powerful serial computer should not have been attempted.

Next time, we'll cover more NSA computers of the past, the successors to ABNER and BAKER.

For more in depth reading see: http://www.governmentattic.org/3docs/NSA-HGPEDC_1964.pdf.