MS06-042 and IE 6.0 SP1 issues
Looks like the recent Microsoft patch (MS06-042) , which is a cumulative Security Update for Internet Explorer is affecting some IE 6.0 SP1 users. So, if you are a IE 6.0 SP1 user, you may be affected by this issue when "visiting a website that use HTTP 1.1 and compression"
MS updated the advisory to contain this information and plan to re-release the patch by August 22, for those users only.
You may ask how many users can be affected by this. I really dont know, but I suspect that the number is not high (but I can be completely wrong). The reason is that HTTP 1.1 compression is not (or at least wasn't ) enable by default on both IIS and Apache web servers, the most used webservers.
If you are one of those users, please let me know if you are seeing this issues.
---------------------------------------------------------------------------------------------
Handler on Duty: Pedro Bueno ( pbueno //&&// isc .sans. org )
MS updated the advisory to contain this information and plan to re-release the patch by August 22, for those users only.
You may ask how many users can be affected by this. I really dont know, but I suspect that the number is not high (but I can be completely wrong). The reason is that HTTP 1.1 compression is not (or at least wasn't ) enable by default on both IIS and Apache web servers, the most used webservers.
If you are one of those users, please let me know if you are seeing this issues.
---------------------------------------------------------------------------------------------
Handler on Duty: Pedro Bueno ( pbueno //&&// isc .sans. org )
Keywords:
0 comment(s)
Thoughts about Informix
With most of the world scrambling to patch against MS06-040, there was an interesting release from David Litchfield yesterday about Informix. Litchfield is one of the best vulnerability researchers in the world and he's been spending the last several years on database platforms. Looks like he has been playing with Informix, which is a commercial product purchased by IBM in 2001. The wikipedia article has the complete history of Informix, if you are interested.
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?
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?
Keywords:
0 comment(s)
Tip of the Day: Secure Surfing at the Coffee Shop (or Hacker Conferences)
Update 1: Many of you pointed out that you can use the built-in SOCKS proxy in SSHD to make this tip easier. Indeed, this is true. However, you can do some cool anonymity hacks within Squid that make your surfing a little more anonymous if you are so inclined. For those that like simplicity and aren't worried about anonymity, don't worry about setting up the Squid proxy software, SSHD will do everything for you. Use the command "ssh -D 3128 <user@IP>" and in your web browser, configure the SOCKS proxy option to be 127.0.0.1 and port 3128.
Update 2: Something I failed to realize is that most recent browsers will also send your outbound DNS request through the SSH tunnel, which means #6 below is only true when using the SOCKS option. So that is another reason to use Squid if you are concerned about privacy or being re-directed by malicious DNS servers on the wireless LAN. DNS privacy worked when using Squid from clients on Linux (Firefox) and Windows (Firefox and IE). If you know of a browser that doesn't do this, let us know.
This tip is how to use SSH port forwarding to browse the web at your favorite coffee shop (or hacker conference).
1) Setup a machine on your home network. If you don't have a static IP address, then use dynamic DNS.
2) On this machine setup squid (http://www.squid-cache.org/) and bind it only to localhost. Do this with the "http_port 127.0.0.1:3128" line in squid.conf. This will prevent others on the Internet from abusing your open proxy.
3) Setup SSHD on this machine. And do yourself a favor, require SSH key authentication and run SSHD on a port that is NOT 22. This will keep all those brute force SSH grinders from filling your log files.
4) At the coffee shop, do ssh -p <sshd_port> -L3128:127.0.0.1:3128 <user@IP>. This will setup your SSH tunnel.
5) The most critical piece is to configure your web browser to use a proxy. Host: 127.0.0.1; port 3128
6) Surf away. All your web surfing will be encrypted to your home box before travelling to the Internet. Be advised that your outbound DNS requests are still sent to the local network unencrypted. But you have at least prevented snooping and/or modification on the HTTP(S) traffic.
You can forward almost any standard TCP application though an SSH tunnel and OpenSSH has recently introduced lightweight VPN features. But that's a topic for another day.
Update 2: Something I failed to realize is that most recent browsers will also send your outbound DNS request through the SSH tunnel, which means #6 below is only true when using the SOCKS option. So that is another reason to use Squid if you are concerned about privacy or being re-directed by malicious DNS servers on the wireless LAN. DNS privacy worked when using Squid from clients on Linux (Firefox) and Windows (Firefox and IE). If you know of a browser that doesn't do this, let us know.
This tip is how to use SSH port forwarding to browse the web at your favorite coffee shop (or hacker conference).
1) Setup a machine on your home network. If you don't have a static IP address, then use dynamic DNS.
2) On this machine setup squid (http://www.squid-cache.org/) and bind it only to localhost. Do this with the "http_port 127.0.0.1:3128" line in squid.conf. This will prevent others on the Internet from abusing your open proxy.
3) Setup SSHD on this machine. And do yourself a favor, require SSH key authentication and run SSHD on a port that is NOT 22. This will keep all those brute force SSH grinders from filling your log files.
4) At the coffee shop, do ssh -p <sshd_port> -L3128:127.0.0.1:3128 <user@IP>. This will setup your SSH tunnel.
5) The most critical piece is to configure your web browser to use a proxy. Host: 127.0.0.1; port 3128
6) Surf away. All your web surfing will be encrypted to your home box before travelling to the Internet. Be advised that your outbound DNS requests are still sent to the local network unencrypted. But you have at least prevented snooping and/or modification on the HTTP(S) traffic.
You can forward almost any standard TCP application though an SSH tunnel and OpenSSH has recently introduced lightweight VPN features. But that's a topic for another day.
Keywords: ToD
0 comment(s)
×
![modal content]()
Diary Archives
Comments