Forum Replies Created
-
Posts
-
If you use Y!Tunnel or a customised filter you are also safer that just using bare Messenger.
Yes, that’s correct.
If you using java/chat2.0 you are pretty safe, way safer than Messenger.
This can be argued. If you’ve heard of a feature Chet Simpson coins “Cloaking” *Y!Tunnel features this* (this can also be done through Messenger without Y!Tunnel only you’ll have to do it manually each time) this feature “informs” the YMSG server that Messenger’s connected to to NOT send the majority of packet types that are considered “extras”. The bare-bone features can be used in this mode while the rest are restricted until after you’ve ‘uncloaked’ — or turned your Alias ID back to the ‘activated’ status. The YMSG features that are available when cloaking are chat room messages, PMs (behavior changes and these aren’t always available) and chat invites, nothing else. If you were to do a feature “run down” for Chat 2.0 (DHTML-based implementation of this protocol via the Yahoo! webpage) you’d see quickly that an Alias ID in a chat room “Cloaking” in YMSG is exactly equivalent in feature set to a Chat 2 protocol user and vice versa. When people “Cloak” they may not know it right away but they infact are “dumbing down” their YMSG session to that of a Chat 2 session.
YCHT protocol is a different story as it’s so bare-boned that it’s virtually impossible to be ‘booted’ from packet floods while using it. The majority of the ‘flooding’ is literally dropped by the YCHT servers themselves so the user experiences virtually none from PM bombing and as a result the servers aren’t ‘forced’ to drop their connection. The YMSG/HTTP login (I’ve yet to see a single 3rd party chat client support this) is also a tough contender and it’s users certainly aren’t prone to being “disconnected” by PM bombs, add buddy bombs etc. due to the nature of the way HTTP operates (not a single long-lasting connection but frequent connections to the servers meaning the connection isn’t in ‘real-time’). Good luck to anyone that thinks they can disconnect a user who’s ‘connection’ is based on a timer to check for new content (in this case YMSG data) every so many seconds.
If you use a 3rd party client you really are laughing at the booters
I assume you’ve made this statement implying that all 3rd party clients are “secure”? The majority are multi-protocol and most users use a 3rd party client simply to get away from YMSG’s problems (they seem to enjoy YCHT and Chat 2 for this). What was it like only about 2 months ago where a remote buffer overflow vulnerability was discovered and *fixed* in a recent build of YahElite? I’ve yet to enjoy chatting on a 3rd party client because the authors are always playing catch up with Messenger’s new features. No 3rd party client has full support for all of YMSG protocol’s features – not even counting the fact that I’ve yet to see a 3rd party client support YMSG13 protocol as it requires a “hacked” login. The rich edit control vs. the MSHTML usage in 3rd party clients also doesn’t make 3rd party clients more “secure”, it only makes them less desirable when smilies are put on screen etc.
I believe (many do) the “best way” to deal with being booted is to simply use an application-layer gateway *Y!Tunnel is one of these* to handle the specific Messenger-exclusive vulnerabilities while at the same time using them to ‘bridge’ to other protocols such as Chat 2 and YCHT so they can be used through Messenger. People want to use Messenger and not 3rd party clients written to clone the official client. Why reinvent the wheel? A 3rd party client using the YCHT protocol isn’t any more “unbootable” than Messenger bridged to a YCHT server.
“Well, you can’t do anything.. as it is in the core of the these IMs.. I’m really sorry I can’t explain more.. I’m waiting a reply from the Yahoo! Security Team Leader who said he will reply within a week..
So then, I may explain what to do (what they need to do really for their software..)”
Waiting for a reply within a week sounds familiar as I’ve heard this before as well when reporting vulnerabilities to them affecting their software BUT I’ve yet to talk to a “Yahoo! Security Team Leader”… usually the e-mail replies are simply and generically signed ‘Yahoo! Security Contact’. I understand the reasoning behind you not wanting to give any details out but I really do think that it’s something small if anything that you’re making a big deal about. Statements like “as it is in the core of the these IMs” and the whole hacking/cracking thing sounds brutally indescriptive covered in a cloud of probable hype. Not trying to offend you but more than likely you just think that whatever you’ve found is a “critical” flaw when in reality it’s probably not too serious. Not trying to really downplay your finding(s). Provide a tad of detail/insight and maybe it might seem more believable.
I figured that was the problem at first also, however, setting the correct source still didn’t/doesn’t solve the problem (at least for me).
Yes, have the same problem, actually. I’ve got an old Aiptek Pencam Trio that won’t work with any of the newer Messenger versions too. I’ve also got a friend with the same cam, same deal. Definitely a 6 -7.0 Yahoo! Messenger incompatibility issue. When it DOES detect the cam, which I can sometimes make that happen, all I see is a black screen when I’m uploading my cam (broadcasting). The only “fix” I see is informing Yahoo! about it, that’s if they actually feel like looking into it. Used to work fine for me on ver 5.5 and 5.6 though.
Dan – This wouldn’t be the only time I’ve forwarded information to them. Last occasion was directly to them and nobody else (didn’t go public). I think that was a mistake, since it took weeks to fix a simple issue that was quite serious which was actively being abused around Yahoo!
I think it’s quite “fair” to release them to the public and to Yahoo! Inc. at the same time. This way Yahoo! is forced to act quickly to fix the issues and the issues are known about to the public, and not just fixed behind the scenes and unknown to chatters. I think people need to be aware of issues like this and by not going public early with these issues I think that it’s allowing people’s eyes to stay closed and allowing for too much leisure time to fix the issues, on the vendor’s behalf. I have nothing against Yahoo!, this is just the way I disclose information. If these had been something more critical, such as a remote buffer overflow that was easily exploitable, I’m sure then that I would have given a few days notice to them before going public. By then Yahoo! probably would’ve already done that and forced everybody to upgrade their builds.
Dan – Yes, notified Yahoo! Inc. at exactly the same time (within minutes or so) of releasing the first two bugtraq advisories.
1st response (to the remote DoS):
“Thank you for contacting us regarding this issue. We are
currently working to reproduce the issue and will update you
next week on the status.”Yahoo! Security Contact
2nd response (to the Add Buddy):
“Thanks for passing this along.”
Yahoo! Security Contact
The third e-mail to them was never acknowledged (the logfile issue). I e-mailed them exact copies of those advisories, where they even received the logfile advisory hours before it was even made available on bugtraq. I also told them that I had released them there, so it wouldn’t catch them off guard down the road when finding that out. As a result 2 of the issues appear to be fixed for now (fixed a few days later), including the remote DoS which actually was a server-side fix — also is fixed* in the beta builds of 7.0.
The logfile issue has yet to be fixed, even at current build 247 of version 7.0 beta. Apparently it’s no big deal to Yahoo! if logging is enabled without local users knowing that it’s being done, storing all session data in clear-text (unencrypted) and locally accessible on the machine to anyone. Cookies, buddylists, PMs, conferences, chat room conversations, status messages and even mobile text messages all there for anyone to read. As I noted in the advisory it wouldn’t be hard to write a parser and reconstruct all conversations and events in the log for perfect viewing of everything that went on. If Yahoo! doesn’t fix this by next build I’ll more than likely write one and post it on bugtraq as “companion code” to show how simple it would be to actually make full use of all the unencrypted information being stored. If this ‘feature’ is available simply for “troubleshooting” then I’d question why so much information that isn’t needed (private) is logged, why there’s so much logging going on and why it’s all being stored with no protection of the contents in mind. The feature is pretty “shady” if you ask me, including the one and only way it can be enabled/disabled in Messenger.
A direct link, for the new build of 7.0 beta and all future builds, can be found here:
http://us.dl1.yimg.com/download.yahoo.com/dl/msgr7/us/ymsgr7_247_us.exe
If you don’t want the bloat from the Messenger 7.0 beta “suite” just get the installer for Yahoo! Messenger 7.0 beta ONLY @ the link.
For those of you that still think this works, it doesn’t. Yahoo! fixed this several days ago (should have fixed it sooner). “Fixed” as in disabled the functionality altogether until they can make sure that this won’t occur again. When they see that it’s working properly more than likely it’ll be back, but actually informing the added “friends” of the buddy add that took place. This really isn’t anything “new”, way back there was a similar way to add people from a Yahoo! web link. The only difference here is that this was found years later, when Yahoo! was “supposed” to have ‘some’ of their crap together. If anyone else would like to know if adding friends can still be done without informing them I can tell you yes, but, not as conveniently as this past method of doing it. As someone already said in this thread it’s definitely not wise to have important information in your status messages.
