So, I’ve come across a lot more information regarding the no-longer-0day Adobe vulnerability (oh, wait, that’s right.. there have been like, 12 in the last 30 days.. I’m referring just to the SING table one).

Anyway, a penetration testing company named Ramz Afzar has released an unofficial patch to fix the Adobe vulnerability, because apparently Adobe has had a difficult time figuring one out on their own.

After reading their analysis of the vulnerable code, this jumped out at me the most:

After initial analysis we’ve discovered that exploit exists in insecure strcat call located in CoolType.dll:
(all addresses and names are from Latest Acrobat 9.3.4′s CoolType.dll)

0803DDAB E8 483D1300 CALL JMP.&MSVCR80.strcat

So, what does ‘strcat’ do, exactly? It basically appends a copy of the source string to the destination string. Example:

main () {
  char adobe_rulez[20];
  strcpy (adobe_rulez,"our ");
  strcat (adobe_rulez,"software ");
  strcat (adobe_rulez,"pwnz! ");
}

Pretty self explanatory. HOWEVER. What DOESN’T ‘strcat’ (or any of the other strc* functions, for that matter) do? Bounds checking! This is a classic overflow due to idiotic programming practices. Really, Adobe? The 15 years of hounding from security researchers haven’t been enough for you to ingrain it into your programmers that the use of strc* will get them fired, or lynched, or burned at the stake? Beyond that, your entire testing/debugging department missed this as well?

Heres’ what they SHOULD be doing:

#define MAXLEN(s) ( sizeof(s)/sizeof(s[0]) - 1 )
 
char buf[20];
 
void write( char data[], int n ) {
   strncat( buf, data, __min( n, MAXLEN(buf)-strlen(buf)) );
}
 
main() {
   strcat(buf, "now it looks like ");
   write("we know what we're doing");
}

Note: The above code is just an example – I don’t even know if it will compile or not. The idea is simple, though. You define the size of a buffer and you want to ensure that the data going in to that buffer doesn’t exceed the size of the buffer. What a concept. Bounds checking is nothing new, so there are plenty of resources out there to educate those who are unfamiliar with it. But, if you’re getting paid big bucks as a programmer for a company, you should know what the hell you’re doing. Sorry, that’s just my personal opinion. *cough*.

Anyway, So, first they’re writing code using functions that have been known to be vulnerable to exploitation for about 15 years and second, they’re now being shown up by little companies who are writing patches to fix the holes that they’re not. And apparently Adobe thinks it’s okay for this vulnerability to be left unpatched until the 4th of October?? Are you kidding me??

I caught some grief when I wrote the Open Letter to Microsoft post about how it’s difficult to write code in a team setting and that it’s difficult for large companies to meet deadlines and whatnot, but honestly, how do you argue with this?

And, whats more, is that a company that does not have access to the source code of the DLL was able to fix the issue, yet the company responsible for the software is not/wont/doesn’t care/can’t find a way to patch it on an expedited schedule? Seriously, this October 4th date is really feels like a, “Eh, we don’t mind that all of our customers are vulnerable to exploitation and corporate espionage.. we’ll patch it when we get around to it” kind of date.

Whats more, is that Adobe has apparently released a statement telling people to not install 3rd party patches or from “untrusted” publishers. So, instead, just remain vulnerable until we get off our ass and do something about it.

Tell you what, Adobe, if you can’t figure out how to simply add some bounds checking to a routine and release a patch, I think maybe you are the “untrusted publisher”.

So, here are your options:

1) Uninstall Adobe (highly recommended. Once this vulnerability is patched, there will be 6 more released, I’m sure – here’s a list of all the vulnerabilities and associated exploits against Adobe products. Look at how many came out in the past 60 days (granted, a chunk of them are DLL hijacking, but even ignoring those ones…)) Some options to replace Adobe include:
A) Install the Google Docs plugin and read your PDF’s from within Google Docs (this is what I do)
B) Install one of the many other software packages out there:
* Evince
* Foxit (Foxit is often vulnerable to the same issues as Adobe, though, so be a bit weary of this one)
* Okular
* GSView
* Xpdf
* NitroPDF
* SumatraPDF
* Please note that I haven’t used all of these, so if you have any input on them, please comment below
2) Install this patch
3) Or wait around for Adobe to do something about it, meanwhile leaving you vulnerable to attack. Though, I’m sure there’s nothing important on your computer that you wouldn’t mind being stolen, right?

Sorry about this rant, I’m just getting tired of these companies writing absolutely terrible code, laughing at us as they head off to the bank with our money and then not taking it seriously when they get flooded with vulnerability discoveries. I’m looking forward to the day when some big company gets pwned due to a vulnerability in a piece of software that a publisher has had ample time to patch and then gets sued for damages. That’s when the face of internet security will change, because I guarantee that if you assign a price tag to apathy, we will begin to see same-day patches.

Oh, wait, we do already see that.. with Linux. *plug*.

Related posts:

1. New Adobe 0day Demonstration
2. New DLL Hijacking Exploits (many!)
3. DLLHijackAuditKit v2
4. Backdoor Password in Accton Based Switches
5. An Open Letter to Microsoft