Slashdot Mirror
Microsoft Admits to Hiding Flaw Details
Spongeform writes "eWeek has an interview with a Microsoft security official admitting to hiding details on software vulnerabilities that are discovered internally. The reason? Microsoft believes that full disclosure of every security-related product change only serves to aid attackers. However, companies using host-based IPS that rely on flaw information to build signatures are basically left at risk because of Microsoft's silent fixes."
Well, here's another reason why that report was flawed - it turns out that Microsoft are fixing multiple vulns in one advisory - from the article:Of course, Microsoft is going to argue that they fix vulns silently to prevent the 'bad guys' from using the patch info to create attacks, but this is refuted by the same researcher:
There are shills on slashdot. Apparently, I'm one of them.
I seem to remember being told in my software engineering class of a type of protection that provides a false sense of security. I think that Microsoft may be becoming more and more guilty of it.
Perhaps it's time they should change their "Who would ever think to put those bytes there anyways?" mantra.
My work here is dung.
Relying on software developed and maintained by someone else always leaves you vulnerable to changes they make.
This isn't exactly limited to Microsoft.
FTA: "We want to make sure we don't give attackers any [additional] information that could be used against our customers.
But, if they are your customers, they can get the patches no problem right? So really this policy only helps out the pirates. Right?
Your sig(k) has been stolen. There is a puff of smoke!
If you had read the article rather than rushing to get first post, you would know that they're talking about releasing information about flaws after the patch is released.
If you still don't understand why they should release information, consider the following from the article:
There are shills on slashdot. Apparently, I'm one of them.
Can there truly be a flawless operating system?
Is it possible to design an easy to use, accessible, and reliable application that has no security holes?
I think not, but if you could, you may become richer than Gates himself.
The reason you wouldn't become richer than Gates if you did this is that it would be incredibly expensive to develop such a system. You would also have a long time-to-market. The result would be a very reliable operating system that is late to market and incredibly expensive. Your would-be customers would then choose your cheaper competitors that have more modern features that they have come to expect. These features would be ones that were invented during the huge period of time that your operating system is going through its rigorous design, implementation, and verification process.
Even coming up with a workable definition of a "flawless operating system" and stating exactly what criteria is used to certify the product as "easy to use, accessible, and reliable" would takes a lot of time and money.
Perhaps I should be clearer. My quote included The attackers are already reverse-engineering the patches.
All the attacker needs is the patch - they can look at that to see whats changed and where & deduce from that where to start looking for attack vectors. It's not particularly a big help for them to hear "Function blah in program blah has changed"
System Administrators on the other hand do not have time to reverse engineer the patch, but can read the summary and say "we don't use function blah in program blah, lets apply the patch as it won't affect our operations" or "Holy shit, we have program blah exposed to a hostile network, lets quickly test our stuff & rush the patch out"
So what Microsoft is actively hampering administrators and not hindering attackers.
There are shills on slashdot. Apparently, I'm one of them.
Doesn't SLASH have a similar policy?
If you had read the article rather than rushing to point out slashdot's supposed hypocrisy, you would know that they're talking about releasing information about flaws after the patch is released.
Nothing to with responsible disclosure at all.
There are shills on slashdot. Apparently, I'm one of them.
But didn't I read someplace that Microsoft were coming out with their own anti-virus/anti-whatever suite with a monthly service charge?
With that in mind - why would they tell other, competing, anti-virus companies what flaws to protect against?
Come to think of it - why bother fixing flaws at all - just defend against them in the MS Anti-virus gadget instead and encourage people to pay the anti-virus tax. It might even be tempting to add the occasional flaw just to make that work better.
I don't know whether any of these things will actually happen - but you simply can't trust the motives of a company that behaves the way MS consistently does.
www.sjbaker.org
RFPolicy is a solid policy for allowing a vendor to be notified in a timely manner (5 days), let them work with the reporter to get a plan of action together (such as a quick way to notify customers and let them get the fix rolled out) and help the vendor reproduce the bug/verify the fix, before notification of the general populace.
If, at any point, the vendor suddenly decides to play not-nice, the RFPolicy is quite clear -- go ahead and post it to bugtraq or whatever you like. It also states that the vendor should acknowledge the original disclosure. That is, if I found a vulnerability in slashcode, but delayed publication because I was trying to get it fixed in good faith, the Slashcode developers would acknowledge my efforts in their advisory -- even if someone else comes along and posts an advisory after I report it to the team, but before the team has posted an announcement.
Nowhere in the RFPolicy v2.0 does it say anything along the lines of, "Hey, you should silently slip-stream fixes without ever notifying anyone ever " -- which is what this article is about Microsoft doing.
The shit that gets modded up. I swear, we need a "-1 WRONG" tag we can apply to posts. Some kind of clue stick for the mods that don't bother to look up RFPolicy would also be good.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
Au contraire. The RFPolicy gives the vendor five working days to respond to a communication from the discoverer of a vulnerability, after which the discoverer can go public at any time. The discoverer and vendor are encouraged to work together to make a joint statement of the vulnerability once there is a fix.
There are two kinds of sysadmins: paranoids and losers. I'm both kinds.
I recall reading an article on the ISC website asking folks if they knew the inner working of Oracle's (many, many) patches. It seems as if this vendor as well hides in innermost details of the bugs their patches fix too. It takes many levels of registration, subscription, etc. to get one of their update e-mail newsletters outlining the patches. But even then the details are a bit sketchy. Perhaps this practice isn't just limited to Microsoft. But since Microsoft is perceived as the big bully on the block this makes better fodder.
What you have to understand, what the American people have to understand, is that we're at war. The fact that we're talking about these vulnerabilities simply emboldens the enemy.
"Flawlessness" is unattainable. No intelligent design team would aim for it. But reasonable security via a reasonable effort is certainly attainable. UNIX is proof. ;-)
please, let's not start THAT old discussion here, as if the evolution team makes such flawless products
Exercise caution when modding this message up: the author acts like a jerk when his karma is excellent.
System Administrators on the other hand do not have time to reverse engineer the patch, but can read the summary and say "we don't use function blah in program blah, lets apply the patch as it won't affect our operations" or "Holy shit, we have program blah exposed to a hostile network, lets quickly test our stuff & rush the patch out"
And that's the crux of the problem. Of course, given Microsoft's checkered security history, why should this come as a shock? If I were a system administrator, I'd be applying every patch they handed me, on the off chance it's patching an obscure vulnerability I'd never catch in a million years. You can't worry about what Micrososft thinks is severe; while not every vulnerability is immediately exploitable, we've seen how easily unpatched vulnerabilties have allowed the black hats to create botnets overnight. If there's a way, the bad guys will find it, and it's stupid to leave any part of your system vulnerable for too long.
GetOuttaMySpace - The Anti-Social Network
That's the crucial problem in this policy. People, especially people who're wary when it comes to MS "patches" or those who have to watch their bandwidth (unless they want to pay extra for more traffic) will read patchnotes carefully, then ponder what the patch does according to the info given and more often than not (especially when the patch is supposedly for a feature they don't use) they'll simply say "Don't need it. Doesn't apply to me."
This patch might have fixed a key security hole. But if you don't know it, how should you decide whether you should apply it? I don't buy the story that MS knows what's good for me. If anyone knows, I do. And I certainly won't hand this decision over to someone else.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
If I were a system administrator, I'd be applying every patch they handed me, on the off chance it's patching an obscure vulnerability I'd never catch in a million years.
If you apply a Microsoft patch for something that is never likely to affect you, you're taking a bigger risk by applying the patch!
Most people here should be aware that applying a Microsoft patch is likely to screw something up -- something Microsoft has become renowned for.
Linux/Open Source/Anti Microsoft News
I really disagree. This is security through obscurity, and hiding the plain english description of an available patch only limits the n00b level black hats (scriptkiddies and the like!)
all the information about what is patched is directly available in patch, exposed via a relatively simple decompiling operation. A compare of the newly provided DLL and the original show you clearly what the original lacks. And as such, how you can attack anyone unpatched, or figure out what other DLLs may have such a problem.
I remember helpctr.exe was the first executable I ever did this to. Simple buffer overflow, before SP1.
Browsing with classic discussion, noscript, at -1 and nested
no hidden comments and I only mod UP
A) Who in the tech world didn't aleady know this?
The news is that microsoft are admitting it. The security community have 'stronly suspected' this for years.
B) Do you realize even *nix vendors do this, including Linux distributions?
Could you please provide an example of this (for linux vendors)?
Of course - even if you do find an example (I doubt it), it doesn't change the fact that its just the distribution - the upstream developers will have released patch information, etc. There is no parallel for this sort of openess in the windows world.
C) Do you also realize that Apple patches more items in a single Patch on average compared to MS by a factor of 10 or more?
I do realise Apple patches multiple vulns in one go. Fortunately however, anything remotely important that is distributed by Apple is written by third parties with more responsible discolure policies (ie openbsd, the apache foundation).
You make a good point about granularity of "bug counting" lists. There's a lot of room for improvement.
There are shills on slashdot. Apparently, I'm one of them.
Please reread my post.
You write:Most Windows system administrators are not programmers, and of those that are fewer still are technically skilled enough to reverse engineer a binary patch.
Which is exactly what I quoted:The guy that feels the pain is the system administrator who is in the dark and who can't do his own reverse-engineering,"
It's the attacker doing the reverse engineering, not the sysadmins.
There are shills on slashdot. Apparently, I'm one of them.
Anyone remember the (deeply flawed) Cert statistics where Microsoft had 812 vulnerabilities compared to Unix + Linux's 2328?
Indeed.
What makes it worse is that Microsoft knows full well that this data is false, and still uses this in its FUD attacks against Linux/Open Source.
Even if Microsoft persuades people that it has a good reason for not disclosing vulnerabilities, Microsoft has no good reason to use false statistics, created by its hiding of information, in order to help persuade people that its software is more secure.
Linux/Open Source/Anti Microsoft News
Those previous statistics also failed to take into account that most of the vulnerabilities in apps for linux, can also exist if those same apps are installed on windows...
Apps such as Apache for instance, can easily be installed on windows and most of the issues found will affect any platform running the software.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
This got moderated Insightful?
That would be an insightful comment... in fantasy land. Most Windows system administrators are not programmers, and of those that are fewer still are technically skilled enough to reverse engineer a binary patch.
Exactly - so how are they meant to know what it does? On the other hand, at least some of the bad guys can and will reverse-engineer to the patches. (Some security researchers are able to too, hence why this came out, but they probably don't have the time to do it for every single patch.)
Microsoft has a valid point when they say that publishing vulnerabilities mainly helps out 'bad guys' because the majority of their 'good guy' users don't have the skills to counterattack. It's not like the open-source world, where there's a large community of skilled programmers ready and willing to publish fixes... and, more importantly, outnumber skill-wise any malicious programmers.
We're talking about vulnerabilities for which Microsoft has already released a patch - all the sysadmins need to know is that it exists and they need to apply it. The fact that Microsoft is providing incomplete information about what its patches fix means that some systems might not get patched because the administrators think it doesn't apply to them and don't want to risk breaking stuff by applying it.
If I have two binaries, I can compare them. I have tools that can walk the function entries and traverse code. If I find a function binary difference, I can scrutinize it to try to determine what has been "fixed".
Now, I *am* an experienced developer. When I do initial probes on "black box" binaries, I actually prefer to NOT have source available (as I am interested in what it is doing, not the comments or source that the original programmer put down indicating what it was intended to do).
Administrators? Generally can't do it. If I WERE a "black-hat", I would be all over the actual patches. I don't care about the paper reports.
The paper reports are critical to the administrators. They are not looking for a crack -- they have to trust that the changes have been checked and the work done carefully to avoid additional problems. But the only way the administrator has to determine if a patch should be applied, and what the risk is, is by full vendor disclosure. The "black-hats" don't really care that much. Of course, full disclosure can be a public relations nightmare.
The advantage that "open source" has here is that the laundry is already out in the open. Reputation can be (perhaps) slightly reduced by exploits, but it (again generally) doesn't destroy the product.
As an example, many people (including me) use sendmail and bind.
However, a closed source provider typically stakes a marketing created reputation. Exploits can really hurt. Take Windows 9x as an example. About the only thing Microsoft can do is state that future Windows are more secure. (even though Windows 98 as a core is reasonably hardened, as long as trojans are not executed, which it is VERY vulnerable to).
Oh, and "good guys" don't "counterattack". Just because someone attacks sshd on my box doesn't mean I turn around and attack. Generally, I ignore it. A "counterattack" stops at reporting the attempts to an upstream provider if they are very persistent (or successful).
Just another "Cubible(sic) Joe" 2 17 3061
Perhaps, but do you really think microsoft tests every possible patch configuration? I'd bet they only test the last service pack plus the patch and maybe current with all updates. You're taking a risk running a "non standard" environment too. Besides, you should always patch a few systems that seem common to your environment before rolling out patches in a large corporate environment anyway.
MidnightBSD: The BSD for Everyone
The big difference is a patch for Oracle 9.0.7, isn't going to change the functionality of your email client. Just as a patch for a Cisco 9320, isn't going to change how your flatbed scanner works. A MS Word patch could change how your email client works, or how your flatbed scanner works.
Food not Bombs is a nice platitude but it breaks down when you notice that the Bombees are usually well fed
do you really think microsoft tests every possible patch configuration?
No.
You're taking a risk running a "non standard" environment too.
I am?
Besides, you should always patch a few systems that seem common to your environment before rolling out patches in a large corporate environment anyway.
Indeed. You should test the patches first; however, if there is a vulnerability that you really must patch, and it's going to knock out something you're dependent on, either way you lose.
Linux/Open Source/Anti Microsoft News