Slashdot Mirror
Another Critical Microsoft Hole
gmuslera writes "Not was enough that recent vulnerability in IE that can run any program in an unpatched windows system. Now there is another
related to an ActiveX control that can make IE and IIS to run any code in the system. The Microsoft solution? kill the related ActiveX control and replace it with a safe one. The Microsoft problem? As this control is Microsoft signed, any site can require it, upload it and replace the "good" one with the vulnerable one. The final recomendation from Microsoft? Don't trust/run ActiveX controls signed by Microsoft." Gimble points to the appropriate locations on Microsoft's website: "Another buffer overrun (that allows arbitrary code to be run) has been admitted to by MS, and it affects IIS and IE on clients (but not on XP), and they have a patch available here Security Hotfix for Q329414. The kicker is that a patched system can be rendered vulnerable again by a hostile web site or HTML email. The 'solution' from MS in Microsoft Security Bulletin MS02-065 recommends that you remove MS from the list of Trusted Publishers."
It's getting tiring to see all this sarcasm, like open source is so free of bugs or something...
If Microsoft tells users not to trust it for this, when should users trust it?
The joke is to say never. But with Microsoft controlling however many trillions of computers, it seems like something they should seriously be addressing. And more seriously than they are.
Let's hope the US Government gets it. There is cause for concern (article titled "Microsoft seeks government partnership").
I do not have a signature
I didn't beleve this was true at first but this is actually what it says in the Security Bulletin:
--
What steps could I follow to prevent the control from being silently re-introduced onto my system?
The simplest way is to make sure you have no trusted publishers, including Microsoft.
--
but I think Microsoft is doing the right thing here. They are in a pickle and they have given a good solution (and one that is embarrasing to them). Of course what they should really do is redesign IE to not run in "root" mode but that is another story. I wish the slashdot editors did not relish so much the foibles of Microsoft in their editorial comments.
I miss the Karma Whores.
According to the MS release, the reason that they can't simply revoke the certificate for the control is that they signed other controls with the same certificate.
Wouldn't it make sense for them to just sign every control with a DIFFERENT certificate, so when one is found to be flawed they can revoke the cert and only the new version will install easily?
It's not like MS can't afford the cost of the individual certs, if they aren't a CA themselves already...
Here's a theory I've long held regarding the excessive number of buffer overrun security holes in MS software:
The lack of an snprintf method in the DevStudio standard C lib causes MS developers to use the unbounded sprintf instead, potentially resulting in buffer overruns.
What do you think?
I don't know if I'm karma whoring, but this last security hole gives me the creeps. In all honestly, I kinda ignored them up until now -- I don't know why, but I think it was because "they" could not delete my data (nothing scares me more than losing my documents (read: not "My Documents"). This security hole that allows people to "format my hard disk" (quote from the original /. article that I cannot be bothered to find) has me burning My Documents to CD-RW which I'm going to (finally) migrate to my Linux laptop which I previously used only for programming.
I know we've seen a million security problems from MS before, but this one (for me at least) is the last straw.
Hang on, let me catch up here. Did Linus digitally sign a control in a subsystem designed to download code from any old webserver you might happen upon and run it as root while I was looking the other way? And did he, after it was discovered that such a system is not perfectly, 100%, safe *astonished look* issue a warning on the Linux kernel developer mailing list stating, in effect, that he's a jackass and people should stop trusting him with anything more dangerous than a moist sponge in a bathtub?
I don't think so.
Money for nothing, pix for free
I'd have to agree with you that it gets tiring seeing IE exploit of the week ( or day ) and the retreaded jokes and karma hores. But then maybe you can filter them in your preference?
The thing is MS is the system that is allegedly on 90%+ of the desktops in the USA and maybe the world. They did'nt get there legally and they do not take security, law, or human rights seriously. They spend millions on advertising, FUD and outright lies. So in the end I guess I don't mind suffering the constant reminders as to why I don't use any of their products. What other news source reports this stuff?
Besides, nothing puts I smile on my face in the morning like a cup of coffee and a new MS exploit.
Kind Regards
"A few great minds are enough to endow humanity with monstrous power, but a few great hearts are not enough to make us w
If this doesn't affect XP, why can't Microsoft just issue a patch that installs the Windows XP components which aren't vulnerable? And also... why the hell isn't XP vulnerable? maybe they knew about this for a long time...
>You have to have said at some point that you >trust Microsoft
;) you _have_ to agree to trust them.
If you want to run windowsupdate (to remove security risks
The only system that doesnt trust Microsoft is a outof the box unpatched one - and then you are fried anyhow...
A clear catch 22
Sure they did. I think you did not read the notice, and are the one missing something here...
From bulletin:
===
Why not revoke the certificate that was used to sign the control?
The certificate that was used to sign the control is still valid - the problem lies in the control, not the certificate. In addition, a number of controls have been signed using the same certificate, and revoking the certificate would cause all of them to become invalid.
===
Additionally, there is this tidbit, about killing the control w/o revoking the certificate:
===
Will Microsoft eventually set the Kill Bit on this control?
Yes. Microsoft is developing a new technology that will enable it to set the Kill Bit on the vulnerable version of the control without forcing users to re-author web pages containing references to these controls. When the new technology is available, we will ensure that this fix uses it.
===
Bottom line: they *could* revoke the certificate, but it would screw up other controls that use it.
The day my bug-ridden OSS software starts silently self-installing across the web because my box was automagically set up to 'trust' the 1s and 0s, I'll stop making fun of MS.
.. you can't honestly think that the Linux crowd is the only group of users that enjoy crass, glib jabs at the competition now, can you?
Until that day, I'll get my kicks from MS bashing. You've read and heard the things Baller & co have said about Linux (I particularly liked the "Linux is unamerican" comment, hehe)
So cease thy whining and either bash or don't. No need to pass judgement unless your prepared to accept that the whole world is guilty of the behaviour you are so desperate to eschew.
"Old man yells at systemd"
In Microsoft's Technet Security Bulletin MS02-065. It's linked from the submission and still not Slashdotted. However, as a free service (maybe you're afraid of surfing to untrusted websites), I am hereby reproducing some of the juicy bits:
Please note that this will generate a warning message EVERY TIME you encounter an ActiveX control - whether it is signed or unsigned. So how would you tell the difference between a 'bad' Microsoft-signed control and a 'good' one (ignoring for a moment the inherent badness in ActiveX)? The short answer is: You can't. You're toast. Muahahahaha!
All I see is not to trust an ActiveX pop-up warning that might be comming from someone OTHER than Microsoft...
Not that easy, I'm afraid. First, if you have been a good astroturfer you have undoubtedly cheched the "Always trust content from Microsoft Corporation" checkbox the first time you saw it (or your keeper checked it for you). Therefore, you will NOT be getting a pop-up warning. Second, the pop-up warning you may get if you haven't added Microsoft to your list of Trusted Publishers does indeed come from Microsoft. Bill Gates more or less personally guarantees the security and validity of Microsoft Corporation's digitally signed certificates (unless they've been hacked again, but that's so unlikely that it probably didn't even happen the first time).
Oh and if I see M$ or Micro$oft one more time I'm going to puke...
Most astroturfers do. It's a feature of your implants and nothing to be ashamed of.
Money for nothing, pix for free
Why all the focus on microsoft products, I submitted an exploit for opera a month or so ago, and it was rejected.
autopr0n is like, down and stuff.
Aberdeen Research Group has this to say about open source and Linux security:
Open Source and Linux: 2002 Poster Children for Security Problems
November 12, 2002
Open source software is now the major source of elevated security vulnerabilities for IT buyers. Security advisories from Cert for the first 10 months of 2002 show that open source and Linux software accounted for more than half of all advisories. The poster child for security glitches is no longer Microsoft; this label now belongs to open source and Linux software suppliers.
Read more here
What better way for the US Gov to get some spyware into all M$ installations, than to have M$ issue a major warning like this. I'm sure they're considering using M$'s monopoly to exploit eavesdropping on some of Al Qaeda's employees.
"The error of Applied Cryptography is that I didn't talk at all about the context. I talked about cryptography as if it were The Answer. I was pretty naive.
The result wasn't pretty. Readers believed that cryptography was a kind of magic security dust that they could sprinkle over their software and make it secure. That they could invoke magic spells like "128-bit key" and "public-key infrastructure." A colleague once told me that the world was full of bad security systems designed by people who read Applied Cryptography."
-Bruce Schneier
> A colleague once told me that the world was full of bad security
> systems designed by people who read Applied Cryptography
Apparently the Microsoft code-signing system is one of them.
We can go back and forth all day long about the quality of that or any book; it happens to be one I get a great deal of use from. Fact of the matter is, there are open, standard public-key infrastructures that are designed such that this "problem" wouldn't be a problem at all, just a barely noticed update to the CRL that wouldn't disturb anything else in the system. Microsoft got infected with the Not Invented Here syndrome, and Windows admins are now suffering the results.
This thread is tiresome, so I'll leave it at that. Cheers. =)
25% Funny, 25% Insightful, 25% Informative, 25% Troll
So this is news because it blows the doors off the signed executable philosphy and makes the sandbox philosohy of the java VM look like the only viable approach. Notice that the JAVA approach would have avoided both problems. first it would have avoided the buffer overrun problem in the first place since that would be caught by the VM when it examined the code, and second there would be no signed app trustworthyness issue.
Some drink at the fountain of knowledge. Others just gargle.
I really like that the mainstream press is using "yet another" here. Think about your neighborhood: if somebody down the street gets burglarized, it's a terrible thing, but it's an isolated incident, and in a couple of days, you'll unload the shotgun and soundly again. But when two houses a week get broken into, well, you're gonna start acting like there's a pattern here.
What will happen when people start treating Microsoft's security lapses like the epidemic they are?
This is not my sandwich.
Does Windows Update require signed ActiveX controls?
If so, I presume the default action would be to trust Microsoft controls? Will this mean that the majority of users will be exposed to this problem?
Actually, I think more realistically, this would mean that Windows Mozilla would become the next hot bugtraq item. Mozilla running on Windows is not the same as Mozilla running on any other OS. Mozilla is guilty of using Windows-specific stuff too (like the JavaScript interpreter).
While that would be better for Mozilla (more bugs would be found faster, and there would be more incentive to become as homogenous across platforms as possible), I'm not sure it if would help Windows users all that much because by default Windows users are at or near the equivalent of root users. Windows is a security-week OS. Granted, integrating something like a web browser so tightly with the OS doesn't help, but the problem is still that regular Joe user is still allowed to do a lot of damage on his own with little or no checks and balances. Don't get me wrong. I don't like Windows, and I choose to run Linux on my desktop, but Microsoft-related security problems go a lot deaper than just IE.
Personally, I'm not sure there's a way around this problem. Attackers are smart and well-informed. Not being fooled into running bad stuff requires knowledge, a healthy dose of skepticism, and vigilance. The problem with Microsoft software in general is that it makes it trivial for the ignorant user to run bad stuff. If all the buffer overflow and security wholes were fixed tomorrow, it still wouldn't stop companies from developing spyware, nor would it stop attackers from using social engineering to find ways into systems. This plagues even the non-MS world (look at the recent compromises in OpenSSL and sendmail).
Here's an anology: Imagine that I was a "car cracker", and I devised a way to sneak into gas stations and replace their fuel with sugar water. NO ONE would notice until their cars stopped running and their engines siezed. Why? Who smells or tastes or tests gasoline from the pump before it goes into their car? The only real thing stopping someone from actually doing something like this is the logistics of cracking a gas station's fuel supply. As a result, people have a reasonable (and yes, in this case it is reasonable) amount of trust in what's coming out of the pump (even if it is gas-ohol).
However, it's much easier in the world of easily-reproducable flying bits to do something very similar. There's a much smaller barrier there. Now users really should smell/taste/test their gasoline before they put it into their car. The only problem is, just like with the car analogy, there's little to no tools available to make that process available to the common consumer. What's worse is that even if they were, the common consumer is so lazy, they probably wouldn't take advantage of them unless they were forced to.
No, I am not an advocate of DRM. I hate the stuff. If anyone ever tells me I can't use my computer the way I want, I'll kill 'em (metaphorically...I don't wish actual physical harm to befall anyone...it's not my place to judge and dispense punishment). My point is that Windows has a very long way to go before these types of problems will become manageable again, with or without Internet Explorer.
In a lot of situations, installing software is less like putting gas in your car and more like buying 50 kilos of cocaine. In that scenario the buyer doesn't trust that the seller hasn't cut the dope. As a result he has the tools (guns and methods of determining drug purity) to help ensure the transaction goes smoothly.
Okay, maybe that analogy doesn't work either, but I think you get my point.
moto411.com
It sounds like the same one that runs on every other Mozilla platform.
If that were true, then the behavior of the following would be the same across platforms:
document.forms.FORMNAME;
document.forms["FORMNAME"];
Note: the first statement works in all versions of IE that support JavaScript on both the WIndows and Mac OS X platforms. The first statement doesn't work in any version of Mozilla except the Windows versions. Several conclusions might be drawn from this:
- The Mozilla JavaScript interpreter is different for its Windows binaries
- Mozilla running on Windows is borrowing the built-in JavaScript interpreter
- The Windows loader/linker (or equivalent) is forcing Mozilla to use the wrong JavaScript interpreter (though this is pretty unlikely)
If someone knows/finds out, please let me know. I'm dying to find out.moto411.com