Re: it's all about timing

>>>>> On Wed, 31 Jul 2002 17:53:08 -0500, "Moyer, Shawn" <SMoyer <at> rgare.com> said:

    MS> ISC? [ ^_^ ] Sure, it shouldn't have leaked, but exactly how long *were*
    MS> they going to let every OSF/1 box out there be a sitting duck? At least now
    MS> I know to chmod 750 /bin/su and chown it root:wheel (a good practice
    MS> anyway). 

Hmmmm, looks like a suit against the vendor for "reckless endagerment"
 might be in order.  Sometimes I wish I was an ambulance-chasing
lawyer (as opposed to the good kind).

(Yes, I know that "endangerment" requires possibility of harm to a
person.  But I can wish, and there must be some liability here...)

--tep
_______________________________________________
Full-Disclosure - We believe in it.
Full-Disclosure <at> lists.netsys.com
http://lists.netsys.com/mailman/listinfo/full-disclosure

RE: it's all about timing

It hasn't been yanked:

http://news.com.com/2100-1023-947325.html

Corey M. Snow- csnow <at> deltadentalwa.com
I don't speak for my employer.

> -----Original Message-----
> From: Moyer, Shawn [mailto:SMoyer <at> rgare.com]
> Sent: Wednesday, July 31, 2002 3:53 PM
> To: 'full-disclosure <at> lists.netsys.com'
> Subject: RE: [Full-Disclosure] it's all about timing

> Riiight.... Great. But according to the (now-yanked) CNet 
> article, 

<snick>

#########################################################
The information contained in this e-mail and subsequent attachments may be privileged, 
confidential and protected from disclosure.  This transmission is intended for the sole 
use of the individual and entity to whom it is addressed.  If you are not the intended 
recipient, any dissemination, distribution or copying is strictly prohibited.  If you 
think that you have received this message in error, please e-mail the sender at the above 
e-mail address.
#########################################################
_______________________________________________
Full-Disclosure - We believe in it.
Full-Disclosure <at> lists.netsys.com
http://lists.netsys.com/mailman/listinfo/full-disclosure

for the record... (Tru64 / Compaq)

[SECURITY] [DSA-138-1] Remote execution exploit in gallery

------------------------------------------------------------------------
Debian Security Advisory DSA-138-1                   security <at> debian.org
http://www.debian.org/security/                         Wichert Akkerman
August  1, 2002
------------------------------------------------------------------------

Package        : gallery
Problem type   : remote exploit
Debian-specific: no

A problem was found in gallery (a web-based photo album toolkit): it
was possible to pass in the GALLERY_BASEDIR variable remotely. This
made it possible to execute commands under the uid of web-server.

This has been fixed in version 1.2.5-7 of the Debian package and upstream
version 1.3.1.

------------------------------------------------------------------------

Obtaining updates:

  By hand:
    wget URL
        will fetch the file for you.
    dpkg -i FILENAME.deb
        will install the fetched file.

  With apt:
    deb http://security.debian.org/ stable/updates main
        added to /etc/apt/sources.list will provide security updates

Additional information can be found on the Debian security web-pages
at http://www.debian.org/security/

------------------------------------------------------------------------

Debian GNU/Linux 2.2 alias potato
---------------------------------

  Potato does not contain the gallery package

Debian GNU/Linux 3.0 alias woody
--------------------------------

  Woody was released for alpha, arm, hppa, i386, ia64, m68k, mips, mipsel,
  powerpc, s390 and sparc.

  Source archives:

    http://security.debian.org/pool/updates/main/g/gallery/gallery_1.2.5-7.woody.0.dsc
      Size/MD5 checksum:      577 34188f0145b780cabc087dc273710428
    http://security.debian.org/pool/updates/main/g/gallery/gallery_1.2.5.orig.tar.gz
      Size/MD5 checksum:   132099 1a32e57b36ca06d22475938e1e1b19f9
    http://security.debian.org/pool/updates/main/g/gallery/gallery_1.2.5-7.woody.0.diff.gz
      Size/MD5 checksum:     7125 707ec3020491869fa59f66d28e646360

  Architecture independent packages:

    http://security.debian.org/pool/updates/main/g/gallery/gallery_1.2.5-7.woody.0_all.deb
      Size/MD5 checksum:   132290 8f6f152a45bdd3f632fa1cee5e994132

--

-- 
----------------------------------------------------------------------------
Debian Security team <team <at> security.debian.org>
http://www.debian.org/security/
Mailing-List: debian-security-announce <at> lists.debian.org

Re: it's all about timing

I think many if not most of us on this list who have produced
advisories/exploits have experienced the fustration associated with the
response from some vendors. I had to explain how serious a buffer overflow
was to the author of mIRC, after several emails the vendor agreeded to fix
the problem in the next version. At this time my exploit writing skills were
in their infancy, I did not have a working exploit so I accepted this.

Two months later (I had got distracted by real work et al) I produced a
working exploit and informed the vendor. It was another two months before
the vendor provided a fix, I waitted until they released it before I
released my exploit code. The new release was a major version upgrade, as
you can imagine this felt like they had played me to keep their existing
development schedule. Of course I cannot accuse them of this, but it
certainly felt like they had. To this day they have not publically
acknowledged the existance of the hole in all versions prior to 6.00.

However Dalnet, IRCNet and many other networks all have warnings advising
users to upgrade. Also it was covered by news.bbc.co.uk, newsbytes.com, cnet
and many other news sites. I cannot understand their reasons for this, they
obviously feel  publically admitting their mistake and giving there users a
strong warning to upgrade is not good PR.

I estimate still nealry 50% of mirc users are running v5.91 and lower. This
figure was attained from a CTCP version of #chatzone on dal.net. This is
after 3 versions being released sequentially since the disclosure. I
personally don't feel the vendor has made an appropriate effort to protect
its userbase.

On top of this, I was astonished at how so many people assumed that because
my proof of concept code only lauched calc.exe, this wasn't a dangerous
hole! I'm seriously considering making my next do "command /c deltree /Y
c:\program files" (joke) :P, you have highlight the seriousness of the hole.
Its amazing how blatent it seems you need to be. I can't imagine releasing
an advisory without working exploit code.

In summary, I don't know the full circumstances with this Tru64 exploit but
it seems the hole should have been fixed by HP and they are just trying to
stifle efforts to get them to fix it. I wonder how long it will take for a
fix to arrive now? (or has it already?). I'd much prefer working exploit
code, and an opertunity to fix any system under my control which would be
effected, than secrecy a with the chance that someone else has wirtten an
exploit which is circulating in the underground.

Regards
James

----- Original Message -----
From: "Dave Killion" <Dkillion <at> netscreen.com>
To: <full-disclosure <at> lists.netsys.com>
Sent: Wednesday, July 31, 2002 10:59 PM
Subject: RE: [Full-Disclosure] it's all about timing

> Florin,
>
> I agree with you completely.  From what I understand this vulnerability is
> about a year old, although I'm not knowledgeable enough to say that with
> authority.  If it's true, then I believe the 2-4 week requirement has been
> satisfied.
>
> -Dave
>
> *************************** NOTICE **************************
> Opinions expressed in this email are solely my own, and do
> not reflect the attitudes, policy, or opinion of my employer.
> *************************************************************
>

_______________________________________________
Full-Disclosure - We believe in it.
Full-Disclosure <at> lists.netsys.com
http://lists.netsys.com/mailman/listinfo/full-disclosure

Re: for the record... (Tru64 / Compaq)

/bin/su +Tru64

Re: It takes two to tango Re: OT: Snosoft vs HP

A city boy, Kenny, moved to the country and bought a donkey
from an old farmer for $100.00. The farmer agreed to deliver
the donkey the next day. The next day the farmer drove up
and said, "Sorry son, but I have some bad news, the donkey
died."

Kenny replied, "Well then, just give me my money back."

The farmer said, "Can't do that. I went and spent it
already."

Kenny said, "OK then, just unload the donkey."

The farmer asked, "What ya goanna do with him?"

Kenny, "I'm going to raffle him off."

Farmer, " You can't raffle off a dead donkey!"

Kenny, "Sure I can. Watch me. I just won't tell anybody he
is dead."

A month later the farmer met up with Kenny and asked, "What
happened with that dead donkey?"

Kenny, "I raffled him off. I sold 500 tickets at two dollars
apiece and made a profit of $898.00."

Farmer, "Didn't anyone complain?"

Kenny, " Just the guy who won. So I gave him his two dollars
back."

Kenny grew up and eventually became the chairman of Enron.

Thanks,

Ron DuFresne
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Cutting the space budget really restores my faith in humanity.  It
eliminates dreams, goals, and ideals and lets us get straight to the
business of hate, debauchery, and self-annihilation." -- Johnny Hart
	***testing, only testing, and damn good at it too!***

OK, so you're a Ph.D.  Just don't touch anything.

_______________________________________________
Full-Disclosure - We believe in it.
Full-Disclosure <at> lists.netsys.com
http://lists.netsys.com/mailman/listinfo/full-disclosure

RE: it's all about timing

I believe, depending on severity of the vulnerability, that one week should 
be sufficient for at least vendor response prior to publically leaking 
information about said vulnerability.  This does not mean releasing exploit 
code, only general information about the vuln so that educated readers can 
understand what's going on.

If no vendor responses occur, then release of information should occur.  If 
there is vendor response indicating an attempt to work the issue, then more 
time should of course be given (again, depending on severity of the issue).

Holes in this would include exactly *how* the vendor was contacted 
(midnight messages left in the general company voicemail don't count, etc.) 
and whether any follow-up attempts were made.  Also, a vanilla vendor 
response to the effect of "Thank you for the information.  We'll look into 
it.  Don't call us, we'll call you" is an effective NOOP.

Are we enough of an ad-hoc "authority" to attempt to determine a proper 
course of action for these instances?  Codifying this (even if it's just a 
"gentlemen's agreement") would most definitely be A Good Thing.
--

-- 
Eric N. Valor
ericv <at> cruzio.com
PGP Key 2048/1024 227B04CB
Key Fingerprint = 766C CA15 0FFF E54B 2FEE  C7D7 0F87 3AFB 227B 04CB

: This Space Intentionally Left Blank :

_______________________________________________
Full-Disclosure - We believe in it.
Full-Disclosure <at> lists.netsys.com
http://lists.netsys.com/mailman/listinfo/full-disclosure

RE: it's all about timing

On Wed, 31 Jul 2002, Eric N. Valor wrote:

> Are we enough of an ad-hoc "authority" to attempt to determine a proper
> course of action for these instances?  Codifying this (even if it's just a
> "gentlemen's agreement") would most definitely be A Good Thing.

RFPolicy always seemed reasonable to me.

--

-- 
Jonathan Rickman
X Corps Security
http://www.xcorps.net

_______________________________________________
Full-Disclosure - We believe in it.
Full-Disclosure <at> lists.netsys.com
http://lists.netsys.com/mailman/listinfo/full-disclosure