If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#31
|
|||
|
|||
Microsoft Zero Day security holes being exploited
"imhotep" wrote in message
... Roger Abell [MVP] wrote: regsvr32 -u "%ProgramFiles%\Common Files\Microsoft Shared\VGX\vgx.dll" which is the first workaround mentioned in the MS advisory, may fail in some locales. As Jesper (and others) have indicated, it should use %CommonProgramFiles% http://msinfluentials.com/blogs/jesp...-a-domain.aspx http://tinyurl.com/mtcbd quote Update Sept. 21, 2006 Uploaded a new version of the archive that uses %CommonProgramFiles% instead of %ProgramFiles%\Common Files to specify the file location. This helps make it work on non-English systems that have translated the name of the Common Files directory. /quote Those interested should see his Friday's blog that not only discusses the third-party patch route, but also outlines another approach to the current (and the Direct Animation control's path) vulnerabiltiy http://msinfluentials.com/blogs/jesp...-a-domain.aspx http://tinyurl.com/h3buq I will pass this along to the helpdesk guys. Thanks. Any ETA about the patch/fix from Microsoft? No, and I have not seen a reason to ask. MS took the unusually step of detailing workarounds that crippled functionality in their initial advirory. That was no doubt in response to analysis showing code availability, exploit character, and extent of testing that would be needed (i.e. time to delivery). From that I fully trust resources were marshalled in appropriate scale. Typically the owning group of the involved code finishes its work, which includes review for similar/related flaws, quite quickly. For something like this, that could have impacts on non-MS code, the test cycle is where the time gets consumed (read: not all testing is in-house). (You trapped me with that dumb follow-up once more !!) |
Ads |
#32
|
|||
|
|||
Microsoft Zero Day security holes being exploited
I have to agree with Imhotep.
I have been thoroughly p****ed off this week as a result of a virus which somehow evaded the countless security systems I have in place. In retrospect, the 'vulnerability' is simply MS stupidity. Imagine allowing WinLogon to to load arbitrary DLLs into its address space simply by adding entries into the registry. WinLogon is supposed to be my first line of defense against security issues. What are they thinking ? About money, obviously ! |
#33
|
|||
|
|||
Microsoft Zero Day security holes being exploited
Roger Abell [MVP] wrote:
"imhotep" wrote in message ... Roger Abell [MVP] wrote: regsvr32 -u "%ProgramFiles%\Common Files\Microsoft Shared\VGX\vgx.dll" which is the first workaround mentioned in the MS advisory, may fail in some locales. As Jesper (and others) have indicated, it should use %CommonProgramFiles% http://msinfluentials.com/blogs/jesp...-a-domain.aspx http://tinyurl.com/mtcbd quote Update Sept. 21, 2006 Uploaded a new version of the archive that uses %CommonProgramFiles% instead of %ProgramFiles%\Common Files to specify the file location. This helps make it work on non-English systems that have translated the name of the Common Files directory. /quote Those interested should see his Friday's blog that not only discusses the third-party patch route, but also outlines another approach to the current (and the Direct Animation control's path) vulnerabiltiy http://msinfluentials.com/blogs/jesp...-a-domain.aspx http://tinyurl.com/h3buq I will pass this along to the helpdesk guys. Thanks. Any ETA about the patch/fix from Microsoft? No, and I have not seen a reason to ask. Surely the critically merits promptness. Does it not? MS took the unusually step of detailing workarounds that crippled functionality in their initial advirory. That was no doubt in response to analysis showing code availability, exploit character, and extent of testing that would be needed (i.e. time to delivery). From that I fully trust resources were marshalled in appropriate scale. Typically the owning group of the involved code finishes its work, which includes review for similar/related flaws, quite quickly. For something like this, that could have impacts on non-MS code, the test cycle is where the time gets consumed (read: not all testing is in-house). (You trapped me with that dumb follow-up once more !!) Asking if you knew of a ETA? Sorry, but I thought you actually might know. No trapping this time.... |
#34
|
|||
|
|||
Microsoft Zero Day security holes being exploited
Karl Levinson, mvp wrote:
"imhotep" wrote in message ... I assure you, a crap load of people will NOT be infected by this or any other IE vuln in the future. IE vulns just don't do that. So, your guarantee means what? Will you personally pay for damages to user's PCs? Will you pay for the IT departments cost at rebuilding/removing spyware, viruses, etc? If you are going to make such a guarantee back it up, like most guarantees...You see it is pretty easy to make such a statement when you have no direct possibilities caused by the repercussions of such foolish statements. That's a really stupid argument and shows a total lack of understanding of computer security. Security is risk management. First you assess risks, and then either you accept a risk, or you mitigate a risk. I assessed the risk, and backed up my assessment by noting the two next largest IE vulns to hit the media. Asking me to put out a monetary guarantee before you'll accept the validity of my argument, with past examples, is just dumb. No. What is dumb is making a guarantee that you *can't* back up. It is both dumb and irresponsible... And if you *really* knew computer security you would understand that risk management is highly dependant on one's computer systems and the business that runs on them. What you might call acceptable risk might not be for someone else....now, not realizing that *is* dumb.... Suffice it to say that past IE vulns have always been widely overrated. BS Propaganda! I guess their are no problems with spyware on Microsoft platforms either? Hahahahaha You're constantly coming here and saying that the sky is about to fall in, and it never does. You're backing up your baseless panic with "what if" and "it could happen" statements. Security and risk assessment just don't work that way, and for good reason. On the contrary. I am saying that Microsoft has failed and is failing at securing their systems (unless it is DRM related). Furthermore, Microsoft's overall security seems to be getting worse. I bet the organization where you work has accepted the risk of this vulnerability, and is doing little to nothing, at least on the client side, to lessen the risk. That's a very common real world posture to these IE vulns. First, luckily we have not had a Microsoft server in years. The only remaining Microsoft PCs are a couple of people who have not been converted to Apple yet. The desktop guys went around and issued the temp fix, that was listed on their site. My company deals with large sums of money and security is paramount. Then how do you explain the record breaking time to patch Microsoft's DRM hole? Three days to patch? Please explain (no propaganda necessary). I already did. No you did not. You, or some else here, tried to use the excuse of patch management (QA proceedsure and steps). True QA is an important step. However, the DRM patch *ALSO* went through the same procedures and was out in 3 days. Please explain that...(this has been the unanswered question) Without propaganda? That's what I should be demanding of you. A good example of propaganda is when you said that Microsoft bases its patching policy on laziness, greed and/or incompetence. Nice try. Please answer my question above. Imhotep |
#36
|
|||
|
|||
Microsoft Zero Day security holes being exploited
Smitty wrote:
I have to agree with Imhotep. I have been thoroughly p****ed off this week as a result of a virus which somehow evaded the countless security systems I have in place. In retrospect, the 'vulnerability' is simply MS stupidity. Imagine allowing WinLogon to to load arbitrary DLLs into its address space simply by adding entries into the registry. WinLogon is supposed to be my first line of defense against security issues. What are they thinking ? About money, obviously ! Possibly, but Microsoft is not the big evil cooperation that users associate it to be. Microsoft does have some problems that are common in a big company but they do try. For example, they had the security cd for free that has been very help in countless 98SE machines that I service. |
#37
|
|||
|
|||
Microsoft Zero Day security holes being exploited
snip
It is interesting that the NT (New Technology) source code was originally nicknamed the "Not There" source code since it did not have a true maintenance operating system like the 9x had. Chris Quirke, MVP can post more information on this because he knows about it extensively. 9x had DOS which was really nice because you could get down and dirty and solve many problems with commands and it overcame the limitations of fixing things that are inherent in GUI (Graphical User Interface). I researched and read about this in a book about Microsoft's early history. The actual base of 9x has a more secure and solid foundation than NT. Check this out for further information: http://secunia.com/product/22/?task=advisories (XP Pro. -- critical extreme vulnerability) http://secunia.com/product/16/?task=advisories (XP Home -- critical extreme vulnerability) http://secunia.com/product/1/?task=advisories (2000 Professional -- critical extreme vulnerability) http://secunia.com/product/13/?task=advisories (98 Second Edition -- only 3 less critical vulnerabilities) Well, you people get the idea and all the garbage about XP being so secure is just plain foolishness if people would just remove the blinders from their eyes and see the truth then we would be getting somewhere. BTW, I tri-boot with 98SE, XP Pro. and am testing Windows Vista Ultimate 32 bit with glass "Aero" interface enabled. |
#38
|
|||
|
|||
Microsoft Zero Day security holes being exploited
"imhotep" wrote in message
... Roger Abell [MVP] wrote: "imhotep" wrote in message ... Roger Abell [MVP] wrote: regsvr32 -u "%ProgramFiles%\Common Files\Microsoft Shared\VGX\vgx.dll" which is the first workaround mentioned in the MS advisory, may fail in some locales. As Jesper (and others) have indicated, it should use %CommonProgramFiles% http://msinfluentials.com/blogs/jesp...-a-domain.aspx http://tinyurl.com/mtcbd quote Update Sept. 21, 2006 Uploaded a new version of the archive that uses %CommonProgramFiles% instead of %ProgramFiles%\Common Files to specify the file location. This helps make it work on non-English systems that have translated the name of the Common Files directory. /quote Those interested should see his Friday's blog that not only discusses the third-party patch route, but also outlines another approach to the current (and the Direct Animation control's path) vulnerabiltiy http://msinfluentials.com/blogs/jesp...-a-domain.aspx http://tinyurl.com/h3buq I will pass this along to the helpdesk guys. Thanks. Any ETA about the patch/fix from Microsoft? No, and I have not seen a reason to ask. Surely the critically merits promptness. Does it not? Contrarily, surely it is the scope of disruption to installed base, or potential thereof, that merits thoroughness and correctness. Does it not? See. Yet another game of trade-offs. MS took the unusually step of detailing workarounds that crippled functionality in their initial advirory. That was no doubt in response to analysis showing code availability, exploit character, and extent of testing that would be needed (i.e. time to delivery). From that I fully trust resources were marshalled in appropriate scale. Typically the owning group of the involved code finishes its work, which includes review for similar/related flaws, quite quickly. For something like this, that could have impacts on non-MS code, the test cycle is where the time gets consumed (read: not all testing is in-house). (You trapped me with that dumb follow-up once more !!) Asking if you knew of a ETA? Sorry, but I thought you actually might know. If I knew I could not say, something true for all that might. No trapping this time.... I would call you a liar, were it not so obvious you did not understand "follow-up" did mean follow-up, as set on your post, which is again to only the ie.sec NG |
#39
|
|||
|
|||
Microsoft Zero Day security holes being exploited
On Sun, 24 Sep 2006 02:45:01 -0700, Ian
Think we'll only achieve secure computing when C is dropped in favour of a better language. The list of buffer-overflow exploits in every single major software-package gets monotonous. Yes, that makes a lot of sense. As C tends to be used across all platforms (UNIX, Linux, MacOS, Microsoft) it's unsurprising that all of these platforms share the same sort of exploits and code repairs. It's a lot like the Y2k problem, i.e. trade-offs made in the interests of performance on the slower hardware of the time. We now waste processing power on eye candy (animated menus, Glass in Vista, etc.) and underfootware (indexing, thumbnailers, .PF and SR management). Plus, the risks from bad code often mean thatr the real code is preceded by several layers of "is this safe?" content testing, from av to code that checks for "shapes" that will exploit the real code to full-blown emulation of the real code in an attempt to "sandbox" it. One's tempted to say it would be more efficient to simply use a less "powerful" language that doesn't use pointers and data-driven buffer operations instead. The challenge is that much of the code logic only works because the need to know how big material is, relative to the buffer space, isn't needed to code it. That's unsafe, but to fix this is more than just a matter of changing the source code language. Wherever there's a dynamic buffer that's having ad-hoc material added to it, it may be difficult to track remaining buffer size and incoming data size. One way is to truncate data to fit, but that can create a different sort of exploitability, where this can match the wrong (malicious) object when truncated. Pointers are another story... it's hard to re-write code that relies on pointers to work in some other way. Object Orientated Programming may mix code and data within multiple small objects, thus creating opportunities for code to overwrite (or point into) data areas that would have been avoided if the older code segment, data segment model was used instead. Finally, what really blows the doors off safety is the irresistable urge to "make everything work". It's so cheap in terms of programming effort to massively extend functionality by passing logic outwards into additional content and syntax parsers, such as programming languages that include some sort of SystemAPI( ) calls - but this is where the original intention of the code is trumped by unintended possibilities that can be exploited. This is very similar to the Internet, where any IP that can't be found locally is sought through the next in a chain of gateways. We love the Internet, though we wish coders wouldn't treat it as one big network just because it's made out of networking. We have less love for sprawling extended interpreters that allow any content to be activated from any kind of visible wrapper. ------------ ----- --- -- - - - - Drugs are usually safe. Inject? (Y/n) ------------ ----- --- -- - - - - |
#40
|
|||
|
|||
Microsoft Zero Day security holes being exploited
On Sun, 24 Sep 2006 16:06:41 -0400, imhotep
Karl Levinson, mvp wrote: "imhotep" wrote in message It really make my blood boil knowing that they patched the DRM security hole in a couple of days, yet I am sure by the time this patch comes out a crap load of people will get infected... I assure you, a crap load of people will NOT be infected by this or any other IE vuln in the future. IE vulns just don't do that. cough See http://cquirke.mvps.org/9x/mimehole.htm, Google( BadTrans B ) That's a very old bug, long fixed unless you "just" re-installed any OS predating XP, as every such OS uses an IE that is both exploitable and too "old" to be patched other than by upgrading the whole of IE. If you read up that bug, you'd see how the nature of exploits and code bugs have changed. The MIME hole was a design safety failure, not a code defect - IOW, it "worked as designed" but the design was brain-dead. There's still design failures in Windows, and until these are proven to be exploitable, they won't be patched because "it's working the way we expected it to". Most exploits that are being patched today are genuine code defects, and may be harder to exploit. Then again, the modern malware industry is optimised to overcome any "an attacker would have to..." mitigations. Once an exploit shape is found, the source code becomes rapidly available, and malware coders then drop it straight into attack vehicles that are ready to roll; either full-fledged multi-function bots, or simple stubs that can pull down the "real" malware. If these malware haven't been released before, av won't "know" them at the signature level. Malware can always out-turn patching. The attacks are smaller than the patches and can drown out the patching process by sheer volume, even before you consider DDoSing the fewer number of patching sources or poisoning the patch pool via fake patching sources. The other reason malware will always win the race is that the required software standards are far lower. A malware has to work on some PCs, and it doesn't matter if it trashes others. But a patch has to work on all systerms, and not cause new problems of any of them. If you insist on butting heads with malware on a level playing field, you will always lose. Better to tilt the playing field so that the user at the keyboard has the ability to trump all code and remote access - but MS's fixation on centrally-managed IT and DRM undermines this and rots the top of the Trust Stack. See http://cquirke.blogspot.com/2006/08/trust-stack.html Then how do you explain the record breaking time to patch Microsoft's DRM hole? Three days to patch? Please explain (no propaganda necessary). Well, it could be that the nature of the hole was trivial to fix - e.g. simply changing some static "secret" info that became harvested and used by the attackers. I suspect this is the case, given how quickly the fix has been circumvented by the attackers. We have a very small sample from which to draw conclusions. Sure, we have a lot of defects that allow user interests to be attacked, and we have a smaller number where users were left hanging out to try while patching caught up with ITW exploits. But we have a sample of 1 prompt DRM fix, and it may just happen to have been an easy one to fix; maybe the next one (or even the continuation of this one) will take a far longer time to fix. If so, don't expect to read about it! So... are you saying that all fixes should be held back the same amount of time, even if they are ready earlier, so that MS can be seen to act more promptly on the issues we'd most like to see fixed first? BTW, the post I'm replying to has a ?bug of its own; the sole newsgroup set for replies is not found to exist on my news server. Maybe it exists on other news servers, who knows? Here, it's 100% broken and buggy. Should I wave this around as "proof" that the poster I'm replying to is trying to hide refutations to his post? ------------ ----- --- -- - - - - Drugs are usually safe. Inject? (Y/n) ------------ ----- --- -- - - - - |
#41
|
|||
|
|||
Microsoft Zero Day security holes being exploited
"Smitty" wrote in message ... I have to agree with Imhotep. I have been thoroughly p****ed off this week as a result of a virus which somehow evaded the countless security systems I have in place. In retrospect, the 'vulnerability' is simply MS stupidity. Imagine allowing WinLogon to to load arbitrary DLLs into its address space simply by adding entries into the registry. WinLogon is supposed to be my first line of defense against security issues. All operating systems do that. They are designed to launch code at boot time by reading registry values, text files, etc. Because those registry values are protected from unauthorized access by permissions, someone would have to already own your system to modify those values, wouldn't they? |
#42
|
|||
|
|||
Microsoft Zero Day security holes being exploited
Check your update processes (MU, WSUS sync.)
but note that your channels may still be staging out. http://www.microsoft.com/technet/sec.../MS06-055.mspx -- Roger Abell Microsoft MVP (Windows Server : Security) MCDBA, MCSE W2k3+W2k+Nt4 "imhotep" wrote in message ... Microsoft Zero Day security holes being exploited "Microsoft has issued warnings about a serious flaw in Internet Explorer that allows attackers to hijack a PC via the popular browser Researcher Adam Thomas uncovered the exploit which revolves around the way that the Internet Explorer browser handles a particular form of graphics known as vector graphics. A properly crafted webpage can exploit this problem and install almost anything they want on the target machine. Unusable PC Tests by Sunbelt Software on a Windows machine patched with all the latest security updates showed attackers installing a huge amount of spyware and other malicious programs." http://news.bbc.co.uk/2/hi/technology/5365296.stm Imhotep |
#43
|
|||
|
|||
Microsoft Zero Day security holes being exploited
On Mon, 25 Sep 2006 05:45:39 +0100, "Stephen Howe"
"Ian" wrote in message And note, I don't regard C as inheritently unsafe - it is just it requires programmer discipline. Humans are just system components, along with everything else - and as such, they have notoriously high error rates. When designing languages, that should be taken into account. With C, it wasn't - the mindset was that programmers are smart enough not to need training wheels, and the beauty of C was that it stayed out of your way so you had full control (and full responsibility). And we can see how well human programmers have filled those shoes... ------------ ----- --- -- - - - - Drugs are usually safe. Inject? (Y/n) ------------ ----- --- -- - - - - |
#44
|
|||
|
|||
Microsoft Zero Day security holes being exploited
"Stephen Howe" sjhoweATdialDOTpipexDOTcom wrote in message
... PS. can you not control your newreader and its use of followups? Why can't you prune the conversation to what is relevant? Too difficult for you? Must you quote everything? Stephen Howe Point taken. I also sometimes get lost in the "what is most relevant?" when considering the fractured view today's search engines yield with currently primative (ill thread xref'd) hits. -- ra |
#45
|
|||
|
|||
Microsoft Zero Day security holes being exploited
Roger Abell [MVP] wrote:
"imhotep" wrote in message ... Roger Abell [MVP] wrote: "imhotep" wrote in message ... Roger Abell [MVP] wrote: regsvr32 -u "%ProgramFiles%\Common Files\Microsoft Shared\VGX\vgx.dll" which is the first workaround mentioned in the MS advisory, may fail in some locales. As Jesper (and others) have indicated, it should use %CommonProgramFiles% http://msinfluentials.com/blogs/jesp...-a-domain.aspx http://tinyurl.com/mtcbd quote Update Sept. 21, 2006 Uploaded a new version of the archive that uses %CommonProgramFiles% instead of %ProgramFiles%\Common Files to specify the file location. This helps make it work on non-English systems that have translated the name of the Common Files directory. /quote Those interested should see his Friday's blog that not only discusses the third-party patch route, but also outlines another approach to the current (and the Direct Animation control's path) vulnerabiltiy http://msinfluentials.com/blogs/jesp...-a-domain.aspx http://tinyurl.com/h3buq I will pass this along to the helpdesk guys. Thanks. Any ETA about the patch/fix from Microsoft? No, and I have not seen a reason to ask. Surely the critically merits promptness. Does it not? Contrarily, surely it is the scope of disruption to installed base, or potential thereof, that merits thoroughness and correctness. Does it not? An how does one predict what tomorrow brings? Crystal ball? Surely one can not. This is why is much better rate to the security hole based on the critically rather than popularity...CRITICALITY DOES NOT CHANGE POPULARITY DOES!!! See. Yet another game of trade-offs. I do not see a trade off here. Honestly, I do see mistakes in how some people try to evaluate security holes thus resulting in making things worse... MS took the unusually step of detailing workarounds that crippled functionality in their initial advirory. That was no doubt in response to analysis showing code availability, exploit character, and extent of testing that would be needed (i.e. time to delivery). From that I fully trust resources were marshalled in appropriate scale. Typically the owning group of the involved code finishes its work, which includes review for similar/related flaws, quite quickly. For something like this, that could have impacts on non-MS code, the test cycle is where the time gets consumed (read: not all testing is in-house). (You trapped me with that dumb follow-up once more !!) Asking if you knew of a ETA? Sorry, but I thought you actually might know. If I knew I could not say, something true for all that might. No trapping this time.... I would call you a liar, were it not so obvious you did not understand "follow-up" did mean follow-up, as set on your post, which is again to only the ie.sec NG |
Thread Tools | |
Display Modes | |
|
|