Bugtraq mailing list archives
Re: [HERT] Advisory #002 Buffer overflow in lsof
From: woloszyn () IT PL (M.C.Mar)
Date: Sat, 20 Feb 1999 14:13:17 +0100
On Thu, 18 Feb 1999 route () RESENTMENT INFONEXUS COM wrote:
[Gene Spafford wrote] | | People who publish bugs/exploits that are not being actively exploited | *before* giving the vendor a chance to fix the flaws are clearly | grandstanding. They're part of the problem -- not the solution. | Who is to say the vulnerability in question was NOT being exploited prior to release? Odds are it was. Bugtraq is a full-diclosure list. The `problem` as you succinctly put it is in *non-disclosure*. While it is still questionable whether or not the original posters found the bug themselves (the advisory lacked any technical detail) calling them part of
In the adv. there was written: Author: Mariusz Tmoggie Marcinkiewicz <tmoggie () hert org> I'm the witness that he DID found a bug themselfe (maybe he was not FIRST ever). Tmoggie called me tuesday evening and he said that there is a bug in lsof (he was prepairing CD with S.u.s.e distribution, so he installed it and did some find for suid/sgid files). Next day, I found his mail about it (which was addressed to hert and lam3rz mailing lists) in my mailbox, so I wrote an exploit (it took me about half an hout), I used slackware linux. After that I posted it back to HERT. Becouse of something there was a lot of rumor about this vul. on #hax channel on IRC, so Anthony Zboralski <acz () HERT ORG> HERT maintainer decided to write an advisory to made it public.
the problem is a misfire of your disdain (attacking them on the content of the advisory --or lack thereof-- is a much better call). The problem, in this case, would be the malevolent individual(s) breaking into your machine exploiting this bug (before or after it was disclosed).
So now you know WHY it was published so fast, without giving a chance to fix it... BTW: finding such kind of vulnerability is not so hard! As I can undestand that authors of lsof could be not familiar with security, but I cannot undestand WHY people that are NOT good in security issues are doing COMMERCIAL distributions (like S.u.s.e or RH)???
Don't shoot the messenger.
:) -- Kil3r () hert org
Current thread:
- Re: [HERT] Advisory #002 Buffer overflow in lsof, (continued)
- Re: [HERT] Advisory #002 Buffer overflow in lsof Valdis.Kletnieks () VT EDU (Feb 19)
- Plaintext Password in Tractive's Remote Manager Software Trevor Gryffyn (Feb 19)
- Re: [HERT] Advisory #002 Buffer overflow in lsof Peter W (Feb 19)
- Re: [HERT] Advisory #002 Buffer overflow in lsof John DiMarco (Feb 19)
- Re: [HERT] Advisory #002 Buffer overflow in lsof brian j pardy (Feb 19)
- Re: [HERT] Advisory #002 Buffer overflow in lsof Greg Woods (Feb 19)
- Re: [HERT] Advisory #002 Buffer overflow in lsof route () RESENTMENT INFONEXUS COM (Feb 18)
- Re: [HERT] Advisory #002 Buffer overflow in lsof Fred W. Noltie Jr. (Feb 19)
- Call to politeness (Re: [HERT] Advisory #002 Buffer overflow in alecm (Feb 19)
- pine 4.10 patches (similar to 4.05) GvS (Feb 20)
- Re: [HERT] Advisory #002 Buffer overflow in lsof M.C.Mar (Feb 20)
- full disclosure and vendor education Antonomasia (Feb 20)
- Re: [HERT] Advisory #002 Buffer overflow in lsof Lamont Granquist (Feb 18)
- Win98 Buffer Overflow (File attached) Scott (Feb 14)