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
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???
"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.
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 ?