- This topic has 21 replies, 10 voices, and was last updated 19 years, 10 months ago by
.
-
Posts
-
Torseq Tech. wrote: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.
Assuming that you are the same “Torseq Tech” that discoverd this original flaw (as noted in the Bugtraq), I think it’s awesome that you have joined this forum and have added to it.
I have a question for you. In many of the BugTraqs that I have read (I get them in my email everyday) most authors include what steps they have performed in order to contact the responsible vendor of the security exploit they have found. In your 5/13 Bugtraq release of this exploit, I can find no such notification, although I’m sure you had tried. Did you try to reach Yahoo in advance? If so, how far in advance did they know about this and failed to do anything?
I have found a BugTraq submission from 2/21/2002 that mentions the ablility to add names without permission, just like you mentioned. Apparently Yahoo is slow to implement patches when vunerabilities are discovered.
Thanks again for your input in this site.
– dan –
Hey Dan,
That particular day/week/month range varies from security company or individual.
Some times its 2 weeks, others its 30 days.
It really depends on the severity of the exploit, the length in which it will take to fix the exploit.
As far as I know, the yahoo security team, and i use that phrase rather loosely dont actually reply to you.
You need to know an Admin if you want it patched asap.
I do know however that a Yahoo! Admin frequents this board, so if an exploit was posted here(minus the nitty gritty) a yahoo! admin will contact you.
UnSaKreD wrote:Hey Dan,That particular day/week/month range varies from security company or individual.
Some times its 2 weeks, others its 30 days.
Yeah, I know all about it. I was just curious about his advance notice since it wasnt listed in the BugTraq. Ironically, it was you (through your post here) that I found this out from because I didnt realize my Gmail notification wasn’t working (which is where all my BugTraq mail goes to).
It’s angering reading through the BugTraqs and seeing how many times a company has been given plenty of advance notice to fix the exploit or alert their customers but they do nothing about it. By the time it becomes a BugTraq warning it’s like a slap in their face to fix the problem. Only then do they seem to “jump” and do something (if only superficial) about the problem.
Also, I know, Brandon, that you probably (through our conversations about BuddySpy) didn’t realize that I’ve been in the I.T. industry for many years. I have been part of several I.T. “Think Tanks” and such and in each one, this topic of exploits and patching seems to come up. Many tend to criticize Microsoft for the number of Service Packs and other patches they come out with. I, however, applaud companies like that who are diligently patching. Yes, the number of patches indicates the number of vunerabilities, but at least they are getting patched. Using Microsoft as an example again, do you realize that a vast majority of viruses that affect Microsoft software could have been prevented by System Admins and Engineers around the world if they had applied previously released patches? This means they are one of the few companies that aggresively pursues exploits and does something about them.
Though I am not a coder, I am a Computer Science major and have been around this a while. I know that coding is not an exact science and mistakes are bound to happen. It’s human. However, I think more companies, such as Yahoo, should have a better open door policy and more avenues to report such exploits as they are found. Maybe they can even offer some type of reward based on the severity. Bugtraq posters, however, are not looking for financial rewards. For the most part, they seem to be doing it for the good of the industry (hence the good faith efforts to notifice each vendor).
Anyways, enough rambling; just my two cents, and then some 😀
– dan –
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.
Torseq Tech. wrote:Dan – Yes, notified Yahoo! Inc. at exactly the same time (within minutes or so) of releasing the first two bugtraq advisories.Well, you see, that is part of my issue here. While it is very noble of you to have contacted Yahoo and have done your part to find these flaws, I dont agree with the lack of notice you gave them before releasing the details to the public. Once that Bugtraq is out, it’s public knowledge.
Read this excerpt from one of yesterday’s Bugtraqs
=======================================>
“NGSSoftware are going to withhold details of this flaw for three months.Full details will be published on the 25th August 2005. This three monthwindow will allow users of L-Soft’s LISTSERV the time needed to apply the patch before the details are released to the general public. This reflects NGSSoftware’s approach to responsible disclosure.”
<========================================If you are really concerned about the security aspect of these exploits, they why not give them advance notice before it’s public knowledge?
Once again, I’m sure the Yahoo community appreciates your dilligence but for the sake of protection, a little more advance warning would probably help. Even though their responses to your emails seemed nonchalant at least give them the chance to correct the problem first. Then, after a few weeks, if the issue has not been adressed, then I fully support the “slap in the face” approach of making it public knowledge. Sometimes this is what it takes for them to step up to the plate.
Lastly, I agree that the problem with logfile is a serious one but only now since the exploit has been published. Hopefully they’ll do something about as the 7.0 Beta builds are released.
– dan –
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.
Im not sure. It’s a catch either way. Here’s the dilemna.
If an exploit has been found and it is being actively used across the network community then, obviously, not much more harm can come if it is released to the public. However, if it’s not a well known exploit (such as logfile, and adding ID’s) then is it beneficial to make it well known, if only for a few days until it’s patched? Take a look at this …
Let’s use fictitious numbers to represent the percentage of users exploiting any particular vunerability and the potential damage.
Scenario 1:
Well Known Exploit – Unpublished (to a major source such as BugTraq)
Used by: 70 % (of yahoo community)
Potential additional damage if released: 100 % of community using this exploit.With this scenario…. the damage only increases 30%…not really a big deal. Publishing this exploit doesnt really add much more harm.
Scenario 2:
Little Known Exploit – (only available to a small community of hackers/lamers/etc.)Used by: 20%
Potential additional damage if released: 100% of communityNow..you can see an 80% increase in possible abuse if this is released.
Publishing this exploit greatly increase the chances of abuse.
This is a classic and historical dilemna often portrayed in movies. “Do we sacrifice a few to save many?” or “Do we sacrifice many to save a few”Consider the very recent airspace breach around the White House a few weeks ago. A decision could have easily been made to shoot down the airplane that was heading toward the White House (sacrifice a few to save many).
I hope you aren’t taking my responses the wrong way. I (and Im sure many others) appreciate the dilligence involved into discovering these holes. I just wonder if, sometimes, a greater advance notice is needed to Yahoo (though by your experience, they don’t seem to really care as much as they do). I’m actually enjoying this thread more now that you’ve joined it. It’s actually good to hear from the source.
Take Care,
– dan –
- You must be logged in to reply to this topic.