Posted by jericho
Mon, 26 Feb 2007 06:49:04 GMT
Steven Christey of CVE recently commented on the fact that Microsoft, Adobe, Cisco, Sun and HP all released multi-issue advisories on the same day (Feb 13). My first reaction was to come up with an amusing graphic depicting this perfect storm. Due to not having any graphic editing skills and too much cynicism, I now wonder if these are the same vendors that continually bitch about irresponsible disclosure and it “hurting their customers”?
These same customers are now being subjected to patches for at least five major vendors on the same day. In some IT shops, this is devastating and difficult to manage and recover from. If a single patch has problems it forces the entire upgrade schedule to come to a halt until the problem can be resolved. If these vendors cared for their customers like they pretend to when someone releases a critical issue w/o vendor coordination, then they would consider staggering the patches to help alleviate the burden it causes on their beloved customers.
Posted in Vulnerability Disclosure, Vulnerability Impact | 1 comment
Posted by jericho
Fri, 15 Dec 2006 13:06:15 GMT
Courtesy of Juha-Matti Laurio at the Securiteam Blogs:
http://blogs.securiteam.com/?p=764
Since 5th December we have seen three separate, serious vulnerabilities in Microsoft Word:
[Disclosed - original reference - CVE name
Affected products and product versions]
Tue 5th Dec - MS Security Advisory #929433 - CVE-2006-5994 and FAQ
Word 2003/2002/2000, Word 2004/v. X for Mac, Works 2006/2005/2004, Word Viewer 2003
Sat 9th Dec - MSRC Blog entry 10th Dec - CVE-2006-6456
Word 2003/2002/2000, Word Viewer 2003
Tue 12th Dec - Fuzzing list posting - CVE-2006-6561
Word 2003/2002/2000, Word 2004/v. X for Mac, Word Viewer 2003, OpenOffice.org 2/1.1.3, AbiWord 2.2
Of course, vulnerabilities in Word (and other MS Office components) are not new, but this recent wave demonstrate (yet again) just how bad the software industry can be and how security was never a consideration during the original design. Hopefully the recent buzz will finally make Microsoft spend serious time auditing the other big business applications like Visio and Project among others.
When reading various security resources, it constantly amuses me that they all seem to ignore the obvious conclusion and short sighted ‘solutions’ they recommend. “Don’t open [filetype] from untrusted people.” We’ve seen this in the past with ‘executables’ to help stop trojan attacks, ‘gif/jpg/bmp’ to stop various overflows and code execution situations in image processing software, ‘excel’ files after a small wave of vulnerabilities were found in MS Excel, and now ‘word’ documents. The people giving this advice are security professionals in many cases, and they all seem to forget that a fundamental component of security is trust. In short, quit specifying a given file format that is the craze of the day. “Don’t open ANY file from untrusted people.”
Posted in Vulnerability Impact | no comments
Posted by jericho
Sat, 30 Sep 2006 17:25:15 GMT
Microsoft is finding themselves under increasing pressure to release fixes for critical vulnerabilities. This week, Microsoft broke from tradition again and opted to release and early fix for a critical Internet Explorer vulnerability. Since we’ve seen other critical vulnerabilities come up before this one, some of which were being exploited in the wild, why the change of policy? One factor that might be influencing this decision is the sudden availability of third-party patches. Back in March, eEye released an unofficial patch for the MSIE createTextRange() flaw which drew criticism and contempt from Microsoft. Windows/IE users were under no pressure to use the patch, but it gave some an alternative to disabling Active Scripting entirely.
This time around, we’re seeing multiple third parties come up with alternative patches that may help some companies while they wait for Microsoft to officially fix a vulnerability. This week the Internet Explorer setSlice vulnerability is being exploited in the wild with more than two weeks before Microsoft possibly releases a patch for it. With this reoccuring trend of critical vulnerabilities going unpatched for “too long”, a group of security professionals has created a new response team called ZERT to help consumers. Determina has also released a patch for the setSlice vulnerability, giving consumers even more choices in helping to mitigate the threat while waiting for Microsoft to patch.
With more and more third party patches available, will it pressure Microsoft to step up and break the monthly patch cycle more often? Will they realize that making patches available for critical vulnerabilities being exploited in the wild, even if not fully tested, is a better option than consumers finding themselves under the control of computer criminals and botnets? After all, we know that Microsoft is perfectly capable of producing fast patches when they think it is a serious issue.
Posted in Vulnerability Impact | 1 comment
Posted by jericho
Sat, 04 Mar 2006 09:29:15 GMT
While digging around the usual sources of vulnerability information tonight, I ran into this sequence of links trying to find where an underlying vulnerability really was:
- sux0r 1.6 was released to fix a vuln
- this was due to a vuln in MagpieRSS, which v 0.72 fixed
- the MagpieRSS issue was due to a vuln in Snoopy
At this point, the sux0r release was linked two steps back to Snoopy, via MagpieRSS. This leads me to stress the value of vendors including such details in their release notes and changelogs. It can save people a lot of time when trying to figure this stuff out. Also attached to the same original vulnerability:
- Ampache was also found to be using Snoopy
- Jinzora was also found to be using Snoopy
Obviously, most people in the security industry who read Bugtraq or Full-Disclosure for their only source of vulnerability information didn’t see all of this. Unless they are as deranged an anal retentive as I am, or monitor several vulnerability databases, they may have missed the fact that several software packages had a fairly serious vulnerability. This is a good example of the value-add that some vulnerability databases offer due to their followup research and organization.
I also have to wonder if the authors of sux0r know that one of the packages they use, also uses other packages. This makes me wonder how many layers deep some of the software goes these days, and if the authors of these packages fully grasp the web of code and dependencies that are created. Imagine having a really accurate mapping of such relationships and integration, that would let us see just how far one vulnerability can spread into different codebases. A while back, I mentioned how this would be incredibly helpful to vulnerability databases in some cases. Imagine having this same type of system that linked software package integration and dependancies. When a given package is found to contain a vulnerability, you could instantly know that it likely affects seven other software distributions, all of which need to upgrade their dependancies or fix the issue themselves. I know, pipe dream but still a nice thought!
Posted in Vulnerability Impact | 1 comment
Posted by jericho
Thu, 02 Mar 2006 06:56:19 GMT
Lance James of Secure Science Corporation posted an advisory detailing a serious flaw in the Fedex/Kinkos ExpressPay smart card payment system. A knowledgeable attacker with relatively minor resources can abuse the system to defraud the company. In response to the advisory, Fedex/Kinkos replied to them saying:
“Our analysis shows that the information in the article is inaccurate and not based on the way the actual technology and security function. Security is a priority to FedEx Kinko’s, and we are confident in the security of our network in preventing such illegal activity.”
Secure Science replied with an image of a receipt showing that it can be done. In case that wasn’t enough for some skeptics, they also released a video showing the abuse in action. Hopefully this will encourage Fedex/Kinkos to change their stance and take back the comment about their confidence in the security of their network/technology. This whole incident reminds me of the l0pht’s catchy slogan: ”Making the theoretical practical since 1992”
Posted in Vulnerability Impact | no comments
Posted by jericho
Tue, 24 Jan 2006 22:23:28 GMT
From time to time, vendors will contact OSVDB to notify us of solutions to vulnerabilities included in the database. These are almost always very professional mails, usually polite, and sometimes include all the details we need/want. These mails may say something along the lines of “we have fixed this issue” which prompts us to ask if it is a patch, upgrade or workaround. Other times they are very descript and provide all the information we need to update our entry, add more detail and provide the best information to our users and their customers.
Every once in a while, we get a real winner. On Dec 29, 2005, Global I.S. S.A. contacted us regarding entry 21429, saying ”This vulnerability has been addressed.” Within minutes I replied asking if this was in the form of an upgrade or patch but did not hear back from them. On Jan 2, 2006, they contacted us again asking ”This is our second request for a change. Is anybody home?” So they didn’t receive my initial reply I assumed (nor did they acknowledge my second reply), but that isn’t what grabbed me. The rest of their mail did:
The vulnerability you refer to has been resolved.
For security we do not release the nature of the solution/s.
It is criminially negligent to publish hacks on the web without first notifying the author.
Let us know if you have a question.
On top of the veiled legal threat (which I love!), their comment that they do not release the nature of the solution is baffling.. moreso that they do this “for security”. Vendors, take note: the one time you want to be completely open and honest with information is when it comes to solutions to vulnerabilities. Witholding information or making it unclear/confusing only contributes to insecurity as customers don’t know the extent of the issue, nor how to easily mitigate the vulnerability.
Posted in Vulnerability Impact | 2 comments
Posted by jericho
Sat, 07 Jan 2006 12:42:15 GMT
Something lead you to the product that ended up on your systems. Be it a feature, a look, ease of use, or price, it was a driving force in your decision. Changing to a different product isn’t easily done, especially if your current solution is heavily integrated or customers/users are familiar with it. Besides, what other product can fill your needs that doesn’t have vulnerabilities of it’s own? Look at the amount of vulnerabilities released along with the diversity of the products. Whether it is no name freebies or million dollar commercial installations, every package seems to have vulnerabilities that would drive you back to where you started.
Offering a “solution” of “Use another product” doesn’t seem very intuitive, logical or helpful to customers.
Posted in Vulnerability Impact | no comments
Posted by jericho
Thu, 15 Dec 2005 02:07:15 GMT
Often times you will see a VDB or researcher disclosure offer the solution ”Edit the source code to ensure that input is properly sanitised.” I’ve never been fond of this for several reasons. First and probably the most obvious, duh? If I proclaim “send food to the hungry”, have I now provided a solution for world hunger? No need to debate semantics or definitions, the bottom line is I haven’t (or we wouldn’t have the problem anymore). So offering a solution of “editing the source to sanitize input” is about as helpful as my solution. Second, if the solution was really so easy, wouldn’t the devlopers have done it in the first place? Couldn’t we apply such advice to all programs from all projects? Third, most users and administrators don’t have the programming experience to make such source code changes. Even if they did, most simply don’t have the time to edit every package they may use, let alone fully test their changes and ensure functionality and security.
Posted in Vulnerability Impact | 2 comments
Posted by jericho
Tue, 15 Nov 2005 13:23:05 GMT
David Litchfield posted to Full-Disclosure pointing out more Oracle errata:
http://archives.neohapsis.com/archives/fulldisclosure/2005-11/0449.html
From: David Litchfield (davidl@ngssoftware.com)
To: ntbugtraq@listserv.ntbugtraq.com, bugtraq@securityfocus.com, full-disclosure@lists.grok.org.uk
Date: Tue, 15 Nov 2005 13:12:41 -0000
Subject: [Full-disclosure] Three years and ten months without a patch
Whilst looking over old Oracle bugs I discovered that a fully patched 8.1.7.4 Oracle server is still vulnerable to the old extproc flaw; this flaw, when exploited, allows a remote attacker without a userID and password to take control of the server. Why, you may ask, has a supported product gone for so long without a patch for a serious problem that was made public 3 years and 10 months ago and reported to Oracle over 4 years ago?
[..]
Litchfield’s mail contains a link to additional commentary with an answer to the question above. Oracle can spin this how they please, but I think Litchfield has hit the nail on the head.
Seeking an answer to this I found the following in Alert 57:
Currently, due to architectural constraints, there are no plans to release a patch for versions 9.0.1.4, 8.1.7.4, 8.1.6.x, 8.1.5.x, 8.0.6.3, 8.0.5.x, 7.3.x, or other patchsets of the supported releases.
What? Wait a minute. They managed to fix the flaw and deal with the same “architectural constraints” in other versions - why not 8.1.7.4? A cynical observer might conclude that Oracle have deliberately left this unpatched in order to improve the chances of their user base upgrading to a version of Oracle that has a patch and having to part with more money. Oracle customers running 8.1.7.4, or any of the versions listed above would be right to feel indignant. This is exactly the kind of thing I was referring to when I posted this open letter.
Posted in Vulnerability Impact | no comments
Posted by jericho
Wed, 19 Oct 2005 03:56:50 GMT
I had planned on writing about this weeks ago but got swamped with that pesky day job along with the steady stream of new vulnerabilities released daily. That steady stream that absolutely will not get better with vendors taking a new approach to dealing with them. Fortunately for me, John Dvorak wrote an article and voiced some of my opinion as well. This comes some three years after Richard Forno wrote a related piece.
http://www.pcmag.com/print_article2/0,1217,a=162175,00.asp
The Microsoft Protection Racket
By John C. Dvorak
Does Microsoft think it is going to get away with charging real money for any sort of add-on, service, or new product that protects clients against flaws in its own operating system? Does the existence of this not constitute
an incredible conflict of interest? Why improve the base code when you can sell “protection”? Is Frank Nitti the new CEO?
So what is actually going on here? I think there were some bottom-line questions that must have been brought up internally. Obviously someone at Microsoft looked at the expense of “patch Tuesday” and asked, “Is there any way we can make some money with all these patches?” The answer was “Yeah, let’s stop doing them and sell ‘protection’ instead.” Bravo! And now the company has a new revenue stream.
What Dvorak doesn’t mention that is just as important, is that Microsoft is not the only one doing this. A colleague recently pointed out that Symantec is offering IDS/IPS solutions for their own software. So instead of truly patching a vulnerability, they can quickly write a rule/filter to stop attacks against a specific/known attack. While this is often effective, history shows us that such solutions often fall victim to being bypassed with crafted requests, altering exploit code or using various evasion techniques.
SYM05-011 - August 12, 2005
VERITAS Backup Exec for Windows Servers, VERITAS Backup Exec for NetWare Servers, and NetBackup for NetWare Media Server Option Remote Agent Authentication Vulnerability
Revision History
8/12/2005 - Revision One - updated details, affected products and response information.
8/12/2005 - Revision Two - Adding Tech Support links to currently available product updates as tested and posted for download by Symantec engineers. Link to IDS/IPS signatures for Symantec Security products.
8/13/2005 - Revision Three - Added Tech Support link to additional product updates. All supported affected products have updates available now.
8/14/2005 - Revision Four - Added links to IDS/IPS signatures for additional security products. All relevant Symantec Security products have signatures available now.
Again, what is the motivation/incentive for a vendor to patch a vulnerability, when they can just as easily ignore it, and spend time developing a profitable workaround or additional product?
Posted in Vulnerability Impact | 1 comment
