Bugtraq mailing list archives
Re: CERT/AUCERT
From: volobuev () t1 chem umn edu (Yuri Volobuev)
Date: Thu, 19 Dec 1996 20:08:32 -0600
I politely asked CERT about this. "Not our policy to acknolwedge", to paraphrase the response. Then I pointed out that they *always* bend over backwards to acknowledge computer companies and the other CERT (whichever one is doing the announce) to the point of effusiveness at times. No reply since, did I offend them? This really isn't a game of responsible CERTs vs dirty crackers, its just a matter of professionals sharing valuable knowledge. Knowledge which is significant enough to be worth a lot of money to a lot of people, regardless of intellectual property laws.They should be far more careful, and apply common decency besides. It seems to me that they might have a case for not acknowledging when all that was posted was an exploit, not a fix. However when both are posted together it smacks of plagurism to me to repost another version of the fix without acknowledgement. By this logic the author of the recent SGI stuff should get a mention but SOD should not, since SOD don't (as far as I can recollect) publish fixes as well.
We had a little discussion on that subject with AUSCERT. They think that full disclosure is bad, period. So if one posts an exploit, he'll never be acknoledged. The rest is irrelevant. That's a matter of opinion, though. For professionals who understand what they are doing, full disclosure is the best way to understand the problem and figure what they need to do to fix it. For people with less clue who consider reading security lists a luxury, it's pure evil. One of the blames put of authors of exploits is that they make possible creation of "root kits". No one mentions, though, that root kit which only contains published exploits is harmless to people who keep themselves informed. At any rate, question of relative merits of full disclosure is far too complex to treat it in any simple way, like xCERT do. However, the way I understand it, giving a credit for this kind of information remains purely a question of professional courtesy, I don't think any legal implications can be seriously considered. As for supplementing an exploit with a fix, it's not a point whatsoever. For commercial Unices where no source code is available, workaround could only be as much as stripping suid bit or making a simple wrapper. Any knowlegdable sysadmin would be able to come up with ideas as bright as those by his/her own. So what SOD et al. are doing is not much different from me reminding people to remove that suid bit. Real fixes in many cases are also simple: check buffer bounds, do lstat before write, never ever use system(), and such (which doesn't make some vendors react any quicker, of course). Trick is to find a weakness. cheers, yuri
Current thread:
- Re: Possible Denial of Service: SSH, (continued)
- Re: Possible Denial of Service: SSH Sven Gestegard (Dec 18)
- Exploit for ppp bug (FreeBSD 2.1.0). Leshka Zakharoff (Dec 18)
- CIAC Bulletin H-17: cron/crontab Buffer Overrun Vulnerabilities David Crawford (Dec 19)
- NT vulnerable to attack on CPU Aleph One (Dec 19)
- CERT/AUCERT Mycroft (Dec 19)
- Re: CERT/AUCERT itudps (Dec 19)
- Re: CERT/AUCERT Aleph One (Dec 19)
- Re: CERT/AUCERT Theo de Raadt (Dec 19)
- Slow vendor response Alan Cox (Dec 20)
- CERT Bashing, etc Aleph One (Dec 19)
- Re: CERT/AUCERT Yuri Volobuev (Dec 19)
- Re: CERT/AUCERT Tung-Hui Hu (Dec 19)
- TCP bug on old Solaris box ? Gilles Soulet (Dec 20)
- Re: TCP bug on old Solaris box ? Nathan Lawson (Dec 21)
- Buffer overflow in Linux's login program Joe Zbiciak (Dec 22)
- Solaris 2.5 x86 aspppd (semi-exploitable-hole) Thamer Al-Herbish (Dec 20)
- CERT, CIAC, etc. and unethical practices Thamer Al-Herbish (Dec 20)
- ANNOUNCE: Crack v5.0a available... Alec Muffett (Dec 20)
- Security Survey Aleph One (Dec 20)