Slashdot Mirror
Microsoft Sits on Security Flaw for Six Months
pmf writes "Yet another critical vulnerability affecting Windows 2000/XP/2003 has been just announced by eEye. It is worthy to note, that it took Microsoft over 6 months to fix it. The bug affects ASN.1 library and is remotely exploitable through authentication subsystems (Kerberos, NTLMv2) and applications that make use of SSL certificates." The AP has an overview.
http://www.eeye.com/html/Research/Upcoming/index.h tml
Fox News Channel reported that there was a serious flaw in Windows during their 4pm ET news burst. Mainstream media as usual leaves out tech details on stories like these, but this is just an indication of how serious this flaw is.
eeye.com
Accoring to the article, code could be injected using character string and OID's that get copied without regard to length. All you would need to do is get the right stuff copied to the right place.
No sig, sorry.
Both OpenSSH and OpenSSL (what you really meant) are available under BSD licenses. Microsoft hasn't said anything bad about BSD-licensed software and has admitted to using it for years.
Dewey, what part of this looks like authorities should be involved?
According to the MS website it appears to have been introduced into 2000 as part of a service pack update (Starting with SP2), and starting with XP Service Pack 1. See KB article: 828028
And, of course, it doesn't affect Windows 98 at all...
That is correct, during the compile, the memory markers (addresses) are created. These are of course, virtual addresses, like you said, all process have their own address space. In terms of real storage (what's actually in the RAM), that would be different every time the application is run, but it makes no difference as the DAT handles the instructions (I think it's a DAT in windows anyways..)
Mod +5 Drunk
Yep, it appears to be the same font.
A bit of googling reveals that the font contains a symbol which is a swastika. Not the reversed Nazi Swastika, but the way round that it was used for thousands of years by Buddhists as a symbol of Buddha's heart and mind. It is still a commonly used symbol in the far east.
As for point 2. Who knows???
Actually it was used by many people including Buddists, but it is now widely believed that it was a Jewish symbol, that was taken from a twist on an acient Sun God. http://www.manwoman.net/swastika/swastika.html "There are even Jewish swastikas found in ancient synagogues side-by-side with the star of David!"
Mod +5 Drunk
I'm a CFO with a small leasing company, and as I also wear the designated IT helper hat from time to time when our contract specialist isn't on site.
I just spent the better part of the afternoon, wasting my time, and a salesperson's time as we first ran Adaware and then Sybot S&D, rebooting again and again, to try to deal with a piece of misfunctioning software
I spend more critical hours of a day dealing with stupid MS software problems! I truly, truly hate this. Its one thing to run MS at home where I can play with tweaking, patching, reparing MS so that I can play the occassional game, but this is work.
I'm waiting for a linux desktop system that will allow us to communicate with our customers (ie. MS Word, Xcel) and run Act! and T-value 5. Unfortuantely I can't afford to spend time experimenting or becoming a guinea pig, either.
The TCO on these MS systems are killing ... and I can't wait till it ends!
In our era and in our culture, the swastika is associated with Hitler and his Nazi party. However, the swastika did not originate with Hitler. It originated in India, and has been considered a mystic/spiritual symbol in Asia for thousands of years. So although it has very negative connotations in western cultures, it probably finds a lot of positive usage in eastern cultures. Swastikas are often publically displayed in India on temples and so forth.
Here's an interesting page discussing the origins of the swastika.
But according to eEye it affects all versions of NT, 2000 prior to SP3, and 98. Is eEye wrong or is Microsoft lying?
Developers: We can use your help.
"In the security bulletin published by MS it states,
"In the most likely exploitable scenario, an attackerwould have to have direct access to the user's network."
The bulletin published by eEye states
"...applications that make use of certificates (SSL, digitally-signed e-mail, signed ActiveX controls, etc.) [areaffected]".
I see a big disconnect there. Can you address this? Also, how would this potentially affect sites that are using an MS VPN solution?"
Yes, I am not sure what Microsoft did with the wording there that seems to be misleading to at least a few people so far.
There is just as much, if not more, chance of people using this vulnerability on server side applications as there is on client-side applications.
For example we setup a totally IPSEC secured network and we broke into that network via our ASN bug which is called by the Kerberos.
We also have written exploits that take advantage of ASN via NTLMv2 authentication. And the list goes on... How about evil ASN SSL CERTs?
Client or server? There is a menu a mile long for the avenues of attacks that this thing can be used for.
If your running, Windows NT 4.0, Windows 2000, Windows XP, or Windows 2003, you are 99.9999% positive to be vulnerable, regardless of what your configuration might be.
Don't try to guess if you have any of the affected protocols or applications (lets not forget third party apps using the MS ASN library), just install the patch.
Client side, server side, world wide.
Signed, Marc Maiffret Chief Hacking Officer eEye Digital Security
Time flies like an arrow, fruit flies like a banana.
It's not so much the location of the overflowed buffer that's the problem, it's the location of the GOT (or IAT on Win32) that matters, as that allows you to call any function imported by that binary. On Windows PE binaries usually have their relocation records stripped so they always load at 0x400000, making the IAT easy to access by an absolute jump. On Linux the situation is mostly the same, albiet with a different address, unless you are using Fedora Core 1 in which case exec-shield with PIE binaries are used to give binaries randomized load addresses. One of the reasons it's called exec-shield is because it helps reduce the problems of buffer overflows - at least it makes it harder to run useful code (you can still crash the app of course).
Why? Because ASN.1 is the Mos Eisley of bit-twiddly protocols, and "you'll never find a more wretched hive of scum and villainy." AFAIK, there's nothing insecure about the protocol itself, but it's so ugly that everybody tends to reuse the reference implementation rather than rewriting their own. While that has some good aspects to it, some of the original reference implementation code wasn't always careful about checking bounds, etc., and eventually the University of Oulu folks did a proper study and found the holes.
ASN.1 is one of these broad-scope protocols that tries to be everything to everybody, so it not only implements in a broad messy manner some things that were done much more simply and cleanly and debuggably in XDR, it also does some other things that are useful in a top-down hierarchical world controlled by all-knowing standards committees, and got itself included at the appropriate layers in other standards such as X.509 and H.323 (which are also big and ugly), and in SNMP (which is otherwise simple and clean and should have known better), and X.509 got itself embedded into SSL. (H.323 is the older VOIP standard, used by almost everybody even though they talk about using SIP Real Soon Now, and Microsoft Netmeeting is the popular free implementation.) One bad side of this is that very many security-critical applications have this buggy code at the bottom of them, though this is somewhat balanced by the good fact that it's so deeply buried that it's often hard to pass malicious data that far down the stack, though of course there's the ugly side which is that it's so ugly that it's hard for an interface module to verify that an ASN.1 object is malformed except by actually passing it to the vulnerable ASN.1 interpreter.
Bit-twiddly space-saving data formats are almost always a Bad Idea. As they say, people who play with the bits deserve to be bitten. ASN.1 problems make many applications hard to write and harder to debug, but in the Open Source world, PGP has gone through several iterations of security-critical bugs because they were trying to steal bits, plus backwards compatibility issues make stealth versions difficult. The theory is that it's somehow more "efficient" to save a few bits of data storage or data transmission time by using variable-length formats, trading off the space for more CPU time and program space. This isn't totally off the wall, given 20 years of Moore's Law (which seems to have improved CPU and RAM price/performance by 10**5 - 10**6, disk by about 10**5, but smaller bandwidths by only 10**3-10**4), but the cost in programmer time, debugging time, and bug impact has been immense.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
"Slackware (well, its alive, but barely)"
New release in September, previous release only 6 months prior to that, a changelog in current at the ftp site that shows continuous update including 11 new/updated packages in the last 4 days ?
Explain to me in what way you think this is "barely" alive ?
Unlike the MS Blaster bug, which had basically one exploit and one fix (the RPC service on TCP port 135), the ASN.1 protocols are used in a dozen services that are listening on TCP/UDP ports all over the place. Servers will be especially vulnerable to this.
If you hack Active Directory you own not just the computer but the whole dang enterprise.
Gads this will be a nightmare to deal with.
All you have found is that your box has OpenSSL for windows installed. AFAIK, ssleay32.dll not distributed by Microsoft, it's built from the OpenSLL source.
Can you even name that worm, I wonder?
I believe you're refering to the 'Morris Worm', released in November 1988. According to Wikkipedia, the GAO estimates the damages were between $10M and $100M US dollars.