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>] [day] [month] [year] [list]
From: R.Ferris at napier.ac.uk (Ferris, Robin)
Subject: stack V heap and MS03-49

Question 
 
MS03-49 is a stack based buffer overflow, as described below in the articles
below. I have also included a description of the blaster exploit, which was
also a stack based over flow. 
 
"We found some RPC functions which will accept a long string as a parameter,
and will attempt to write it to the debug log file. If we specify a long
string as a parameter to these RPC functions, a stack-based buffer overflow
will happen in the Workstation service on the remote system. Attackers who
successfully leverage this vulnerability will be executing code under the
SYSTEM context of the remote host."  credit Yuji Ukai
http://www.eeye.com/html/Research/Advisories/AD20031111.html
<http://www.eeye.com/html/Research/Advisories/AD20031111.html>  analysis of
MS03-49
 
"This is a stack buffer overflow vulnerability that exists in an integral
component of any modern Windows operating system, an RPC interface
implementing Distributed Component Object Model services (DCOM). In a result
of implementation error in a function responsible for instantiation of DCOM
objects, remote attackers can obtain remote access to vulnerable systems."
credit  <http://lsd-pl.net/special.html> http://lsd-pl.net/special.html
(blaster exploit)
 
However the buffer overflow patched by MS03-039 was a heap based.
 
I remember reading in this list that a stack based overflow would be more
"easily"/"effectively"/"automatically" exploited than a heap based one.
Taking this into account could we summarise that this latest over flow
posses a similar threat as the first RPC DCOM overflow?
 
Thanks
 
RF
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20031112/d428a20f/attachment.html

Powered by blists - more mailing lists