Last Updated: 2006-08-16 16:21:09 UTC
by Kyle Haugsness (Version: 2)
Of course, Litchfield has found lots of vulnerabilities and reported them to IBM in January 2005 and now patches are released in August 2006.
Please note that I'm not trying to make a political statement about IBM. There are plenty of other vendors with similar types of problems still lurking about. Instead, I am merely highlighting the research of Litchfield and posing some thoughts for our readers. I will do my best to leave my opinion unstated, so that you can draw your own conclusions.
Here is what I find interesting about the vulnerabilities that Litchfield found:
1) There is a basic stack overflow in the username parameter when you authenticate to the database. You can't get any more easy than this. The bug exists on all versions of Informix on all operating systems. This reminds me that "Smashing the Stack for Fun And Profit" by Aleph1 is almost 10 years old now.
2) An attacker doesn't need to authenticate to determine the remote operating system. The installation path is given in the error message for an authentication failure. This is very useful for exploiting #1.
3) After authentication, there are numerous buffer overflows available that allow for code execution and privilege escalation. These are vanilla buffer overflow scenarios that are easy to exploit.
4) In the event of a crash, Informix will dump username and password information to files that are world readable in /tmp. This makes it convenient for an unprivileged bad guy with local access to get usernames and password for admin or privileged users.
5) Any authenticated user has the ability to create a new database, which gives that user DBA privileges on the database. So once you do this, you own the whole server. This is a major architectural flaw.
6) Normal users can run arbitrary OS commands using the SYSTEM SQL command. There are numerous paths to get commands and user-specified DLLs executed as the privileged Informix account.
7) Finally, there are stack overflows still available in environment variables used by SUID command-line binaries.
Here is a link to the research paper by Litchfield: http://www.databasesecurity.com/informix/DatabaseHackersHandbook-AttackingInformix.pdf
So given the facts above, are you asking the right questions of your vendors? How certain are you that your favorite software vendor is writing secure code? Do you have the ability to change software packages if you find that a product has been found to have basic programming errors? And can your organization afford to let known holes live unpatched for 1.5 years?