Onderwerp: New Bug KESM in GoogleTalk

Hi!! My name is Nataly Lopez, I'm a 17 years old girl living in Venezuela; I have always loved computer security because that's also my father's work.
Well, the reason for me to post this is for telling you about a bug in Google Talk I discovered with my friend chris77 (#velug @ irc.freenode.net) this afternoon.
Google Talk's excellent features allow the user to know when contacts send mails without configuring any passports, etc., well, you know that. What's really funny is: one can generate remote errors in the users' systems connected to Google Talk, and thus
creating a kind of DoS. So Google Talk stops working if it has email notification enabled: it suffices to type this command in a Linux shell (nail must be installed of course):

echo kill | nail -s Kill -r "" victim@gmail.com

This instruction is quite simple, and will send an email to the user being connected to Google Talk from a certain "unknown sender", and as you can see, GoogleTalk Windows client cannot notify <> is sending an email. Therefore, an error windows appears on
screen:

[ Google Talk encountered an internal error, and must now close. Ok to report this error to Google? ]
[Yes] [No]

We called this bug KESM, which stands for "Killer Empty Sender Message" and one can easily implement it into a loop, keeping the victim busy clicking on the YES button and resetting his connection to Google Talk.

That's all for now folks :-)

Initially every anonymous email was notified and googletalk crashes, but now all anonymous emails go directly to spam folder, don't show the popup and don't crash, but if move the mail to the inbox and it's marked "no readed" , when open googletalk and sh
ows the popup the application crash.

> From: natalylopez380@hotmail.com
> To: bugtraq@securityfocus.com
> Subject: New Bug KESM in GoogleTalk
>
> Hi!! My name is Nataly Lopez, I'm a 17 years old girl living in
> Venezuela; I have always loved computer security because that's also
> my father's work.
> Well, the reason for me to post this is for telling you about a bug in
> Google Talk I discovered with my friend chris77 (#velug @
> irc.freenode.net) this afternoon.
> Google Talk's excellent features allow the user to know when contacts
> send mails without configuring any passports, etc., well, you know
> that. What's really funny is: one can generate remote errors in the
> users' systems connected to Google Talk, and thus creating a kind of
> DoS. So Google Talk stops working if it has email notification
> enabled: it suffices to type this command in a Linux shell (nail must
> be installed of course):
>
> echo kill | nail -s Kill -r "" victim@gmail.com
>
> This instruction is quite simple, and will send an email to the user
> being connected to Google Talk from a certain "unknown sender", and as
> you can see, GoogleTalk Windows client cannot notify <> is sending an
> email. Therefore, an error windows appears on screen:
>
> [ Google Talk encountered an internal error, and must now close. Ok to
> report this error to Google? ]
> [Yes] [No]
>
> We called this bug KESM, which stands for "Killer Empty Sender
> Message" and one can easily implement it into a loop, keeping the
> victim busy clicking on the YES button and resetting his connection to
> Google Talk.
>
> That's all for now folks :-)

Google has investigated this report and verified the validity of this
bug. It is fixed in the current version of Google Talk (1.0.0.76),
which is available at http://www.google.com/talk/. Existing users are
being updated automatically.

We take the security of our services and users very seriously, and
work to rapidly resolve any reported vulnerabilities. In the interest
of minimizing the impact that security vulnerabilities have on our end
users, we highly encourage anyone who discovers a vulnerability in a
Google product or service to follow responsible disclosure policies by
contacting us first at security@google.com.

--
-- Cory Altheide
-- Incident Response Lead
-- Google Security Team
-- security@google.com

Reference: http://kahrn.blogspot.com/2005/08/go...k-exploit.html