Google Pushing to Redefine 'Responsible Disclosure' 07/31/2010

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.

Mozilla Rolls Out Security Update for Firefox 07/31/2010

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.

Windows XP Security Patch 07/31/2010

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.

iTunes Store to Receive Security Makeover 07/31/2010

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.

The "New" Paper Trail 07/31/2010

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.

Security Holes Fixed by iOS 4 07/31/2010

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.

The History Of NSA Computers, Up Until 1964. Part III. 07/31/2010

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.

114,000 iPad 3G Owners' Email Addresses Exposed by ATandT 07/31/2010

A group called Goatse Security was able to grab 114,067 personal email addresses of iPad buyers from ATandT's website. 114,000 IPad 3G Owners' Email Addresses Exposed By AT&T Some of the Email addreses leaked include White House Chief of Staff Rahm Emanuel, New York City Mayer Michael Bloomberg, Diane Sawyer of ABC News, and many CEOs, CFO, and CTO's. A number of the email addresses exposed were even those of DARPA reesarchers and high-ranking military officials. Each iPad comes with an ICC-ID or an "integrated circuit card identifier." The subscriber's SIM card and ICC-ID are linked to uniquely identify them. Normally this data would not be publicly accessible. AT&T goofed big time and left a script on their website that allowed anyone to query it. If an ICC-ID was provided to the script, it responded with a the subscriber's email address. This script was intended to be used with AJAX apps, but obviously had no protections built in. This lack of security allowed researchers to write a simple PHP script that used the iPad browser agent string to grab potentially millions of addresses. This would not have been possible with out all the pictures of iPad's online that helped them to guess the ICC-IDs. Like any exploit group that wants fame, these guys shared the script and corresponding info with many others like them before reporting the gaping security hole to AT&T. So now Steve Jobs has a bit of a problem. Hundreds of thousands of customer's and potentially millions of email address have been made available to groups that could use them for malicious purposes. Not only that, but the iPad 3G looks rather unappealing now even if it was not Apple that was responsible for the breach. If you bought an iPad 3G and have an email address that doesn't reveal your identity and a strong password for it, you might be safe. However, now is as good a time as any to change your email password to something stronger. Also, if your email is firstname.lastname@mysite.com or something similar, just be very cautious about who you open PDF's from and the links you click in emails. Its easier than you might think for criminals to target a victim with a specially crafted convincing email that appears to be from co-workers or friends. References: http://security.goatse.fr/

The History Of NSA Computers, Up Until 1964. Part II. 07/31/2010

Recently a formerly classified document was declassified describing how the NSA used computers to crack codes. The History Of NSA Computers, Up Until 1964. Part II In Part I, we talked about ATLAS I. The NSA's first real computer. The successor to ATLAS I was named, appropriately enough, ATLAS II. Even before ATLAS I arrived, ATLAS II's construction was being planned. ATLAS II had several important improvements over ATLAS I. Instead of drum storage, it had high speed electronic static storage in the amount of 1,024 words. The word size was 36 bits instead of ATLAS I's 24, two address logic instead of one, more sophisticated instruction code, and the basis of all computing today, input-output program controlled instructions. Having two-address logic instead of one was very powerful for computers of this age. The new instruction codes included another first, a 'repeat' instruction, some arithmetic instructions, a scaling factor ability, and index jumping capability. There were actually two ATLAS II's. One arrived in October of 1953 and another in December of 1954. The second ATLAS II's only modification to the original design was the replacement of the electro-static tube memory with high-speed ferrite-core memory. In the planning of ATLAS II, the design had originally planned to use Raytheon magnetic-tape with one character per frame. But to conform to the established data representation that required three frames per character, the change was made to use three. Later, the NSA seems to have regretted this decision as they tried to redesign the magnetic-tape operations, but never succeeded in making the system more efficient. The ATLAS II computers were very reliable systems for the most part, but the first ATLAS II required a bit more maintenance because of its electrostatic tube storage. The first UNIVAC commercial line of computers the 1101 and the 1103 were based on ATLAS I and ATLAS II respectively. The SOLO, the first transistorized computer, was based on ATLAS II. The two ATLAS II computers were taken out of operation in 1960 and 1962. Next time, we'll cover the NSA's computers called ABNER and BAKER. For more in depth reading see: http://www.governmentattic.org/3docs/NSA-HGPEDC_1964.pdf.

The SSL security model is falling apart at the seams 07/31/2010

Can anyone with the right resources hijack your connection? If so then what good is SSL? The SSL Security Model Is Falling Apart At The Seams It was only less than a year ago when Dan Kaminsky and Moxie Marlinspike wired.com showed just how easy it is to trick a Certificate Authority (CA) and a web browser into faking an SSL certificate by simply dropping a null character into the name to be registered. Simply placing a null character after the name of the site to fake as a sub-domain of the site before the real domain name would accomplish this. An example would be amazon.com\0.evildude.com. Even worse is the fact that ANYONE could just register what is called a wildcard domain, ex. *\0.evildude.com, and masquerade as any site on the Internet they pleased. After that CA's cleaned up their act by stopping the issuance of such certificates but previously issued certs would continue to work until new versions of web browsers were released that would check for such flaws. Today we should all be safe from such attacks using modern web browsers, Firefox 3.5+ is not vulnerable to this type of attack, but the researchers example should make it quite clear that such a gaping hole in SSL security could happen again. As if I could not rain down on the SSL parade any more, recently, a paper was released by Christopher Soghoian paranoia.dubfire.net detailing how governments, law enforcement, and potentially malicious entities can easily hijack SSL connections through coercion or even policy. As many governments have been given their own CA's so that they may control their own encryption needs they can just issue themselves a certificate for a real site and pretend to be that site. Then if a device existed to load that certificate onto that could be located between the victim to be spied on and the real site, then there's nothing stopping them from eavesdropping. Such a device does exist. In fact, the only currently known commercial entity that produces them, called Packet Forensics, attempted to deny their existence for some time. For this to be true, it must mean two things. One, that through some means, coercion, theft, or otherwise, CA's are allowing such certificates to be collected and used on these devices. And two, that there must be a market for these type of devices. There may be other companies producing these devices as well that are just unknown to the general public. So, there you have it, if you were paranoid about government spying before, then this should help push you over the edge. I'm not just talking about governments though, corporations, employers, family, ANYONE who can get their hands on such a device, or build one for that matter, and can buy, coerce, or steal the certificates needed to spy on their targets can do just that! On the other hand, I can hear the sound of new private eye shops opening up, based on this technology. Go-Go-Gadget SSL Circumvention! "I still lock my doors even though I know how to pick the lock" - Matt Blaze, http://crypto.com/ -quoted from http://www.wired.com/threatlevel/2010/03/packet-forensics/

Current Blog

2010 Securty Blog Archive
June Archive
May Archive
April Archive
March Archive
February Archive
January Archive

2009 Securty Blog Archive
December Archive
November Archive
October Archive
September Archive
August Archive
July Archive
June Archive
May Archive
April Archive
March Archive
February Archive
January Archive

2008 Security Blog Archive
December Archive
November Archive
October Archive
September Archive
July-August Archive
May-June Archive
April Archive
March Archive
February Archive
January Archive

2007 Security Blog Archive
December Archive
November Archive
October Archive
September Archive
August Archive
July Archive
June Archive
May Archive
April Archive
March Archive
February Archive
January Archive

2006 Security Blog Archive
December Archive
November Archive
October Archive
September Archive
August Archive
July Archive
June Archive
May Archive
April Archive
March Archive
February Archive
January Archive