full-disclosure - DCOM RPC exploit (dcom.c)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

From: rwm8 at CSE.MsState.EDU (Robert Wesley McGrew)
Subject: DCOM RPC exploit  (dcom.c)

Good of a point as any to jump into this, with a couple of questions to
steer conversation towards something resembling productivity ;).  For the
record, I support full-disclosure with "reasonable" vendor notification,
taking into account a time to acknowledge and a time to patch, and I also
support the release of exploit code publicly, especially with some warning
time given such as this situation.  That said, I see the point of people
who bring up the complexities of this, that disagree with me on this, and
for the most part, the arguments are well reasoned.  So I have two
questions, one on exploit code, and one on this in particular:

1) How would you propose to change the scene/industry/community of
security in such a way that would prevent the public release of exploit
code like this?

2) For this DCOM RPC problem in particular, everyone's talking about
worms.  How would the worm know what return address to use?  Remote OS
fingerprinting would mean it would be relatively large, slow, and
unreliable (compared with Slammer), and sticking with one would cause more
machines to just crash than to spread the worm.  I haven't looked into
this very closely yet to see if it can be generalized.

If the above have been answered already, forgive me.  I haven't read
everything in this thread header-to-sig :)

Wesley