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 for Android: free password hash cracker in your pocket
[<prev] [next>] [day] [month] [year] [list]
From: th.campos at bol.com.br (Thiago Campos)
Subject: DCOM RPC exploit  (dcom.c)

You would kill the process. Sometimes the system will 
continue to run but not properly. Other times a reboot 
is necessary.

- Thiago Campos

> What if it just kept an internal list of return address
es and simply cycled
> through them each in a separate thread until it was abl
e to gain access to
> the machine?
> 
> -----Original Message-----
> From: full-disclosure-admin@...ts.netsys.com
> [mailto:full-disclosure-
admin@...ts.netsys.com] On Behalf Of Robert Wesley
> McGrew
> Sent: Monday, July 28, 2003 1:11 PM
> To: full-disclosure@...ts.netsys.com
> Subject: RE: [Full-
Disclosure] DCOM RPC exploit (dcom.c)
> 
> 
> 
> On Mon, 28 Jul 2003, Schmehl, Paul L wrote:
> 
> > > 2) For this DCOM RPC problem in particular, everyon
e's
> > > talking about worms.  How would the worm know what 
return
> > > address to use?  Remote OS fingerprinting would mea
n it would
> > > be relatively large, slow, and unreliable (compared
 with
> > > Slammer), and sticking with one would cause more ma
chines to
> > > just crash than to spread the worm.  I haven't look
ed into
> > > this very closely yet to see if it can be generaliz
ed.
> >
> > What fingerprinting?  If you've got 135/UDP open to t
he Internet, you're
> > screwed.  Slammer didn't fingerprint.  It simply hit 
every box it could
> > find on port 1434/UDP, and the exploit either worked 
or it didn't.  Most
> > worms do the same.  They attack indiscriminately, and
 infect those Oses
> > that are susceptible.  And with Windows, that's enoug
h boxes to cause a
> > real problem.
> 
> Thanks for responding.  I realize that having 135 open 
on any Windows
> machine makes you vulnerable, and that you wouldn't nee
d to differentiate
> Windows/OtherOSes.  My question is about different Wind
ows versions.  The
> version (NT/2000/XP), service pack, and language at lea
st have to be known
> to get the return address right.  If it's "guessed" wro
ng, the system goes
> down with no shell executed.
> 
> Any worm using this would need to know the return addre
ss before
> attempting to exploit If a worm were to stick to target
ting one return
> address (say, English XP  SP1), everytime it ran across
 something slightly
> different (SP0, german, win2k, etc) it would simply cra
sh it and not
> spread.  One of three things would happen in the case o
f this worm :
> 
> 1) Sticks with one return address, makes a spectacular 
DoS against all
> other languages/versions/SPs.  This could limit how qui
ckly it spreads.
> 
> 2) Somehow finds out ahead of time what the remote lang
uage/version/SP is.
> Could be very unreliable and slow.
> 
> 3) There is some way of generalizing the return address
 in a way that
> would work on at least a large portion of installs.  Th
is is what would
> bring it into the league of Very Scary Worms.
> 
> Has anyone seen any indication in the private exploits 
or in their
> research that there's a way to get it to work reliably 
on systems without
> having to know version/SP/etc?
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-
charter.html
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-
charter.html
> 

 
__________________________________________________________________________
Acabe com aquelas janelinhas que pulam na sua tela.
AntiPop-up UOL - ? gr?tis!
http://antipopup.uol.com.br/



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ