Google claims that its browser Google Chrome is able to isolate events that may crash a browser, isolated within those individual tabs. However, an issue exists with how Google Chrome handles undefined handlers in chrome.dll version 0.2.149.27 which is the latest version of the browser. A crash can result without any user interaction.

When a user visits a malicious link which has an undefined handler and followed by a special character, the browser crashes. You can also crash the browser by typing the characters :% in the Chrome URL bar. Google Chrome crashes with a message ” Whoa! Google Chrome has crashed. Restart now?”

Tested on : Windows Vista SP1, Windows XP SP2, Windows XP SP3

Howto: Type :% in the Google Chrome URL bar

Google Chrome crashes with all Tabs

Proof of Concept:

Note: Do not hover over the link below if you are currently using Google Chrome and running something critical. Google Chrome actively links to any URL in any page. So, you don’t even have to click on the link below for Google Chrome to crash. A mere hover will do.

PoC Working exploit to crash Google Chrome:
Click for a demo HERE

According to SecuriTeam, it crashes on “int3″ at 0x01002FF3 as an exception/trap, followed by “POP EBP” instruction when pointed out by the EIP register at 0x01002FF4

UPDATE (9/7/2008): Google has patched this vulnerability in Chrome. They released an update to the browser. Please make sure you update your current version to 0.2.149.29

The TIBCO Rendezvous RVD daemon is vulnerable to a memory leak, which when remotely triggered, prevents any further RV communication until the daemon is manually restarted.

Vulnerability Type / Importance: Remote DoS / High
Workaround: There are no known workarounds for this vulnerability

The RV daemon (RVD) within TIBCO’s Rendezvous messaging product is responsible for the communication of messages between RV-enabled applications. The vulnerability exists as the result of an error in the code that parses information within one of the headers in a TIBCO proprietary network protocol packet.
Technical Details:
Within a Rendezvous “wire format” TCP packet, the first four bytes represent the number of bytes of data to expect within the packet, for example:
“0000007c” //total length of data in packet
“9955eeaa” // “magic” number
“06″ // number of following bytes including null
“6d7479706500″ //the text “mtype”
…etc

In the above example the number of data bytes in the packet is “0x7c”, or 124 bytes. If this value is set to zero in a packet sent to the RVD daemon then it stops responding to all subsequent communication. This appears to result from a memory leak, which continues to attempt to allocate memory. Eventually, operating system alert messages start to appear, warning that the virtual memory in the underlying operating system is running low.

[youtube]http://www.youtube.com/watch?v=1hdsxUmVTBg[/youtube]

Credits:
Research & Advisory: Varun Uppal and Andy Davis

http://www.irmplc.com/index.php/158-Messaging-Systems-Security